JA-SIG User Directory and Authn

New Concept Please feel free to edit, comment, etc.

Summary

• Current issues that this addresses
  • Authentication and user directory integration is difficult and typically requires custom code
  • Untested code is used and depended on
  • Changes typically require editing of code or config and rebuilding
• Goals
  • Gain functionality and reduce the maintenance costs of Sakai's user directory services by integrating JA-SIG's PersonDirectory library.
  • Gain functionality and reduce the maintenance costs of Sakai's authentication service by integrating JA-SIG's CAS.
• Benefits
  • Use of well-tested and proven framework for authentication
  • Use of an industry standard framework with flexible integration points

Introduction

Integration with campus systems is a frequently mentioned source of dissatisfaction with Sakai. Our legacy user directory and authentication APIs and implementations have never been subject to peer review and are often perceived as unnecessarily difficult. There are no unit or integration tests in place. Even when code exists to integrate with popular enterprise approaches (such as LDAP or Kerberos), such integrations can't be used without editing Sakai source and re-building.

As it happens, another open source Java community in higher education has been handling enterprise integration issues successfully for a while now: JA-SIG. Over time, uPortal and related products have spun off powerful and flexible authentication and user directory support libraries.

The goal of this project is to fix some of Sakai's pressing problems by joining forces with JA-SIG on common integration concerns.

Background

Most of the issues mentioned in the old Enterprise Integration WG home still exist in Sakai 2.4.x.

Leveraging JA-SIG libraries to renovate Sakai's user directory and authentication was first discussed in email following on an umbrella UserDirectoryService JIRA task. Participants included Jason Shao, Daniel McCallum, John Lewis, Andrew Petro, Scott Battaglia, Aaron Zeckoski, Antranig Basman, and Jon Gorrono.

Non-Goal : Sakai's authorization and group services also need a great deal of work and also obviously have some overlap with JA-SIG and industry standard technology. However, given their functional complexity (as compared to the fairly simple UserDirectoryService and UserDirectoryProvider interfaces) and the special (not purely enterprise defined) requirements of an LMS / CLE, Ray suggests taking those modules up later.

Technical overview

First Sakai steps

There's general agreement that we want to separate authentication and user data services as cleanly as possible. (There will always be some connection because the mapping from authentication evidence to user data varies by authentication service. For example, successful Kerberos password-based authentication might lead to an LDAP user data service search on "localKerberosPrincipalString", whereas successful base-Sakai authentication leads to a DB search on EID.)

There's also general agreement that we'd like to replace the current sample-code LDAP and Kerberos providers with more easily configurable versions.

A safe next step would be to create a pluggable class to serve as a bridge from the current UserDirectoryService and UserDirectoryProvider interfaces: a "CompoundUserDirectoryProvider" which can be pointed to an ordered list of user data services and an ordered list of authentication services. Naturally, we'd want some backwards-compatible code there to start with.

Those split service APIs could then be used to get to focused, solid implementations – very likely ones supplied by JA-SIG.

PersonDirectory

JA-SIG PersonDirectory services were separated out from uPortal into a separately managed library (which is now used internally by the CAS project, as well). It comes with configurable LDAP and JDBC implementations, and can merge user data from multiple sources.

• Wiki
• Project site

CAS

Sakai developers have tried to integrate CAS authentication into Sakai as if it was a peer of Kerberos authn, DB-based authn, JAAS authn.... However, CAS is itself a common integration point to those and other authentication handlers. If we handed off authentication duties to CAS services deployed as an integral part of the Sakai framework, we'd get all those integrations for free, and possibly gain new-or-improved functionality from framework-embedded SSO as well.

Email from Andrew Petro, 2007-09-10

Andrew, feel free to edit!

I am proposing that uPortal (and now Sakai) replace all forms of authentication with CAS authentication. The idea is that uPortal just use CAS. Always use CAS. Assume CAS. The way you authenticate to the portal, from the perspective of the portal, is via CAS. There is no other way to authenticate to the portal.

And then uPortal would happen to ship with a ready to rock and roll CAS 3.1.x webapp that is properly configured to authenticate usernames and passwords against those uPortal-internal local accounts.

Deployers then have a few options. They can instead point it at their real CAS. They can configure this uPortal-specific CAS instance to authenticate users in whatever ways they want (uPortal-internal accounts, OpenID, even delegation to their CAS server). This can be simple, but here's the kicker: it can fluidly get complicated. Have local accounts namespaced differently from institutional PubCookie accounts, and also have some OpenID use cases running around? CAS can accomodate implementing that workflow via its web flow and authentication handler configuration, and it is better poised to support that complexity than is uPortal, since CAS is an entire project dedicated to this problem of how to deliver user sign in experiences, whereas uPortal is trying to be a portal.

You can "just use CAS" and still implement Sakai-local user accounts. The advantage is that you have a fluid and continuous runway to introduce more sophisticated authentication stories.

While it's not trivial "out of the box" to actually solicit the username and password in a UI provided by Sakai rather than delivering a button that sends you to the CAS server, that may be a good thing – presenting credentials to different login user experiences is arguably a security "anti pattern" that CAS can help to alleviate. However, if you really have that use case, implementing embedded login forms while still "just using CAS" is trivially implemented.

Again, this approach need not be threatening to folks invested in SSOs other than CAS. It's a matter of whether you regard the CAS instance as an implementation detail of Sakai (in which case you would "PubCookiefy" or "Crowdify" or "Shibbolize" or "Kerberize" this embedded CAS server and then ignore it) or whether you regard this as an opportunity to introduce SSO to Sakai and then in a natural expansion to the applications linked from and linking to Sakai and pretty soon you have compelling enterprise SSO. Note that even if you go the implementation detail of Sakai approach, you might choose to CASify strategically certain applications related to Sakai. Since Sakai is IFrame-happy, transparent SSO across applications can actually help a whole lot with IFraming in external tools and having it "just work". Likewise, it may be that Sakai can take advantage of CAS Proxy Ticket authentication to securely go get interesting student information.

Conversations

More to come as I get permission to quote from emails or I rewrite what was said there....