[Building Sakai] User Providered IDs and LDAP and ?
Daniel McCallum
dmccallum at unicon.net
Fri Apr 17 11:43:40 PDT 2009
UserTypeMappers are actually set on SimpleLdapAttributeMapper, not
JLDAPDirectoryProvider. Sorry for any confusion.
- Dan
Daniel McCallum wrote:
> 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"
> _______________________________________________
> 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"
More information about the sakai-dev
mailing list