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

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

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.

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.

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

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

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

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

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.

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

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).

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.

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?

Ideas? http://confluence.sakaiproject.org/confluence/ http://groups.google.com/group/sakai-kernel/ Ray Davis <ray@media.berkeley.edu>