[Building Sakai] User Providered IDs and LDAP and ?

[Daniel McCallum]

If by "status" you mean "type", then your expectations are correct. 
Sakai will use the user's type to generate a MyWorkspace on first login 
and subsequently for contextless permissions (mainly just site.add).

As to where Sakai gets the user's type, that's up to you. If your users 
are stored locally, it will be read from SAKAI_USER.TYPE. If your users 
are provided, you can specify how the provider calculates the type by 
plugging in a strategy (JLDAPDirectoryProvider#userTypeMapper). Several 
strategies ship out of the box. The readme and javadoc should have more 
info. But I think you've already experimented with UserTypeMappers? Did 
you give up on this approach for some reason? Maybe LDAP doesn't 
actually have the attributes or structure you need to calculate a user 
type for Sakai?

For your SIS/CM integration, is the issue that your SIS feed references 
employee numbers rather than login tokens (EIDs)? If so, it is unlikely 
that the correct solution is setting SAKAI_USER_ID_MAP.USER_ID = 
:emplid. Employee IDs aren't actually your database keys; you're just 
running afoul of the fact that users have multiple "enterprise IDs" but 
Sakai only supports one. A better option is implementing a mapping layer 
for converting emplids to EIDs, which (for better or worse) is what I 
believe the CM APIs expect to use to reference users. One option for 
doing this would be to write a patch or extension to the CM synchronizer 
to perform the mapping OOB, e.g. perhaps with a direct LDAP search if 
the mapping is available in LDAP. If the mapping is available in LDAP, 
you could also define a mixin interface for the UDS and UDP for looking 
up user's by arbitrary property (not exactly trivial, but reasonably 
straightforward if you have Java talent in house). Or, if you're loading 
all your users into your SAKAI_USER* tables and you're under time and 
resource pressures, you should store the emplid in SAKAI_USER_PROPERTY 
and you could then use a direct SQL query to perform the emplid->EID 
mapping. There might be other options for adding an abstraction between 
the GroupProvider and the CM APIs such that CM EIDs needn't match User 
EIDs, but I don't have a good feel for how feasible that would actually be.

- Dan



