Sakai Providers
Overview (Sakai 1.5, 2.0, 2.1.x) For Future UC Davis Implentations of Sakai, Summer Session(s) 2006 + please see Current Implementation Strategy child page
The UC Davis' campus and Mediaworks pilot implementations of providers in the Sakai framework follow a similar approach to the University of Michigan, Columbia University, Stanford University, and most closely UC Berkeley. All of these institutions have used the Sakai Providers for integrating campus enterprise Data/Services (e.g. LDAP, DistAuth, Banner, etc) into their Sakai integration(s). SOM and VetMED currently are using different implementations of these providers. The UCD system architecture, with respect to data that is provisioned into Sakai, resembles University of Michigan's current architecture and UC Berkeley's architecture.
Purpose of Providers in Sakai
The purpose of providers within Sakai is to provide external data to the Sakai framework in order to create users, realms, and sites. The three aforementioned providers perform these tasks by querying data sources external to Sakai's internal tables.
Data Sources and Data Provisioning
1. UCDavisUserDirectoryProvider: Provides both the user authentication and user provisioning into Sakai. UC Davis' implementation of Sakai will perform authentication and user provisioning in the following manner:
a. User authentication: Users are authenticated via DistAuth, and are provisioned into Sakai upon login. An initial batch load of users will be performed before auto provisioning will take place.
b. User provisioning: A query of UC Davis' LDAP will provide all the necessary data to Sakai for creation of user accounts.
Class Diagrams: UCDavisUserDirectoryProviderClassDiagram.gifUCDavisUserDirectoryProviderHelperClasses.gif, Activity Diagrams: UCDavisUserDirectoryProviderActivity.gif
NOTE: As of Winter Pilot '06: Due to the recursion that occurs during checking user status in Sakai vs. WebDav access through the provider, the KerberosUserDirectoryProvider will be used as the UserDirectoryProvider until this issue can be resolved. Also, the check to determine if the user is accessing the provider by means of Sakai or through Dav does not seem to be consistent. Therefore, users will be loaded into Sakai until this provisioning can be resolved through the provider. The KerberosUserDirectoryProvider will be only accessed, therefore, when there is a Dav request.
2. UCDavisRealmProvider (aka UCDavisGroupProvider): Associates Sakai roles to users, based on particular sites they are accessing. The realm provider queries necessary Sakai lookup tables (enterprise level roles such as access, maintain, student, etc.) and also Sakai specific authorization roles at the tool level, component level, etc.
a. Enterprise level roles: These will be provided via Grouper, or some other mechanism at the campus level.
b. Sakai specific roles: These will be initially provided by Sakai's internal table data, then moved to a central enterprise level lookup table for campus implementation.
Class Diagrams: UCDavisRealmProviderClassDiagram.gif, Activity Diagrams: UCDavisRealmProviderActivity.gif
3. UCDavisCourseManagementProvider: Provides all course related data from Banner via materialized views, and other school data sources as necessary.
a. Banner materialized views: These materialized views will be real time data that can be directly queried. Materialized views provide the best mechanism for providing real-time data to Sakai because they are isolated from the Banner system during Banner downtime, and are effectively "snapshots" of the current data. These views will be read-only.
Class Diagrams: UCDCourseManagementProviderClassDiagram.gif, Activity Diagrams:
Miscellaneous providers: Other providers may be needed to properly account for other site types, site migration, etc. The need for these providers or services need to be evaluated further.
UC Davis Sakai Provisioning Architecture Diagram
See SVN documentation at:
https://mware.ucdavis.edu/svn/sakai/providers/trunk/AnalysisDocumentation/Providers%20and%20Sakai%202.ppt