8th Sakai Conference4-7 December 2007 Newport Beach Integration: Users and Groups Mark J. Norton...
-
Upload
miles-flowers -
Category
Documents
-
view
215 -
download
1
Transcript of 8th Sakai Conference4-7 December 2007 Newport Beach Integration: Users and Groups Mark J. Norton...
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