Potential service integrations

Owned by Former user (Deleted)
Last updated: Aug 26, 2009Version comment
3 min read

Since we're still working out top-level requirements, by most project management standards we're not ready to try integrating Sling/K2 with an external groups-n-roles service library. (How would we choose one?) However, since Sakai management has expressed interest in the topic and I've already done a lot of the necessary research (including ongoing meetings with some of the most likely project teams), I spent a couple of days running through known options. Cutting to the chase, my recommendations are:

  • Don't try to directly integrate a GnR service component at this point. Whereas some well-established authentication and person directory providers should meet most Sakai 3 requirements, no existing GnR candidate is (A) stable, (B) componentized, and (C) likely to give us what we need out-of-the-box. And it seems unnecessarily complex and risky right now to design extra layers on top of something that isn't already in K2.
  • To support experimental prototyping I'll provide throwaway service implementations as needed, prioritizing speed of delivery – probably mock implementations and implementations built on Sling/Jackrabbit.
  • I'll continue to track progress of likely candidate projects. When we're ready to try integration with an LDAP server, I'll pick whatever approach seems to promise the fastest delivery time.

Candidates

Embedded LDAP library

For authentication integration, domain experts have strongly recommended that Sakai 3 re-use the Jasig CAS library: not only is CAS itself one of the most popular authentication choices, it also embeds a host of integrations with other sources. Along similar lines, Michael Korcuska suggested that I look at embedding an LDAP server. Although LDAP is most ubiquitous for delivering information about individual persons, it's also the most widespread delivery mechanism for information about groups and roles, and any decent server will support a variety of persistence mechanisms.

By far the most popular open source LDAP server is OpenLDAP. That's just a C executable, however. Access has to be handled via the LDAP protocol and we'd always be a client.

Apache Directory (aka ApacheDS) is an LDAP server written in Java, but none of its JAR artifacts cleanly separate group handling from generic directory services.

The overarching issue is that LDAP is a string-based directory protocol. Over time, certain conventional sets of attributes have developed to handle organizational structures and other groups. But de facto standards for group and role handling are still very primitive (as compared to things like the EduPerson attributes), and so we'd need to build a layer on top of LDAP's string-based directory protocol – and at that point we might as well shed the server baggage and just integrate with a client library.

uPortal Groups-and-Permissions

Looks like the project teams changed their minds about breaking this out of uPortal 3 as a separate library. In the release and in trunk, the "groups" package is still embedded in the big uportal-impl JAR. There are obvious gaps around roles and integrations with non-enumerable groups, but at the very least the source should provide some useful hints, since it can pull group information from a locally managed DB, from LDAP, from flat files, or from user attributes.

Development is ongoing here, including another look at Grouper as a potential integration point.

Grouper

Grouper's focus is on centralized management and provision of groups rather than consolidation of multiple sources. It can import from LDAP and it can export to LDAP, but it doesn't handle straight-through merging. It also doesn't seem to support local overrides. Again, there are conceptual gaps around role that I'd rather not deal with right now.

Development is ongoing, the team is much better connected with probable clients than in the past, and so I'll stay involved with its progress.

Kuali KIM

Really focused on Kuali's internal requirements. Out of the (current) box, the only LDAP integration I see is via ACEGI (an older version of Spring Security), and I'd feel more comfortable going to the Spring services directly.

At least one KIM developer has also expressed interest in looking at Grouper again.

eid (Export Import Directory Tool)

Limited, young, and doesn't use LDAP as a source (only as a target).

COmanage

In early development.

OpenRegistry

The goal is enticing – to consolidate multiple sources of person and role – but it's still just a gleam in its momma's eye.

Liferay

The license is OK, but it's basically a closed project with no support for breaking out particular libraries (notably the LDAP community integration).

PerMIT

Meant to be a central campus authz/permission store, not released yet, and MySQL-only. Basically of interest as a way to shake up some assumptions.