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/
