Velo feeding

[Peter]

Hello,

I tested the Velo feeding from an external resource (simulated HR
system - MySQL db table). I can't get Velo to create users in velo
repository with the correct attributes (firstname, lastname).

When I reconcile jdbc resource (MySQL table), velo successfully finds
all users and creates new accounts and users. Newly created accounts
are correct - all account attributes are set correctly. Velo also
creates users with correct usernames, but none of the user attributes
is filled with the correct value (they are empty). I tried the
"Reconcile Identity Attributes" action, but the task results with
FATAL ERROR. I studied the code and if I understand it correctly,
there should be an XML file velo\velo_ws\resources\<res_name>
\sync_files\<res_name>_sync.xml - this file is used to create
ActiveAccounts list. Without proper ActiveAccounts list the user and
corresponding account attrs synchronization cannot be completed
(target attrs are simply ignored and they are not filled with the
correct values). Could you please post an example sync file?

Thanks.

Peter

[Asaf]

Hey Peter,
Welcome!

When you define new resource attributes (for the resource you want to
reconcile), you have to flag it as 'synced' and 'persistence',
otherwise the attributes wont get persisted in the DB,
Also, if you want the user's attributes (which are the global
attirbutes of the identity that represents the person) you have to
select the identity attribute, edit it, and map its value to the
resource attribute as its source,


Let me know how it works for you!

Asaf.

[Peter]

Hi Asaf,
you are right, it works that way. I'll explain in more detail what I
meant with my question. I am analysing the full potential (features/
posibilities) of Velo in various identity management designs/
scenarios.

I was thinking about two situations:

1. When the global identity attribute is mapped to certain resource
attribute, I was not able to edit this attribute from the Velo GUI.
It's OK when the resource is considered to be an autoritative source
(Velo is reading from the resource - not writing). It becames a
problem when I want to create a user through the GUI - for a mapped
attribute I cannot set the value (attribute is read-only). Of course,
there is a workaround - temporaly unmap the identity attribute,
manually create the user and after the user was created map the
identity attribute back as resource source attribute. Or is there also
another solution I didn't figure out?


2. I saw an identity management scenario with two sources used to feed
an identity management system (it worked, both sets of identities were
disjunctive). Now I was thinking how to handle such a situation in
Velo. The setting described in previous point was not an option for me
(you can't map global identity attribute to two resource attributes).
So I came to conclusion, that all global identity attributes must be
set LOCAL and their proper values must be copied from corresponding
account attributes (account attributes are calculated in
reconciliation process). When I read the code of "Reconcile identity
attributes" - class velo.reconcilidation.ReconcileIdentityAttributes,
it seemed to be exactly what I was looking for - except the fact that
it needed xml sync file to work and I didn't know it's correct syntax.
Based on code and digester rules
(velo.reconcilidation.SyncTargetImporter) I tried to reconstruct this
XML file, probably it should look something like:

<synclist>
<resource name='veloHR'>
<accounts>
<account>
<attributes>
<attribute name='uniqueName'>
<values>
<value>...some value...</value>
</values>
</attribute>
<attribute name='displayName'>
<values>
<value>...some value...</value>
</values>
</attribute>
... other attributes ...
</attributes>
</account>
... other accounts? ...
<groups>
<group name='Active Accounts'/>
</groups>
<groupsMemberShip>
<group name='Active Accounts'>
<member id='????' name='veloHR'/>
... other members? ...
</group>
</groupsMemberShip>
</resource>
</synclist>

But at this point I am not sure - should be in this file all accounts
I want to use as sources to copy syncedPersisted attributes to their
user identity attributes, or am I completely wrong and this sync file
should have other structure and it's used to other purpose?


Nevertheless, if Velo is designed so that there can be just one
feeding source (and user global identity attributes are mapped to this
resource's attributes), the abovementioned situation with two sources
can be solved by combining them into one that will be used to feed
Velo (imperative source).

Now I would like to know your opinion - is there some solution to use
several feeding sources to create Velo users? (excluding the solution
to bypass Velo and directly fill the Velo's db repository tables with
data - btw. I like the db data model, it's rational and
understandable...)


Peter

[Asaf]

Hey Peter, Answers are embedded within the original mail,

> Hi Asaf,
> you are right, it works that way. I'll explain in more detail what I
> meant with my question. I am analysing the full potential (features/
> posibilities) of Velo in various identity management designs/
> scenarios.
>
> I was thinking about two situations:
>
> 1. When the global identity attribute is mapped to certain resource
> attribute, I was not able to edit this attribute from the Velo GUI.
> It's OK when the resource is considered to be an autoritative source
> (Velo is reading from the resource - not writing). It becames a
> problem when I want to create a user through the GUI - for a mapped
> attribute I cannot set the value (attribute is read-only). Of course,
> there is a workaround - temporaly unmap the identity attribute,
> manually create the user and after the user was created map the
> identity attribute back as resource source attribute. Or is there also
> another solution I didn't figure out?

Currently, a global identity attribute is not editable if the source
is a resource, the only way is to make the identity attribute's source
is local.
We'r desining velo2 now, it'll probably change in this version, so you
will be able to push changes to account's attributes through the
global identity attributes,

Yeah, because there are many many tables, we really really kept the DB
structure as simple as possible,

Regarding your question - ReconcileIdentityAttributes is an old code,
I think it's even flagged deprecated, the new way allow you to map
only one source, the reason is because it started to be a mass,
At the end, I convinced all customers that use Velo to have one
authoritive source for global identity attributes, I think it's much
more comfortable and right to do,
If it's important for you, file a feature request, so we can support
that in the future, btw, I'm cerious, can you explain the reason of
having two authoritive sources for one attribute?



> Peter

[Peter]

Hi Asaf,

there was one source for one attribute per user, but there were two
categories of users - one category had been feeded through the sync
with source, and the other category was feeded through another
interface (SPML). In that special case it was the sw architects' wish
- I don't know the exact reasons, but I think they wanted to test both
ways.
In general I like more the design with one authoritative source for
identity management solution, where every identity has exact set of
normalised attributes and all real source systems (regular HR,
different contractor DBs, special users DBs...) feed this autoritative
source.

Thanks for your answer. I have other questions regarding Velo but I'll
open separate discussion.

Peter

[Trouby]

Hey Peter,

I encountered some cases where different identity attributes had
different sources,
this sometimes make sense in situations where information of a certain
attribute is more accurate in one source than in another,

But having two sources for the same attribute does not make too much
sense to me, also what happens if the value is different? then you
have to manage priorities, etc... and this sounds to me like an
overkill and raises the complexity,


Sure, feel free to post any question you have around!


Asaf.