You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Edward Siewick <es...@digipro.com> on 2013/03/19 02:39:46 UTC
An odd work-around for stubborn derived attributes
Hi.
Just a quick note to report some unexpected behavior (v1.0.6).
I've been tinkering with two resources, a MySQL database and an openLDAP
directory with inetOrgPerson and posixAccount schema.
The only guaranteed unique field from the (OrangeHRM) MySQL resource is
the key field, emp_number (an int data type). Within Syncope's Resources
/ Schema Mappings for the resource, the key field isn't provided as an
option in the pulldown for External Attributes. It does get set to
Username, however.
Now, the openLDAP wants a uid as a guaranteed unique value. (More
precisely, it wants a DN that happens to include the uid.) The derived
attribute (uid => username) in Schema was still not working out for me.
So I decided to poke at this by adding to the MySQL resource's schema
mapping uid => emp_firstname (Internal Attributes => External
Attributes) which I'd expected would produce a string value in the uid
fields. And, surprise! The derived attribute (uid => username)
instantly popped to life. The next run of the sync task with the MySQL
resource produced a complete set of (numeric) uids.
To test this again, I added uidNumber => username as another derived
attribute. Again, it wouldn't populate automatically. I added uidNumber
=> emp_smoker (a smallint in the MySQL schema.) The column populated at
the next sync with the MySQL resource.
Edward Siewick
Re: An odd work-around for stubborn derived attributes
Posted by ilgrosso <il...@apache.org>.
Hi Edward,
I've finally been able to take a look at the provided information.
You can find my replies below.
Regards.
Edward Siewick wrote
>>> The only guaranteed unique field from the (OrangeHRM) MySQL resource
>>> is the key field, emp_number (an int data type). Within Syncope's
>>> Resources / Schema Mappings for the resource, the key field isn't
>>> provided as an option in the pulldown for External Attributes. It
>>> does get set to Username, however.
Ok, now I see: in the mapping, when you flag a row as 'AccountId' it gets
linked to the key of the underlying resource; for SQL tables, this turns to
be the primary key.
>From your mapping, then, I see that you are associating Syncope's username
with the primary key of the hs_hr_employee table, e.g. 8 / 9 / 11 / 14 / 15
/ 16.
Edward Siewick wrote
>>> Now, the openLDAP wants a uid as a guaranteed unique value. (More
>>> precisely, it wants a DN that happens to include the uid.)
>>> The derived attribute (uid => username) in Schema was still not
>>> working out for me. So I decided to poke at this by adding to the
>>> MySQL resource's schema mapping uid => emp_firstname (Internal
>>> Attributes => External Attributes) which I'd expected would produce a
>>> string value in the uid fields. And, surprise! The derived attribute
>>> (uid => username) instantly popped to life. The next run of the sync
>>> task with the MySQL resource produced a complete set of (numeric) uids.
>>>
>>> To test this again, I added uidNumber => username as another derived
>>> attribute. Again, it wouldn't populate automatically. I added
>>> uidNumber => emp_smoker (a smallint in the MySQL schema.) The column
>>> populated at the next sync with the MySQL resource.
>From the LDAP mapping you have provided, I can see several anomalies:
1. the external attribute 'uid', usually defined by default as the key (see
above) for LDAP resources, is mapped to the internal derived attribute
'uid'
2. the row flagged as 'AccountId' is actually mapped to external attribute
'uid' - this makes double mapping for the same external attribute and leads
to inconsistencies
3. the internal attribute 'uid' is mapped to three distinct external
attributes: this is problematic for synchronization
I'd suggest you to make this LDAP mapping much simpler by removing all
mappings involving any (internal / external) uid.
Finally, please change the AccountLink to
'uid=' + username + ',ou=people,dc=digipro,dc=com'
That should work.
--
View this message in context: http://syncope-user.1051894.n5.nabble.com/An-odd-work-around-for-stubborn-derived-attributes-tp5706896p5706899.html
Sent from the syncope-user mailing list archive at Nabble.com.
Re: An odd work-around for stubborn derived attributes
Posted by Edward Siewick <es...@digipro.com>.
On 03/19/2013 03:46 AM, Francesco Chicchiriccò wrote:
> On 19/03/2013 02:39, Edward Siewick wrote:
>> Hi.
>>
>> Just a quick note to report some unexpected behavior (v1.0.6).
>>
>> I've been tinkering with two resources, a MySQL database and an
>> openLDAP directory with inetOrgPerson and posixAccount schema.
>>
>> The only guaranteed unique field from the (OrangeHRM) MySQL resource
>> is the key field, emp_number (an int data type). Within Syncope's
>> Resources / Schema Mappings for the resource, the key field isn't
>> provided as an option in the pulldown for External Attributes. It
>> does get set to Username, however.
>
> I understand that emp_number is not shown in the dropdown, and this
> sounds strange: could you please provide the details of your DB Table
> configuration and the database table schema from MySQL? And maybe also
> a screenshot from the admin console, in the schema mapping window?
>
> What does "It does get set to Username, however" mean exactly?
>
>> Now, the openLDAP wants a uid as a guaranteed unique value. (More
>> precisely, it wants a DN that happens to include the uid.)
>
> That's why LDAP (and LDAP-like as Active Directory) resources need an
> additional "Account Link": for generating a correct DN.
> What's the Account Link you've provided for OpenLDAP?
>
> Normally, for LDAP, one should flag Syncope's username as AccountId in
> the mapping + provide an account link as JEXL expression, including
> uid; something like
>
> 'uid=' + username + ',ou=People,o=isp'
>
> Could you please provide a screenshot of the mapping of this OpenLDAP
> resource?
>
>> The derived attribute (uid => username) in Schema was still not
>> working out for me. So I decided to poke at this by adding to the
>> MySQL resource's schema mapping uid => emp_firstname (Internal
>> Attributes => External Attributes) which I'd expected would produce a
>> string value in the uid fields. And, surprise! The derived attribute
>> (uid => username) instantly popped to life. The next run of the sync
>> task with the MySQL resource produced a complete set of (numeric) uids.
>>
>> To test this again, I added uidNumber => username as another derived
>> attribute. Again, it wouldn't populate automatically. I added
>> uidNumber => emp_smoker (a smallint in the MySQL schema.) The column
>> populated at the next sync with the MySQL resource.
>
Francesco,
A few screen shots and a listing of the MySQL table structure are attached.
The emp_number from the mysql table is used as the Username in the Users
listing window.
Edward
Re: An odd work-around for stubborn derived attributes
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 19/03/2013 02:39, Edward Siewick wrote:
> Hi.
>
> Just a quick note to report some unexpected behavior (v1.0.6).
>
> I've been tinkering with two resources, a MySQL database and an
> openLDAP directory with inetOrgPerson and posixAccount schema.
>
> The only guaranteed unique field from the (OrangeHRM) MySQL resource
> is the key field, emp_number (an int data type). Within Syncope's
> Resources / Schema Mappings for the resource, the key field isn't
> provided as an option in the pulldown for External Attributes. It does
> get set to Username, however.
I understand that emp_number is not shown in the dropdown, and this
sounds strange: could you please provide the details of your DB Table
configuration and the database table schema from MySQL? And maybe also a
screenshot from the admin console, in the schema mapping window?
What does "It does get set to Username, however" mean exactly?
> Now, the openLDAP wants a uid as a guaranteed unique value. (More
> precisely, it wants a DN that happens to include the uid.)
That's why LDAP (and LDAP-like as Active Directory) resources need an
additional "Account Link": for generating a correct DN.
What's the Account Link you've provided for OpenLDAP?
Normally, for LDAP, one should flag Syncope's username as AccountId in
the mapping + provide an account link as JEXL expression, including uid;
something like
'uid=' + username + ',ou=People,o=isp'
Could you please provide a screenshot of the mapping of this OpenLDAP
resource?
> The derived attribute (uid => username) in Schema was still not
> working out for me. So I decided to poke at this by adding to the
> MySQL resource's schema mapping uid => emp_firstname (Internal
> Attributes => External Attributes) which I'd expected would produce a
> string value in the uid fields. And, surprise! The derived attribute
> (uid => username) instantly popped to life. The next run of the sync
> task with the MySQL resource produced a complete set of (numeric) uids.
>
> To test this again, I added uidNumber => username as another derived
> attribute. Again, it wouldn't populate automatically. I added
> uidNumber => emp_smoker (a smallint in the MySQL schema.) The column
> populated at the next sync with the MySQL resource.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/