Virtual Attributes

[Martin Goldstone <m....@keele.ac.uk>]

Hi all,

I'm currently trying to understand virtual attributes.  I have a database
which contains ID card numbers for users, and I wish to propagate this into
LDAP. I've successfully done this as a plain attribute (by synchronising
and propagating), but I've read it would be best to keep the number of
plain attributes and derived attributes as low as possible and as such I've
been looking at virtual attributes.

I've got a user account which has the card database resource and the ldap
resource assigned, and I've defined the attribute in the user virtual
schema. I've added this to the mappings of both the card database resource
and the ldap resource (screenshots attached)

When I view the user, if the card number is absent from LDAP, a single
value is displayed for the card number attribute (under the virtual
attributes screen). If the card number is present in LDAP, a second value
is displayed. If the value in LDAP matches that in the card database, the
values are the same, however if the card number changes in the card
database the two values displayed are then different (screenshot attached),
and if I attempt a propagation for that user, the new number from the card
database does not make it into LDAP. Only when I remove the old value from
the user does the new value get propagated across. I've attempted to remove
the search capability from the LDAP resource connector, but whilst this
ensures only the value from the card database is displayed, any propagation
results in an error (LDAP: error code 68 - Entry Already Exists).

Can any one point me in the right direction? Am I trying to use virtual
attributes in the wrong way?

Thanks

-- 
Martin Goldstone
IT Systems Administrator
IT Services, Innovation Centre 1 (IC1)
Keele University, Keele, Staffordshire, United Kingdom, ST5 5NB
Telephone: +44 1782 734457
G+: http://google.com/+MartinGoldstoneKeele

Re: Virtual Attributes

[Fabio Martelli <fa...@gmail.com>]

Hi Martin, please find my comments in-line.
Kind regards,
F.

Il 31/03/2016 12:55, Martin Goldstone ha scritto:
> Hi all,
>
> I'm currently trying to understand virtual attributes.  I have a 
> database which contains ID card numbers for users, and I wish to 
> propagate this into LDAP. I've successfully done this as a plain 
> attribute (by synchronising and propagating), but I've read it would 
> be best to keep the number of plain attributes and derived attributes 
> as low as possible and as such I've been looking at virtual attributes.

Correct. By the way, virtual attributes are "expensive" as well so you 
have to find the right compromise.
Looking at your screenshots, it seems you have found it.

>
> I've got a user account which has the card database resource and the 
> ldap resource assigned, and I've defined the attribute in the user 
> virtual schema. I've added this to the mappings of both the card 
> database resource and the ldap resource (screenshots attached)
>
> When I view the user, if the card number is absent from LDAP, a single 
> value is displayed for the card number attribute (under the virtual 
> attributes screen). If the card number is present in LDAP, a second 
> value is displayed. If the value in LDAP matches that in the card 
> database, the values are the same, however if the card number changes 
> in the card database the two values displayed are then different 
> (screenshot attached),

Yes, this is the correct behaviour.

> and if I attempt a propagation for that user, the new number from the 
> card database does not make it into LDAP.

It is correct as well: propagation is not attempted because no changes 
are performed locally (on syncope).
This is the implementation chosen for virtual attributes up to the 1.2.X 
version.

If card database is authoritative for the card id and you are not 
interested in reading v.a. value from ldap, can I suggest you to map 
kdirCardUid as propagation-only attribute (purpose arrow ->) on ldap.
If you need to read it, you can use a second v.a. mapped in read-only 
mode just on ldap (purpose arrow <-).
In this way you will have just a single value for card_id.

To enable propagation you can still continue to use a sync task.

> Only when I remove the old value from the user does the new value get 
> propagated across. I've attempted to remove the search capability from 
> the LDAP resource connector, but whilst this ensures only the value 
> from the card database is displayed, any propagation results in an 
> error (LDAP: error code 68 - Entry Already Exists).
You cannot remove search capability for ldap resource: without it you 
cannot perform any entry existence check operation.
User mapping purposes as given above.
>
> Can any one point me in the right direction? Am I trying to use 
> virtual attributes in the wrong way?
>
> Thanks
>
> -- 
> Martin Goldstone
> IT Systems Administrator
> IT Services, Innovation Centre 1 (IC1)
> Keele University, Keele, Staffordshire, United Kingdom, ST5 5NB
> Telephone: +44 1782 734457 <tel:%2B44%201782%20734457>
> G+: http://google.com/+MartinGoldstoneKeele


-- 
Fabio Martelli
https://it.linkedin.com/pub/fabio-martelli/1/974/a44
http://blog.tirasa.net/author/fabio/index.html

Tirasa - Open Source Excellence
http://www.tirasa.net/

Apache Syncope PMC
http://people.apache.org/~fmartelli/