Katherine Faella wrote:
> Dan, Kevin and all,
> 
> Thanks for your help.
> I have some follow up questions and comments that might help explain 
> where my confusion lies. We are only a couple of months into Sakai and 
> have only a couple more months to get this going so all the help you can 
> give is greatly appreciated!!!
> 
> The reason we feel/felt the need to pre-populate our users is because we 
> don't know where their status is set, ie students vs faculty/staff.  
> Sakai needs to know this at logon so the correct !user.template is 
> selected - is this correct? If so, how do we ensure this?  We also see 
> the need to get our USER_IDs (emplids) into a record for each 
> student/faculty so  they can match up with the courses and rosters we 
> will be importing.  We have not found documentation telling us where 
> this is kept (and how to get it into Sakai) and thought perhaps this 
> happened in SAKAI_USER_ID and SAKAI_USER_ID_MAP. (I have to admit here 
> to some frustration here with the person assigned here to get users 
> imported.  She hasn't tried to look for any Sakai method, instead just 
> wanting to write directly into the database.)  So, is there some 
> documentation that would help me with my confusion about users and their 
> properties?
> I am not committed to pre-populating but can not  figure out what other 
> path to take.  Univ of Delaware (as well as Steve Swinsburg) has 
> graciously shared their CM implementation details with us.  And we are 
> using that as a starting point so have managed to load courses and 
> rosters but haven't figured out how to tie this in with our users.  As 
> you no doubt know, there is a steep learning curve in all this and many 
> things have conspired against us here at URI, leaving us with a short 
> time table and only a couple of worker bees to make a total cutover from 
> a pretty heavily used WebCT to Sakai by this Fall!  
> Thanks for all the help so far,
> Kathy
> 
> 
> 
> Daniel McCallum wrote:
>> Katherine, Kevin
>>
>> 1) EID vs USER_ID -- Pre-populating SAKAI_USER_ID_MAP is not a 
>> problem. Changing EID values in that table is also mostly OK, but 
>> might not be respected by all tools. _Changing_ USER_ID values in that 
>> table _is_ a problem. USER_ID is a database artifact and is 
>> effectively used as a foreign key in other tables. So there's nothing 
>> wrong with using your employee IDs as USER_IDs, per se, as long as 
>> they are unique and immutable. You will be in for disappointment, 
>> though, if your process involves creating users via Sakai, then trying 
>> to change their USER_IDs in the database later. IMHO, you should treat 
>> employee IDs as user attributes (served from LDAP or stored locally in 
>> SAKAI_USER_PROPERTY) rather than as the user's database key.
>>
>> 2) Pre-Populating SAKAI_USER -- This is fine, but keep in mind that 
>> for the purposes of sourcing attributes, a user is either local or 
>> provided. There is no merging of attributes across the Sakai database 
>> and your LDAP tree. Also keep in mind that if you're using the vanilla 
>> LDAP provider, Sakai prefers local attributes (there are special cases 
>> where Sakai could be configured prefer provided attributes, but only 
>> at authentication time). So if a user is pre-loaded into SAKAI_USER, 
>> Sakai will not check LDAP for that user's attributes. It only makes 
>> sense to do so, then, if you only want to use the LDAP provider for 
>> authentication.
>>
>> 3) Authentication -- Hard to say why your users are not able to 
>> authenticate any longer. Sakai will attempt LDAP authN first, if the 
>> authenticateWithProviderFirst flag is set on the provider. If that 
>> flag is not set or provider authN fails, Sakai attempts local authN. 
>> Failing that, Sakai falls back to provider authN unless 
>> authenticateWithProviderFirst was set. There's not much logging in the 
>> UserDirectoryService to tell you what's going on, but your best bet is 
>> probably to turn up logging in both the service and provider to get an 
>> idea of whether or not it's even being invoked and when. In 
>> sakai.properties or local.properties:
>>
>>   log.config.count=2
>>   log.config.1=DEBUG.edu.amc.sakai.user
>>   log.config.2=DEBUG.org.sakaiproject.user.impl
>>
>> If you'd like to send your logging output to me or to the list, I'd be 
>> happy to have a look.
>>
>> 4) Strict Local Attributes with Provider AuthN -- I.e. do not allow 
>> authN or attribute lookup unless the user's account already exists in 
>> SAKAI_USER. It is awkward to do this, so the first question I think 
>> should be the classic: "Why?". But assuming you have a good reason, 
>> what you need to do is prevent the provider from responding positively 
>> to findUserByEmail(), getUser(), getUsers(), and getUserExists(). The 
>> easiest way to do this at the moment, I think, is to write a subclass 
>> of JLDAPDirectoryProvider which overrides those methods to return 
>> false/empty/null results.
>>
>> Hope that helps.
>>
>> - Dan
>>
>>
>>
>> Kevin P. Foote wrote:
>>> Katherine -
>>> There are many way more experienced on the list than I with this but In
>>> a simple sysadmin veiw here's a shot of explaining a bit of what can
>>> work. (I chose this route)
>>>
>>> Our sakai is integrated with our Ldap system (MSAD) via the jldap
>>> provider within sakai. This works great! If a user can login via your
>>> ldap they get a sakai account provisioned right away on the system - 
>>> this is where the sakai_user_id_map table comes in to play ..
>>> OK we have our full user base covered now.
>>>
>>>
>>> Now we want courses.. and the rosters that go along with a given course.
>>> This in the sakai universe is called CourseManagement (CM). There's tons
>>> of wiki docs and dev threads on the subject.
>>> I chose to use the sample XML based approach to get my 3k+ courses in to
>>> sakai. The way this is done is an xml file is read nightly by sakai 
>>> and course/instructor/membership is pulled into the CM_xxxxx backing 
>>> tables.
>>>
>>> One reason I did this is to use the default 
>>> CourseManagementGroupProvider (internal to sakai) rather than try to 
>>> use/create another.
>>> The jist of CM is that the CM tables are where you set courses and their
>>> rosters. If an instructor wants to provision his/her course the data
>>> gets pulled from there otherwise the data does not impact the other
>>> areas of sakai (ie: sakai_user table etc).
>>>
>>> Hope that helps a bit...
>>> ------
>>> thanks
>>>   kevin.foote
>>>
>>> On Thu, 16 Apr 2009, kfaella wrote:
>>>
>>> -> -> Hi all,
>>> -> -> Sorry about the previous blank message, it was an errant enter!
>>> -> -> I seem to be almost totally confused here and could use some of 
>>> your clarity
>>> -> and expertise.
>>> -> -> I am working on a test instance of Sakai 2.5.3.  I have 
>>> successfully
>>> -> integrated Ldap authentication into this server (including patches
>>> -> SAK-14632, the OpenLdapIDEid patch and most recently SAK-14648 
>>> which I am
>>> -> thinking now I do not need).   -> -> A co-worker is looking into 
>>> the Course Management tools for adding courses,
>>> -> rosters and users.
>>> -> -> In an attempt to move things along, she has zapped all the 
>>> student and
>>> -> faculty users into the tables sakai_user and sakai_user_id_map.  
>>> She has
>>> -> made the EID the correct id to authenticate with and made the 
>>> User_id field
>>> -> our employee id (nine digit number).  All faculty/staff she marked
>>> -> 'registered' and students 'null' for account type.  About the same 
>>> time (big
>>> -> mistake), I also played with setting the account type from my ldap 
>>> server. -> Unfortunately, one of these actions (mine or hers) has 
>>> left me unable to
>>> -> login with any account but admin.  I have looked over the stuff I  
>>> did and
>>> -> think I have reverted to previously working code but an attempt to 
>>> login
>>> -> does not cause any calls to the ldap server! even for ids that 
>>> previously
>>> -> worked.
>>> -> -> Is it possible that filling in the sakai_user and 
>>> sakai_user_id_map tables
>>> -> along with changing the user_ids to our emplid causes this 
>>> condition?  Can
>>> -> anyone shed any helpful light here?
>>> -> -> Also,  we are thinking that we will pre-populate all users (and 
>>> their info)
>>> -> from our SIS.  Can I change ldap provider code behaviour so that 
>>> if the id
>>> -> attempting logon is not already in Sakai they can be prevented 
>>> from logging
>>> -> in and self-creating? (unless of course it is id "admin" or a 
>>> guest email
>>> -> address)
>>> -> -> Any and all help and ideas welcome.  -> -> Katherine Faella
>>> -> University of Rhode Island
>>> -> University Computing Systems
>>> -> Kingston, RI  02881
>>> -> -> -> -- -> View this message in context: 
>>> http://www.nabble.com/User-Providered-IDs-and-LDAP-and---tp23082904p23083290.html 
>>>
>>> -> Sent from the Sakai - Development mailing list archive at Nabble.com.
>>> -> -> _______________________________________________
>>> -> sakai-dev mailing list
>>> -> sakai-dev at collab.sakaiproject.org
>>> -> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>> -> -> TO UNSUBSCRIBE: send email to 
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of 
>>> "unsubscribe"
>>> -> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to 
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of 
>>> "unsubscribe"