1. Sakai Authentication and Directory Architecture for 1.0 and Beyond A response to an E-Mail by Albert Wu and Thomas Bush 8/28/2004 Charles Severance

2. Sakai Tools Sakai Legacy API Implementations JK_connectorWSRP Portals Browsers Sakai API Implementations Plugin Form Based Auth Directory Plugin Enterprise Info Enterprise Info Architecture for 1.0 and 2.0 Apache Plugin OSID

3. Sakai Identity and User Directory Information Approach Sakai must know several things about a person –Basic identity (csev) –Directory Information (first name, Last name, E-Mail, etc) Sakai is very flexible and easily configured to accept information from external sources for either or both of these elements

4. Basic Identity WebISO identity provider –Sakai can be configured to take identity from a WebISO source –Sakai is protected by an apache mod and Tomcat gets identity through the JK connector. The WebISO identity is the Sakai identity and this identity is placed in the framework and all of the Sakai API implementations for use by Sakai tools transparently to all tools and services. Form based Identity –Without WebISO, Sakai uses its own internally generated form- based identity capability which consults the UserDirectory Service for Id/PW information. The UserDirectory service may or may not consult a plugin for this information.

5. Directory Plug Ins The Sakai UserDirectory Service by default simply consults its own internal database for identity and directory information Plugins are used to change this behavior and cause Sakai to consult various sources of enterprise information. There are several choices –The plugin takes responsibility for any subset of identity,password, and all directory information In addition Sakai can be configured to trust the plugin exclusively for all information or to use the plugin to load information into Sakai structure so that authentication can be done locally when the external source is not available.

6. Common Configurations Out of the box - Form based authentication, no plugins, all users are managed and stored internally WebISO used for identity, user directory info stored internally in Sakai. Form based authentication, plugin used for id/pw (say Kerberos) and plugin used for directory info (say LDAP) Form-based authentication, external id/pw validation, local storage of directory information, and local caching of password information (Grid-Portal approach using myproxy) Hybrid - support for both form and webiso authentication with id/pw/directory coming from a combination of plugins and internal data.

7. Time View of Features In Sakai 1.0 –Much of the infrastructure is based on the legacy service implementations so plugins must be built to plug into the legacy implementations –http://cvs.sakaiproject.org/release/1.0.rc2/javadoc/org/sakaiproject/service/l egacy/user/UserDirectoryProvider.htmlhttp://cvs.sakaiproject.org/release/1.0.rc2/javadoc/org/sakaiproject/service/l egacy/user/UserDirectoryProvider.html Between Sakai 1.0 and 2.0 –WSRP support will be added (assuming all goes well) as a mechanism for interacting with Portals. This will also provide identity like WebISO –The Sakai API (not legacy) implementations will be developed and the plugins will be to these implementations –Additional plugin types will be developed based on the OKI OSIDs It would be possible to build a SakaiPlugin which implements AuthUdp, CompleteUdp, PiggybackUdp chich consumes an OKI OSID implementation (RC6 or 2.0) By Sakai 2.0 OSIDs as plugins will be directly supported by a wide range of APIs (Authentication, Directory, Authorization, DR, etc…)