[Building Sakai] User Providered IDs and LDAP and ?

[Kevin P. Foote]

Dan 

Very nicely stated.. and I'd agree with all points. :-) 
(I for one think your jldap portions are magic and am glad that they just 
work, no hassles) 

My only point (which might have been blundered) was that you don't need to 
populate the sakai_user table (or sakai_user_id_map table) with your 50k+ 
user base to get CM to function. 

------
thanks
  kevin.foote

On Fri, 17 Apr 2009, 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"
->