8th Sakai Conference

4-7 December 2007Newport Beach

Integration: Users and GroupsIntegration: Users and Groups

Mark J. Norton

Nolaria Consulting

2

OverviewOverview

• Architectural Review– The Sakai Framework

• Integration Topics:– User Integration– Group Integration– Course Integration (not covered)– Content Integration (not covered)

3

The Sakai FrameworkThe 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

Enterprise IntegrationEnterprise 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 ApproachesIntegration 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

ProvidersProviders

• 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 PointsIntegration 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 / PersonUser / 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.

UserIntegration

org.sakaiproject.user.api.UserDirectoryService

9

UsersUsers

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

UserIntegration

10

User IntegrationUser 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.

UserIntegration

11

Key User InformationKey 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.

UserIntegration

12

User Directory ProviderUser 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

UserIntegration

13

Policy FunctionsPolicy 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();

UserIntegration

14

Information TransferInformation 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);

UserIntegration

15

Implementation StrategiesImplementation 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.

UserIntegration

16

ExamplesExamples

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

17

Group IntegrationGroup 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.

GroupIntegration

18

The Authorization ModelThe Authorization Model

Person

Group

Role

Function Entity

Collection

The Authorization Triple

GroupIntegration

19

Authorization GroupsAuthorization 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.

GroupIntegration

20

The Group ProviderThe 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);}

GroupIntegration

New forSakai 2.4!

21

Authz Group RolesAuthz 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.

GroupIntegration

22

IdentifiersIdentifiers

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

GroupIntegration

23

User Roles for GroupUser Roles for Group

• Create a Map object which includes pairs of user ids and roles for a given group id.

Map getUserRolesForGroup(String gid);

GroupIntegration

24

Group Roles for UserGroup Roles for User

• Create a Map object that includes pairs of group ids and roles for a given user.

Map getGroupRolesForUser(String eid);

GroupIntegration

25

Examples – Group ProviderExamples – Group Provider

• Mark - MIT