1. Sakai ID & Access Management
Ray Davis
University of California, Berkeley
ACAMP ID Summit – June 2009

2. What’s an LMS? “Learning Management System”
“Collaborative Learning Environment” =
Collaborative web functionality +
Central maintenance
Higher education
Three things never meant to go together.

3. What is Sakai? A framework A suite Java-based Open source Pluggable
Open source = The product relies on distributed volunteer(ed) labor.
Pluggable = Very decentralized.
Must be not too hard to develop for, not too hard to deploy, and not so awful that users revolt.

4. How is Sakai? Sakai 2 Sakai 3 (WORK IN PROGRESS) Tomcat Spring
Homegrown component / portal system
Anything Java-ish
Sakai 3 (WORK IN PROGRESS)
Apache Sling (Scripting, JCR, OSGi)
“Homegrown” = A nightmare to maintain.
“Anything” = A nightmare to QA.

5. Federated Authentication : LMS
Local accounts
Kerberos
LDAP
CAS
SAML
OpenID
The usual…

6. Federated Authentication : Sakai 2
One integration point
Need to maintain custom code

7. Federated Authentication : Sakai 3
Configurable out-of-the-box support for common options?
Use existing libraries?

8. Federated User Profile : LMS
Merge with LDAP, etc.
Context-specific settings
Context-specific access
* Context-specific settings : filtering by class; role-playing pedagogy
* Context-specific access : class instructors see more data than fellow students

9. Federated User Profile : Sakai 2
Two integration points
Non-centralized profile services
Need to maintain customized code
Basic user data vs. “display name and ID”.
EduPerson not in core.

10. Federated User Profile : Sakai 3
Core support for EduPerson?
Out-of-the-box LDAP integration?
Cross-application profile customization?

11. Federated Authorization : LMS
Application-owned privileges
Installation-specific role definitions
Context-sensitive groups, roles, and permission mappings
Externally-managed groups and roles
LMS targets the same functional space as collaborative web apps, social networking, LAMP tools. Fast development + UX-feature driven + Widely distributed teams = Plug-in-defined permissions.
* Installation-specific roles : "Head GSI" at Cal, "Supervisor" at Cambridge.
"Privileges" as integration interface (does a "Head GSI" edit course assignments?)
* Context-sensitive groups and roles : An instructor in one area, a student in another, a reviewer in a third.
Permission mappings: A student might not be able to edit the blog in one course workspace, but have that duty in a different course workspace.
* Refer to and merge from externally-managed groups and roles : official enrollments, teaching duties, staff positions.
Tightest area of control (student privacy issues; final grades as financial transactions).

12. Federated Authorization : Sakai 2
Complex template-based system
Plug-in-defined permissions, Installation-defined role types, Site memberships and groups, Institutional integration
Customized code often needed
Common administrative tasks unsupported
Conflicts between course sections and site groups
Common adminstrative tasks: Add or upgrade a plug-in. Add an installation role. Change an existing role’s permission mappings.

13. Federated Authorization : Sakai 3
Groups as first-class citizens?
Better merging and reconciliation?
Easier upgrades and fixes?
Out-of-the-box integration with IMS LIS?
With OpenSocial?
With SAML attributes?
With Google Apps Education?

14. Ideas? http://confluence.sakaiproject.org/confluence/
Ray Davis