1. Introduction to Group Management Tom Barton, Blair Christensen University of Chicago

2. CAMP - 30 June 2004 2 Copyright Tom Barton, 2004. This work is the intellectual property of the author. Permission is granted for this material to be shared for non- commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

3. CAMP - 30 June 2004 3 Outline Grouper’s place in the world Some Grouper guts Deployment scenarios “This session will offer an interactive introduction to Grouper and offer a demonstration of its tools.”

4. CAMP - 30 June 2004 4 Group services facilitate … Customization – application UI tailored to user’s affiliation with the organization “Lightweight” authorization –Groups provide binary relationship data feeding access decisions “Heavyweight” authorization –Assignment of structured privileges to groups Group messaging, scheduling, & collaboration –Departments, courses, programs, cmtes, teams, … Posix naming services …

5. CAMP - 30 June 2004 5 Group management issues Coordinating many sources of information Provisioning groups in multiple locations Supporting several styles of access to group membership information Maintaining referential integrity Aging of groups and of memberships Use of subgroups vs. effective membership Referring to set theoretic combinations of groups Meeting security, privacy, & visibility requirements  Grouper will deal with much of this

6. CAMP - 30 June 2004 6 Grouper in Context

7. CAMP - 30 June 2004 7 Grouper v1 features API & UI for basic group management –Create, read, update, delete, import, export –Distributed management –Subgroups & compound groups –Aging of groups and memberships Abstracted interfaces for –Naming and access privileges –Subject lookup –Last activity

8. CAMP - 30 June 2004 8 Grouper v1 features Signet integration Data model supports extensible group types Security, privacy & visibility requirements met in Groups Registry Not in v1: –Change history for change-based provisioning –Rule-driven membership –Presentation as a web service –Facilitation of group type management

9. CAMP - 30 June 2004 9 Grouper roadmap 3 phases of Grouper v1 development 1. Basic management and export functions 2. Compound groups & Signet integration 3. Aging of groups and memberships Deliverables –Java API, UI, Groups Registry creation scripts, sample batch import/export scripts, documentation –Phase 1 API due in November 2004 –Maybe phase 1 UI by then, too

10. CAMP - 30 June 2004 10 Grouper roadmap Developers –API: University of Chicago –UI: University of Bristol – just now coming aboard Contributed elements sought –Provisioning connectors (especially LDAP & AD) –LDAP Subject Lookup implementation –Interesting loaders –Alternate Privilege implementation (Maybe Signet? Maybe SPOCP? Others?)

11. CAMP - 30 June 2004 11 Phase 1 API highlights Session-oriented –Subject’s privileges cached in a session object “Flattened” membership –Immediate & effective memberships are updated together “List” and “non-list” data types –List fields are lists of principals or groups –Non-list fields are single string values Designed for management of group info, not high- volume run-time query service –Provision other repositories for that, such as directories or RDBMS’s

12. CAMP - 30 June 2004 12 What’s in a group Fields of “base” group type: –Name (non-list) –Description (non-list) –Members (list) –Additional list fields supporting the default access privilege interface implementation Site-defined group types can declare additional list and non-list fields

13. CAMP - 30 June 2004 13 Privileges: Access Interface VIEW group’s name in lists & can refer to group READ basic information about a group UPDATE membership and administer membership related privileges ADMIN can modify everything, including group name, description, & privileges, and can delete the group OPTIN can add self to the members list OPTOUT can remove self from the members list

14. CAMP - 30 June 2004 14 Privileges: Naming Interface Group names have two parts stem:descriptor CREATE group with specified name stem STEM – authority over a specified name stem –Assign CREATE & STEM privilege for a stem –Delegate STEM privilege to a subordinate stem –Example stem hierarchy: uc, uc:bsd, uc:bsd:obgyn –Hierarchical stem structure is visible only within the Naming Interface – rest of Grouper is oblivious Like pathnames, naming stems reflect authority but are often expected to also be lucent

