Enhancing Collaboration by Extending the Groups Directory Infrastructure

1. Enhancing Collaboration by Extending the Groups Directory Infrastructure James CramtonBrown University

2. Why We are Here • De-duplication without all the facts • Software in central business system identifies individuals on SSN • Provisioning software in IT identifies individuals on First Name, Last Name, DOB • William Charles Smith and William Kenneth Smith, with same DOB applied • Provisioning software flags Kenneth as a duplicate, does not provision him • Turns out they are twins with same first and last name! • Solution: write an exclusion list for skipping provisioning duplicate check • Need for greater group specificity • Clinical faculty in medical school irate because he is not granted system access • Turns out clinical faculty are grouped with various affiliates in registry • Solution: continue with current initiative to identify & enforce better policy

3. Starting Point: Brown Grouper • 1990s: Brown Grouper developed to manage groups and ACLs • Dated web interface allows experienced administrator to include or exclude group members from base group • 11,000 groups stored in home-brewed text file format • 5,000 base course groups from SIS feed for 2,500 Courses (read only) • 5,000 modifiable course groups for 2,500 courses (read/write) • 1000 demographic groups support limited group logic • Active Directory and Novell groups manually provisioned • Major exposure to Hit by a Bus Syndrome • One administrator and the one person responsible for mailing labels know the data • No personal groups (unless you know who to ask) • No index of group data—what groups exist? (unless you know who to ask)

4. Brown’s Provisioning System • Text feeds from multiple systems consumed by provisioning software • Brown Grouper • University mainframe (BRU) • Student Info System (SIS) • Provisioning handled by Perl scripts and some 3rd party connectors • Object-based Perl code is modular, but biz logic is embedded in code • SunOne LDAP registry is main repository for provisioned data • Registry replicates users to AD, eDirectory, and other SunOnes servers • WebAuth and bulk mail query Brown Grouper directly • Course membership and primary affiliation are the only group info in registry; they are attributes on the Person object

5. Current System Landscape Kerberos UserRegistry Alum AD ProvisioningSoftware ManuallyProvisionGroups Exchange SQL E-Directory LDAP Directory User LDAP Authentication LDAP Network LDAP Feed Account Provisioning LDAP Alumni Relay LDAP SMTP Relay GroupsRegistry LDAP Mail Relay LDAP Registry BRU Group Sync Grouper Feed Base Group Course iTunes WebCT Effective Group SIS Bulk Mail Group Course Feed WebGroupie UI WebAuth Course Feed

6. Proposed System Landscape Kerberos User UserRegistry Alum AD ProvisioningSoftware Exchange SQL E-Directory LDAP Directory LDAP Authentication LDAP Feed LDAP Network Account Provisioning LDAP Alumni Relay User, Group, and Course Groups Registry LDAP SMTP Relay LDAP Mail Relay BRU Group Sync LDAP Registry Grouper Feed Base Group iTunes WebCT Bulk Mail SIS Effective Group WebAuth Course Feed Group Mgmt UI

7. Motivations • Stakeholders want: • More control of groups (delegation of some groups) • Less control of groups (centralized definitions of other groups) • Ability to extend base groups (include and exclude members) • More group visibility (expose more existing groups to applications) • More groups (add student activities, personal groups, etc.) • Limit administrative overhead • Contain Help Desk administrative burden • Delegate some group administration to some departments • Eliminate duplication of effort in manually provisioned groups (AD and Novell) • Support wider range of policy decisions • Remove technical limitations on business policy • Increase granularity of rules • Use centralized ACLs to enforce rules in application layer

8. Requirements • Provide a single system image of group definitions • Store more granular group definitions in LDAP • Automatically provision groups into Active Directory and eDirectory • Support multiple types of groups • Increase granularity of group definitions available to application layer (highly nested schema) • Technically not particularly challenging • Business rules for establishing ACL and affiliation hierarchy is tricky • Continue to support expectation of highly customizable groups • Automatically provisioned (base groups) • Provisioned and tuned (effective groups) • Manually provisioned (centralized, not ad hoc) • Expanded granularity will require delegation • Improve usability of group management tool—both interface and concepts • Scope includes group definitions, membership, and ACLs • Implement with minimal service disruption • Support current applications • Provide framework for support of future applications

