Creating your own GroupProvider in Sakai

In Sakai, the GroupProvider provides user / role membership in a group, from an external system. We are currently involved in a project that implements GroupProvider to allow the members of a federated administration workspace to manage the worksites created inside that federated administration worksite. More on that in future posts. Here I'd like to briefly give a few pointers about implementing your own GroupProvider.

I'm doing this against Sakai 2.5.3.

First of all, read Chuck Severance's blog post about creating an allhands group: http://www.dr-chuck.com/csev-blog/000205.html.

The source code that Chuck is referring to is in your Sakai source tree under [SAKAI_SRC]\providers\allhands You'll find a number of very useful examples in [SAKAI_SRC]\providers, that I wish I would have found earlier.

Some of the information in Chuck's post is outdated. First of all, Sakai now ships with a GroupProvider out of the box and since there can only be a single GroupProvider, the out of the box version has to be disabled. Secondly, you can't manually change the Provider ID in your worksites realm anymore, because the provider ID will be checked by the CourseManagementService configured. The latter is an undocumented feature that I had to find out by debugging.

Fortunately, both the GroupProvider and the CourseManagementService can be configured in Sakai properties. This is contrary to popular belief that both have to be beans with ids that match the fully qualified name of the interface. The fact that you can do your configuration in sakai.properties is good news, because if the configuration did involve creating beans with the proper ids, that would mean disabling the GroupProvider and CourseManagementService beans that ship out of the box. That would be Bad News because it requires you to patch the Sakai source code (Spring configuration is source too, you know), which I try to avoid as much as possible.

So to set up your own GroupProvider, do the following:

• Implement the GroupProvider interface.
• Configure a bean in the components.xml file of your pack that sets up your GroupProvider as a singleton. Give it any id you like (but NOT org.sakaiproject.authz.api.GroupProvider). I will refer to this id from now on as [your provider id].
• In sakai.properties add this line:
  org.sakaiproject.authz.api.GroupProvider=[your provider id]

This sets up your GroupProvider, but introduces a problem. When you try to change the realm using the realms tool, doing so will fail because the realms tool will consult the CourseManagementService to ask whether it knows the Provider ID that you supply. This is a bit strange, really, because the tool aparently assumes a particular implementation of the GroupProvider. Moreover, if there is no CourseManagementService configured (which is the case in the 2.5.x-cafe branch), editing the realm will fail entirely.

Luckily, the course management service can be configured in the same way that the GroupProvider is configured: using sakai.properties. So to set up your own CourseManagementService:

• Implement a dummy CourseManagementService. It doesn't have to do anything.
• Configure a bean in the components.xml file of your pack that sets up your CourseManagementService as a singleton. Give it any id you like (but NOT org.sakaiproject.coursemanagement.api.CourseManagementService). I will refer to this id from now on as [your cms id].
• In sakai.properties add this line:
  org.sakaiproject.coursemanagement.api.CourseManagementService=[your cms id]

That should do it. What exactly my GroupProvider does, is the subject of my next post.

Note: to get this working on the cafe version, the providers project should be deployed also.