Hi Nadia,

The user name mapping is the job of the individual authority.  So, for example, 
the Documentum authority would be responsible for any user name mapping that 
would need to be done prior to looking up the tokens for that user within 
Documentum, and the LiveLink authority needs to do something similar for 
mapping to LiveLink user names.

It turns out that most enterprises that have coexisting repositories of 
disparate kinds make an effort to keep their user name spaces consistent across 
these repositories.  Otherwise, enterprise-wide single signon would be 
impossible.  In the cases where the convention for mapping is ad-hoc (e.g. 
LiveLink), the authority connectors included with LCF were built with a simple 
regular-expression-based mapping feature, which you get to configure right in 
the crawler ui as part of defining the authority connection.  (The online 
documentation doesn't yet have documentation for any of these authorities - my 
apologies.  But you can look in the LaTeX documentation that checked in with 
the source tree and maybe get an idea how it works from there.)

Many repository companies also have added AD synchronization features as their 
products have matured.  Documentum is one such repository, where the repository 
software establishes a feature for operating with AD.  For those repositories, 
we did not add a mapping function, because it would typically be unnecessary if 
the repository integrator followed the recommended best practices for deploying 
that repository.

Hope that helps.
Karl

________________________________
From: ext Nadia Akkari [mailto:[email protected]]
Sent: Friday, April 23, 2010 5:33 AM
To: [email protected]
Subject: authority service and user id mapping

Hi,

I have a question regarding how multiple identifiers for a given user is 
handled in the authority service.

Let say that I want to get the access tokens for the user John Smith against 
all the authority connectors defined in LCF.

Let say that John is known as john.smith in AD, known as j.smith in document 
and so on.

If I'm not wrong, the only parameter used to identify a user in the authority 
service is "username".

I'm wondering how user id reconciliation is performed inside the authority 
service in that case? Is there something done about that or is it a work that 
should be performed externally?

Thks

Nadia


Reply via email to