Re: [Building Sakai] User Providered IDs and LDAP and ?

> 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@...
>>> -> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>> -> -> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe@... with a subject of
>>> "unsubscribe"
>>> -> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe@... with a subject of
>>> "unsubscribe"