BOF Session: Using Different IDs for Login ID vs. Enterprise ID
BOF Description: Some institutions need a user ID for login/authentication purposes that is different from the ID used to uniquely identify the user within the enterprise. Sakai currently assumes these are the same (the Sakai "EID"). This BOF will cover how institutions deal with this today and how Sakai could better handle this in the future.
This session is scheduled for Wednesday, June 13th, at 16:00 (4:00pm) in the Basel conference room.
This topic came up in a recent Sakai Dev mailing list discussion. Some requirements (and some partial solutions) were discussed by Georgian Tech, UC Davis, and UC Berkeley. From that discussion, here is Ray Davis' great description of the issue:
Back before Sakai 2.0, we analyzed the cross-institutional user ID needs and found that the framework needed to support at least three different person IDs.
- Enterprise integration ID : What ties user data together across different software systems. This might be human-understandable or it might not. But it shouldn't be in itself a huge confidentiality risk, and it will probably be difficult to change. (Both of which are good reasons for it not to have much meaning to human beings!)
- Display ID : A disambiguator which makes human sense. At a large school like UC Berkeley, there can be a surprising number of duplicate names even for a single class. At Berkeley, instructors tend to use student ID as a disambiguator; at MIT, an institutional email address is used. The important point is that this is for
people, not for software.
- Authentication ID : What the user types in as a login identifier is determined by the particular authentication service. It may be the same as the user's display ID which is shown in roster lists (but it's not the same here at Berkeley), or it may be the same as the service integration ID which ties everything together in software (but it's not the same here at Berkeley), or it may be a magnetic keycard, or a retinal scan, or..... The point is that it can be thrown away after authenticating.
By default, standalone Sakai should have Login ID = Display ID = Service integration ID. In some institutions (such as U. Michigan) they might continue to all hold the same value. In most institutions, at least two of them would be equal. In some institutions (such as UC Berkeley), they would all be different.
Unfortunately, this requirement doesn't seem to have been fully understood. The BaseUserDirectoryService now provides an "eid" field for user objects, and it also includes a "user" argument in the API it uses to authenticate. However, as implemented, that argument is generally left null, and therefore the institutional authentication service can't send the proper EID (or any other data) back to Sakai.
Based on my first look at the code, I hypothesize that a good solution would be for the BaseUserDirectoryService to give the authentication service an empty (rather than null) user data holder, and base its later code path on what fields have been filled in by the authentication call. This would also let user directory providers
avoid unnecessary duplication of labor in the case where authentication has its hands on the other data usually obtained by a "getUser(UserEdit)" call.
Unicon recently helped implement an approach to this at Georgia Tech. From that experience, we agree that some changes to the Sakai User framework itself could make this whole issue much easier to deal with and we look forward to facilitating a discussion about it and coming up with a good community solution to this need.