9. Policy Issues • The technical decisions are relatively easy • Explaining issues to stakeholders is more challenging • Reaching consensus takes time and collective education • Policy & business practice questions abound • We can do great things. But should we? Will it be used? • How do we provide visibility without compromising sensitive info? • What are the organizational expectations of privacy & accessibility? • Who will be managing group data? With what tools? With what skills? • Need to communicate the new capabilities and policies • Limiting scope is essential • Impact core infrastructure, not applications in HR, Registrar, etc. • Justify any increased administrative overhead • Privilege management scheduled to follow policy decision process

10. Cultural Considerations • Historically, computer services have been highly customizable • Courses have multiple membership list—for better or worse • Course registration • Course mailing list • WebCT registration • Groups will be created & membership modified to meet most any need • If students and faculty can’t get what they ‘need,’ they will use 3rd party services • Potential productivity drain as departments reinvent the wheel with or without IT expertise • Potential waste of money as departments purchase 3rd party products & services • Potential security risk in unapproved systems • So, IT provides peripheral authentication and authorization services (Napster, wiki, etc.) • Extremely open campus policies, with exceptions • Student groups want to know when related group meets to avoid schedule conflict • Some group membership must be known only to group • Some group membership must be known only to another group • Some groups existence must be hidden from community view • Technology capabilities currently limiting business innovation • Highly vulnerable to the Hit by a Bus syndrome

11. Strategic Approach • Identify requirements • Define scope of change • Design proposed system • Implement prototype • Revise design as needed • Implement and validate additive infrastructure • Phased rollout of applications • Pilot • Roll-out • Next… • Follow up with delegated applications (AD/Exchange/eDirectory) • Consider next generation features as subsequent projects

12. Implement infrastructure LDAP schema changes Provisioning software changes Management interface changes Tier 1 applications (enhance existing services) Network Access Control Lists VPN, Wifi, other ACLs Network Device ACLs WebAuth (http[s] authn & authz) Bulk Mail Morning Mail Groups Replace Majordomo (with Sympa?) WebCT Course Provisioning iTunes provisioning Tier 2 applications(delegated services) Wiki authn & authz via LDAP Groups Exchange/AD group provisioning Novell eDirectory group provisioning Tier 3 applications(proposed services) Shibboleth Video on Demand Campus Calendars Personal Groups Privilege management Guest, alumni IDs and ACLs Phased Implementation

13. Analysis Techniques • Interview stakeholders • Understand current and proposed system • Set arithmetic diagrams for conceptualizing scope • Research and create lists of LDAP group queries • Current • Anticipated • Analyze impact on performance and schema • Understand scope of current group infrastructure • Summarize to understand big picture • Review detail to identify the exceptions

14. Current System Landscape Kerberos UserRegistry Alum AD ProvisioningSoftware ManuallyProvisionGroups Exchange SQL E-Directory LDAP Directory User LDAP Authentication LDAP Network LDAP Feed Account Provisioning LDAP Alumni Relay LDAP SMTP Relay GroupsRegistry LDAP Mail Relay LDAP Registry BRU Group Sync Grouper Feed Base Group Course iTunes WebCT Effective Group SIS Bulk Mail Group Course Feed WebGroupie UI WebAuth Course Feed

15. Proposed System Landscape Kerberos User UserRegistry Alum AD ProvisioningSoftware Exchange SQL E-Directory LDAP Directory LDAP Authentication LDAP Feed LDAP Network Account Provisioning LDAP Alumni Relay User, Group, and Course Groups Registry LDAP SMTP Relay LDAP Mail Relay BRU Group Sync LDAP Registry Grouper Feed Base Group iTunes WebCT Bulk Mail SIS Effective Group WebAuth Course Feed Group Mgmt UI

16. Set Arithmetic Modeling Current Design User Proposed Design User KerberosADExchangeE-DirectoryLDAP x 7 Kerberos ADExchangeE-DirectoryLDAP x 7Bulk MailWebAuthWebCT WebCT Bulk MailWebAuth Via Course Feed Via Brown Grouper Course Group Course Group

17. List Anticipated LDAP Queries • Summarize query types by application • Optimize schema according to common query types • Real time vs. batch can influence decisions

18. Current Group Summary • 10,000 course groups • 1,000 other groups • Redundancy is merited by historical precedent • Schema depth: 4 levels • Deepest nested subgroup membership much deeper