This is a set of proposed changes to a very core API – UserDirectory services – so I would like folks to take a look and comment before work gets started. Take a look at the JIRA for more detail:
\nhttp:\/\/bugs.sakaiproject.org\/jira\/browse\/SAK-13671
\nThe basic idea is to make it so we can have enterprise IDs from multiple sources – probably the best use case is if you wanted to build a friend-like capability using perhaps Radius and OpenID to compliment your local accounts perhaps coming from a campus LDAP\/Kerberos or something. You want to be able to tolerate an account “csev” from any of the three sources – i.e. you don’t want it to be a security hole if the local csev account is a teacher for a course and an account named “csev” shows up from an OpenID or Radius Source – and all of a sudden they are teaching all my courses.
\nSince Sakai has an internal random ID for all users in places like Realm tables, etc – the is a pretty surgical change in terms of data structure. We only record the Enterprise ID (eid) in one table: SAKAI_USER_ID_MAP – I propose to add an ESOURCE column to this table. The EID\/ESOURCE combination is the unique key now for the table.
\nWe leave the column NULL for all accounts on the system and all the current calls to mae new users leave the column NULL – so unless you start adding these users from another Enterprise, nothing changes.
\nIf on the other hand, you come up with some new approach to login – such as Shibboleth or a Radius login – and this login process starts making new users with different ESOURCE values – then these accounts with non-NULL ESOURCE values do not collide with the normal internal and default enterprise users. The accounts “pass in the night” from an AuthZ, etc perspective.
\nThe Changes to UserDirectoryService are pretty simple – anywhere there is an Enterprise ID – we add a new method with one more optional parameter – the Enterprise Source – sourceId – so the methods look like this:
\nOld:
\naddUser(String id, String eid)
\nNew:
\naddUser(String id, String eid, String sourceId)
\nOld:
\nauthenticate(String loginId, String password)
\nAdded:
\nauthenticate(String loginId, String sourceId, String password)
\nWe keep the old methods – they are the same as calling the new methods with a sourceId of NULL.
\nThere is more detail in the JIRA http:\/\/bugs.sakaiproject.org\/jira\/browse\/SAK-13671
\nFeel free to add comments there. Since this touches a pretty core API – I want to make sure that it is well discussed before starting the branch. Assuming we like the general approach – then it can be coded up in a branch and folks will get many more opportunities to review it in detail and comment. I just wanted to get the dialog started early.
\nI have no current plans in this JIRA to change the provider API – for now we can use the providers for the “default” enterprise so nothing needs to change. At some point we might want multiple providers – one for each enterprise source – or perhaps just pass in the enterprise source as a parameter. You are welcome to think this through – I would like to do that as a separate JIRA.
\nThe folks who find this the most useful are those who might want to use Sakai as a platform for software as a service.
\nIf you can think of risks and\/or issues – please bring them up on the dev list or in the JIRA.<\/p>\n","protected":false},"excerpt":{"rendered":"
This is a set of proposed changes to a very core API – UserDirectory services – so I would like folks to take a look and comment before work gets started. Take a look at the JIRA for more detail: http:\/\/bugs.sakaiproject.org\/jira\/browse\/SAK-13671 The basic idea is to make it so we can have enterprise IDs from […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-483","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts\/483","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/comments?post=483"}],"version-history":[{"count":1,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts\/483\/revisions"}],"predecessor-version":[{"id":2590,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts\/483\/revisions\/2590"}],"wp:attachment":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/media?parent=483"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/categories?post=483"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/tags?post=483"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}