[Building Sakai] User Providered IDs and LDAP and ?

[Daniel McCallum]

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"