[Building Sakai] local accounts with provider authn [was: User Providered IDs and LDAP and ?]
Will Humphries
whumphri at vt.edu
Thu Jul 30 09:08:12 PDT 2009
I'm replying to this old but related thread with a question on
implementing the 'strict local attributes with provider authn' strategy.
We've historically followed the steps in part 4 of Daniels reply, namely
extending JLDAPDirectoryProvider to return null for findUserByEmail(),
getUser(), getUsers(), and getUserExists(). We've discovered that if a
user goes to Site Info->Add Participants, and enters a username that can
be found in our LDAP but is not in Sakai, a provided account is created.
This depends on a positive return from getUserByEid().
I'm experimenting with overriding 'public boolean getUserByEid(String
eid)' to return null as well, and things *seem* to be working ok - users
can't create provided accounts through Site Info->Add Participants, and
very limited testing shows local users can still log in, add other local
users to sites, and 'do stuff.' Before I bother to do more comprehensive
testing, I'd like to know what other developers think. Is this a
reasonable approach, or is there a case where a null return from
getUserByEid() will lead to inconvenience, chaos, and/or horror? Thanks
for any feedback!
-Will
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