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

CAMP - 30 June Copyright Tom Barton, 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.

CAMP - 30 June 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.”

CAMP - 30 June 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 …

CAMP - 30 June 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

CAMP - 30 June Grouper in Context

CAMP - 30 June 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

CAMP - 30 June 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

CAMP - 30 June 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

CAMP - 30 June 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?)

CAMP - 30 June 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

CAMP - 30 June 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

CAMP - 30 June 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

CAMP - 30 June 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

CAMP - 30 June 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

CAMP - 30 June 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

CAMP - 30 June 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

CAMP - 30 June 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

CAMP - 30 June 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

CAMP - 30 June 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?

CAMP - 30 June 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

CAMP - 30 June 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?

CAMP - 30 June 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

CAMP - 30 June Further info & participation MACE-Dir list MACE-Dir-groups conference calls Stay tuned for further Signet & related participation opportunities Code samples, current javadoc, and Phase 1 specifications docCode samples current javadocPhase 1 specifications doc