15. CAMP - 30 June 2004 15 Default privilege implementation Access privileges are conferred by effective membership in list fields associated with each group (“updaters” list for UPDATE privilege, etc) Naming privileges conferred by effective membership in a system of naming groups –Hierarchical or flat stem space, per configuration All access & naming privileges can be assigned to both individuals and groups Personal groups – any user can CREATE groups named personal:username:descriptor –Configurable: on/off; stem for personal namespace –No delegation of naming authority for personal namespace

16. CAMP - 30 June 2004 16 Naming & privilege examples faculty:clinical (centrally auto-maintained) uc:nsit:netsec-update (a mail list) UPDATE: uc:nsit:netsec OPTIN: uc:members OPTOUT: uc:nsit:netsec-update student:privLoss (Registrar’s s**t-list) READ: uc:nsit:services

17. CAMP - 30 June 2004 17 Example: Delegate naming authority to Biological Sciences Division’s “Enterprise Systems Group” 1. Beginning state “uc”, STEM: uc:stem-root 2. uc:stem-root member creates “uc:bsd” naming stem & assigns STEM privilege to jdoe “uc:bsd”, STEM: jdoe 3. jdoe assigns “uc:bsd” CREATE privilege to self “uc:bsd”, STEM: jdoe, CREATE: jdoe 4. jdoe creates & populates group uc:bsd:es uc:bsd:es, ADMIN: jdoe, UPDATE: uc:bsd:es 5. jdoe completes delegation of naming authority “uc:bsd”, STEM: uc:bsd:es, CREATE: uc:bsd:es

18. CAMP - 30 June 2004 18 More examples uc:bsd:us (something only they can know) ADMIN: uc:bsd:es uc:bsd:obgyn:us UPDATE: uc:bsd:obgyn:it-staff VIEW: uc:bsd:us personal:tbarton:myFriends personal:tbarton:myTrueFriends OPTOUT: personal:tbarton:myTrueFriends

19. CAMP - 30 June 2004 19 LDAP Computer lab login access control scenario SIS HR Dir. Learning Environments Lab Managers Loaders Grouper API Person registry Groups registry Grouper UI Grouper API uid: jdoe ucAffiliation: … isMemberOf: … lab Grouper API

20. CAMP - 30 June 2004 20 Application access scenarios Status quo: app-specific “admin view” is used to manage access-control related lists of netIDs stored with the app Options for managing app-specific access 1. Incorporate Grouper API into app’s admin view 2. Use Grouper or Signet UI instead Options for application consumption of app-specific access lists 1. Incorporate Grouper API 2. Use standard protocol to read from standard repository When to recommend which approach?

21. CAMP - 30 June 2004 21 Probable UC deployment Central IT ID management extended to use API –Existing source -> person registry processing –Existing person registry -> consumer provisioning –UI access granted in parallel with delegation of group naming authority –Start small (flat stem space, no personal groups), then grow Placement of API in key distributed IT shops –Where there are significant and persistent authorization management operations LDAP & AD provisioning

22. CAMP - 30 June 2004 22 Other deployment musings UIs tailored to new group types in a common Groups Registry –Course groups –Signet –Mail list manager? API bundled into applications using a common Groups Registry –uPortal alternate Groups store –Implement appropriate uPortal Groups Service interfaces –IMS Membership Management Service API bundled with applications (with separate Groups Registry?) –Calendar –“Groupware”, of all things?

23. CAMP - 30 June 2004 23 Under discussion Multi-valued non-list fields How much built-in delegation capability is best? Identify memberships separately from members Group name aliases Group naming in inter-domain contexts UI requirements: –Defaulting privileges –Search & browse capabilities

24. CAMP - 30 June 2004 24 Further info & participation MACE-Dir list MACE-Dir-groups conference calls Stay tuned for further Signet & related participation opportunities http://middleware.internet2.edu/dir/groups Code samples, current javadoc, and Phase 1 specifications docCode samples current javadocPhase 1 specifications doc