Group Providers and Eids

As part of my upcoming workshop on integrating Sakai into enterprise environments, I'm writing a pair of user and group providers that will access a dummy student information system implemented as a set of MySQL tables. Conceptually, these providers are simple: they enable Sakai to sorta "look over there" for information about a user or a group.

Of the two, the user provider (UserDirectoryProvider) is more powerful. A UserEdit object is passed to the provider (in several of it's methods) which is completed by the provider implementation, presumably drawing on a enterprise-wide information service such as LDAP, CAS, PeopleSoft, etc. Using the user provider, you can pretty much use an external system of record to maintain your user definitions.

However, this is not the case with the group provider. The group has two important methods:

getUserRolesForGroup -- pairs of user ids and roles for a given group.
getGroupRolesForUser -- pairs of group ids and roles for a given user.

For this to work, however, the group must already be established on the Sakai side of things. In part, this is because the group provider is really only getting information about members of groups (and their roles) or determine which groups a user is a member of. It is used to implement authorization on the Sakai side, and thus requires that sites be defined in Sakai, not elsewhere.

Earlier in the year, I developed a way to access Sakai tools from MIT's Stellar course management system. One of the big stumbling blocks was that authorization was defined on the MIT side of things and was required to remain there. Further, there were thousands of sites defined in Stellar that (in theory) would have to be provisioned in Sakai for the tool integration to work.

I got around this problem by adding a few new methods to the group provider:

• isAllowed() - an authorization check.
  
• isGroup() - check to see if this group is known to the enterprise
  
• getAllowedFunctions() - get the list of allowed functions.
  

with some modifications to the BaseAuthzGroupService code, these functions allowed authorization to be moved external to Sakai.

I have the code around, if people are interested. The modifications to the authz group implementation was such that if external authorization wasn't implemented, it would fall through to the current database solution. Is this a useful thing to include in a future release?

Enterprise Ids

Josh Holtzman recently lamented that he was bit repeatedly by Ids vs Eids while developing providers for the new course management service. Even in the existing providers, the use of these two identifiers is confusing. It's quite clear what the difference is: the user id is the Sakai identifier, the Eid is the enterprise identifier. They could be the same, since user ids can be supplied when the user is created, but I believe we are trying to establish a practice of letting the system assign a GUID.

Regardless, I also had quite a bit of trouble with my test harness and use cases trying to get Sakai to understand the equivalence of a given user id and her eid. Likely this is due to my lack of understanding, but how DO people figure this out? There is some documentation, but frankly, it doesn't help much when it's time to code.

Ids and Eids will figure prominently in my up coming workshop. It's something that developers need to have a good understanding of if they are going to implement providers or do other kinds of system integration with Sakai.

- Mark