User Providered IDs and LDAP and ?

[kfaella]

[kfaella]

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

[Kevin P. Foote]

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"

[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@...
> -> 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"

_______________________________________________
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"

[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@...
-> > -> 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"
->
_______________________________________________
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"

[Daniel McCallum]

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@...
>>> -> 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"

_______________________________________________
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"

[Daniel McCallum]

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@...
>>>> -> 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"
> _______________________________________________
> 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"

[Will Humphries]

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@...
>> -> 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"
>>    
> _______________________________________________
> 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"