Presentation is loading. Please wait.

Presentation is loading. Please wait.

8th Sakai Conference4-7 December 2007 Newport Beach Integration: Users and Groups Mark J. Norton Nolaria Consulting.

Similar presentations


Presentation on theme: "8th Sakai Conference4-7 December 2007 Newport Beach Integration: Users and Groups Mark J. Norton Nolaria Consulting."— Presentation transcript:

1 8th Sakai Conference4-7 December 2007 Newport Beach Integration: Users and Groups Mark J. Norton Nolaria Consulting

2 1Overview Architectural Review –The Sakai Framework Integration Topics: –User Integration –Group Integration –Course Integration (not covered) –Content Integration (not covered)

3 2 The Sakai Framework Velocity/JSF/RSF Tools Application Services Portal Framework Services Kernel Most Sakai integration will happen at the services level of the framework, either by replacing the default implementation with a new one, or by using a provider.

4 3 Enterprise Integration Sakai integration happens in the Sakai services and mostly in kernel services. All Sakai services are implemented against a published API to specifically enable integration. In some cases, additional integration support is included in Sakai service implementations (providers).

5 4 Integration Approaches Sakai offers four main approaches to campus integration: –Service replacement –Providers –Web Services. –Synchronization tools. This talk is focused on the User and Group Providers

6 5Providers Providers are a way to “look someplace else” for data. These other place can be a service or a database. In general, Sakai databases should only be accessed through services. Database tables are sometimes modified between Sakai releases so using the API is best.

7 6 Integration Points Currently (as of 2.4) Sakai has four key integration points: –UserUserDirectoryProvider –GroupGroupProvider –Course CourseManagementProvider –ContentFile System Mapping User Group Course Content

8 7 User / Person User objects are currently used by Sakai tools whenever information about the current (or other) user is required. Users are managed by the User Directory Service. User Integration org.sakaiproject.user.api.UserDirectoryService

9 8Users The User service is modeled on a directory service an may include user authentication. Sakai includes default implementations against LDAP, but has also be integrated to other user services like CAS. User provides access to identifiers, name, email, user type, etc. User Integration

10 9 User Integration User integration in Sakai is largely accomplished by writing a user provider. The general model is simple: a UserEdit object is passed to a provider implementation. If the user id included is known to the enterprise system, data is filled in. User Integration

11 10 Key User Information The following user information should be part of your integration strategy: –Creation and modification times. –Email address –Display name –Sort name –First and last name –User type Other information can be properties. User Integration

12 11 User Directory Provider This is the User Directory Provider API: public interface UserDirectoryProvider { boolean authenticateUser(String eid, UserEdit edit, String password); boolean authenticateWithProviderFirst(String eid); boolean createUserRecord(String eid); void destroyAuthentication(); boolean findUserByEmail(UserEdit edit, String email); boolean getUser(UserEdit edit); void getUsers(Collection users); boolean updateUserAfterAuthentication(); boolean userExists(String eid); } org.sakaiproject.user.api.UserDirectoryService User Integration

13 12 Policy Functions Some of these provider functions allow the enterprise environment to define policy: These are pretty simple to implement, being booleans. boolean authenticateWithProviderFirst(String eid); boolean createUserRecord(String eid); boolean updateUserAfterAuthentication(); User Integration

14 13 Information Transfer The remaining functions transfer information from the enterprise system of record to Sakai: Note that Sakai often caches this information. boolean authenticateUser(String eid, UserEdit edit, String password); void destroyAuthentication(); boolean findUserByEmail(UserEdit edit, String email); boolean getUser(UserEdit edit); void getUsers(Collection users); boolean userExists(String eid); User Integration

15 14 Implementation Strategies Often, developers will create a private method that updates a UserEdit object. This makes getUser(), getUsers() and findUserByEmail() simple to implement, all being variants of initialization. The other functions tie the user service to your authentication system. User Integration

16 15Examples Let’s hear from people who have done some work with the User Directory Provider: –Ray –Seth –Dan

17 16 Group Integration Groups are widely used in various Sakai services. Most of these services leverage the group structure provided by AuthzGroups. Authorization groups allow groups of users to be defined who share access permissions, usually based on their role. Group Integration

18 17 The Authorization Model Person Group Role FunctionEntity Collection The Authorization Triple Group Integration

19 18 Authorization Groups A user may be a member of a particular authorization group. All users in an AuthZGroup are required to have a role. Each group has a set of permissions. The ability to perform a particular function may be specified by a role or membership of a user in a group. Group Integration

20 19 The Group Provider This is the group provider API: Simpler than a user provider, but also more limited. public interface GroupProvider { String getRole(String gid, String eid); Map getUserRolesForGroup(String gid); Map getGroupRolesForUser(String eid); public String packId(String[] ids); String[ ] unpackId(String gid); String preferredRole(String one, String other); } Group Integration New for Sakai 2.4!

21 20 Authz Group Roles Roles are simple strings in Sakai. Some pre-defined roles are included: –instructor –student –ta –admin –maintain –user Some Sakai application define their own roles and specific installations are free to define new ones. Part of writing a group provider is mapping external roles to known Sakai roles. Group Integration

22 21Identifiers Where a user identifier is passed a parameter, it is the enterprise id. Where a group identifier is passed, it is the enterprise group id. Since some schools use compound group ids (perhaps based on course id), an unpack() function is provided to parse out the group id that Sakai uses. Group Integration

23 22 User Roles for Group Create a Map object which includes pairs of user ids and roles for a given group id. Map getUserRolesForGroup(String gid); Group Integration

24 23 Group Roles for User Create a Map object that includes pairs of group ids and roles for a given user. Map getGroupRolesForUser(String eid); Group Integration

25 24 Examples – Group Provider Mark - MIT


Download ppt "8th Sakai Conference4-7 December 2007 Newport Beach Integration: Users and Groups Mark J. Norton Nolaria Consulting."

Similar presentations


Ads by Google