1. Implementing MACE Grouper at Brown University James Cramton October 9, 2007 Internet2 Fall Member Meeting 2007 San Diego, CA

2. Project Goals Centralize group definitions Make groups more accessible to apps Delegate group management Improve group management interface Adopt compatible standards Minimize service interruptions Phased rollout of supported apps

3. Solution Scope 1 year in planning 1 PT developer 1 PT sys admin 3 PT managers 2 months in execution 2 FT developers 1 PT sys admin 3 PT managers Identify measurable benefit to CIS Pilot Instructional Technology applications WebCT course management software Majordomo email list manager Confluence wiki iTunes U Limit initial user base to 6 users of the GUI Focus on the well known course group schema

4. Current Status Production launch at start of Fall semester 2007 Limited to course groups 2,500 ‘real’ courses; 4,500 with independent study 14 groups per section  60,000 course groups Nightly provisioning takes 5 – 8 hours LDAP provisioning takes 1.5 – 2 hours Runs continuously after nightly provisioning Replicates ad-hoc changes in near-time (2 – 4 hours) Corrects minor discrepancies created under load Demographic groups using legacy Brown Grouper

5. System Diagram AfterBefore

6. Provisioning Workflow Nightly provisioning batch runs in 5 - 8 hours Each step executes via ssh immediately after its predecessors, from a shell script on a one host Batched LDAP provisioning replicates ad-hoc Grouper changes every 1.5 - 2 hours Dependencies on nightly person provisioning can suspend execution

7. Course Group Schema Course : [ Subject ] : [ Number ] : [ Term ] : [ Section ] All Administrator –Instructor (Provisioned) –TeachingAssistant –Manager Contributor –ContentDeveloper –Mentor Learner –Student (Provisioned) –Auditor –Vagabond [ brackets ] indicate dynamic data Bold indicates eduCourse/IMS compatible role Schema is flattened to provision LDAP 12 groups per course provision hasMember attribute in Groups ou Person objects get isMemberOf pointers to groups

8. Application Role Mapping Documented how Grouper groups map to application roles Application integration characteristics allow some flexibility Mapping highly dependent on user feedback MACE Grouper Course GroupsiTunesMajordomoConfluenceWebCT All Recipient list, Discussion SenderCan Use AdministratorInstructorBroadcast SenderSpace Admin Instructors (provisioned) Instructor Managers TAs TA and Designer ContributorInstructor Space Admin Content Developers Designer Mentors LearnerStudent Auditors Auditor Students (provisioned, read only) Student Vagabonds Auditor Other, outside MACE GrouperSuper Admin Super Admin(s)

9. Lessons Learned—Integration Write good documentation 40 pages of concepts, role mapping, plus Grouper and application tasks Test with the most representative data possible Mid-term data not always representative—too little change Beginning of term data causes more change—and longer run time Be prepared for a lengthy support cycle after launch Application ‘support’ for external groups is variable Some integrate directly with LDAP ~ natively (iTunes, Majordomo) Some use separate provisioning scripts (WebCT) Some suffer loss of usability with thousands of groups (Confluence) None pay any attention to group ACLs—use single bind dn Application needs vary by course or group Some need section-specific course groups Some need multi-section course groups Few performance problems in the Grouper UI LDAPpc provisioning needs performance and feature improvements Provisioning LDAP from group attribs would allow more flexibility

10. Lessons Learned—Group Management Limit initial release audience to manageable, trusted group Demographic groups are a big challenge 10 years of legacy demographic group evolution is a mess Legacy demographic groups have redundancy and transparency problems Can’t clean up part of the legacy data without addressing all groups Demographic group resolution gating factor in deploying apps WebAuth Wifi Bulk Email Naming conventions take a long time to define Accurately representing existing uses of groups Maintaining standards compatibility (eduCourse/IMS) Catch-all group important in course schema Widespread use will require exposure of implications of actions Lay users will need a clear understanding of how changes impact apps GUI troubleshooting tool awaits in Nirvana

11. Next Steps Software improvements needed in near term Performance LDAPpc batched performance around 2 hours is too long Provision LDAP using attribs, not stems –Speed: Do not provision 2,000 independent study course groups –Flexibility: Add courses to provisioning process as needed Logging and auditing capabilities need improvement UI needs to be customized for Brown’s needs Off-the-shelf UI is demonstration of all capabilities Collaboration started with other campuses Identify priorities for fall development Other CIS projects Deploy more applications using course groups Delve into demographic groups, AD, NDS migrations (complicated) Support more detailed privilege management (Signet?) Develop tool to expose implications of group and privilege changes

12. Long Term Vision Identify who manages groups Allow lay people to manage their groups & privileges Must convey implications of group & privilege changes across apps Pursuing idea of a ‘services portal’ to automatically activate selected services for specific groups Both imply more granular control of privileges Message-based provisioning Provide real-time change availability 1. From Grouper to LDAP 2. From HR or course management systems to Grouper Enforcement of group ACLs from within applications Apps should not expose existence or membership of some groups Have yet to see an application support this Probably can be achieved by removing capabilities from apps May require exposure of privilege management to community