Integration: Users and Groups

1. Integration: Users and Groups Mark J. Norton Nolaria Consulting

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

3. The Sakai Framework 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. Portal Velocity/JSF/RSF Tools Application Services Framework Services Kernel

4. 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. 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. Providers • 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. Integration Points • Currently (as of 2.4) Sakai has four key integration points: • User UserDirectoryProvider • Group GroupProvider • Course CourseManagementProvider • Content File System Mapping User Group Course Content

8. User / Person User Integration • 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. org.sakaiproject.user.api.UserDirectoryService

9. Users User Integration • 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.

10. User Integration 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.

11. Key User Information User Integration • 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.

12. User Directory Provider User Integration • 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

13. Policy Functions User Integration • 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();

14. Information Transfer User Integration • 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);

15. Implementation Strategies User Integration • 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.

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

17. Group Integration 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.

18. The Authorization Model Group Integration Group Role Collection The Authorization Triple Person Function Entity

19. Authorization Groups Group Integration • 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.

20. The Group Provider Group Integration • 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); } New for Sakai 2.4!

21. Authz Group Roles Group Integration • 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.

22. Identifiers Group Integration • 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.

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

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

25. Examples – Group Provider • Mark - MIT