Grouper Tom Barton University of Chicago

I2MM Spring Outline  Grouper’s place in the world  Some Grouper guts  Deployment scenarios

I2MM Spring Core middleware for an integrated architecture

I2MM Spring Attribute & group services facilitate …  Customization – application UI tailored to user’s affiliation with the organization  “Lightweight” authorization Groups & attributes in directories  “Heavyweight” authorization Assignment of structured privileges to groups  Group messaging, scheduling, & collaboration Departments, courses, programs, cmtes, teams, …  Posix naming services  …

I2MM Spring 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

I2MM Spring Grouper in Context

I2MM Spring Features in Grouper v1  Basic group management  Subgroups & compound groups  Aging of groups and memberships  Abstracted interfaces for Privileges Subject Lookup Last Activity  Signet integration  Data model supports extensible group types

I2MM Spring Grouper roadmap  3 phases of Grouper v1 development Basic management and export functions Compound groups & Signet integration Aging of groups and memberships  Deliverables Java API, UI, Groups Registry creation scripts, sample batch import/export scripts, documentation Some type of prototype demo at AuthZ CAMP

I2MM Spring Grouper roadmap  Developers API, etc: University of Chicago I2+UofC funded UI: University of Bristol JISC funded  Contributed elements sought Provisioning connectors (especially LDAP & AD) LDAP Subject Lookup Interface Signet-based Privilege Interface implementation Interest expressed in SPOCP-based Privilege Interface implementation

I2MM Spring What’s in a group  Fields of “base” group type: name description members  Additional “list” fields supporting default access privilege management  Site-defined group types can declare additional list fields and non-list fields A Grouper “list” is a list of individuals or groups

I2MM Spring Access Privileges  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

I2MM Spring Naming Privileges  Group names have two parts stem:descriptor  CREATE group with specified name stem  STEM – authority over a specified name stem Manage who has CREATE privileges for a stem Delegate STEM privilege to a subordinate stem  Grouper enforces authority over flat or hierarchical stem space Egs: uofc, uofc-bsd, uofc-bsd-obgyn

I2MM Spring Grouper’s privilege implementation  Hierarchical or flat stem space, per configuration  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  Naming privileges conferred by effective membership in system of naming groups  Access privileges conferred by effective membership in lists associated with each group (updaters list for UPDATE privilege, etc)  All access & naming privileges can be assigned to both individuals and groups

I2MM Spring Sample mayhem  uofc:faculty (centrally auto-maintained)  uofc-bsd (initial delegation to BioSci Division) STEM: jdoe  uofc-bsd (resultant delegation of naming authority) STEM: uofc-bsd:enterprise-IT-group  uofc-bsd:us (something only they can know) ADMINs: uofc-bsd:enterprise-IT-group  uofc-bsd-obgyn:us (delegated to OB/GYN dept) UPDATERs: uofc-bsd-obgyn:it-staff VIEWers: uofc-bsd:us

I2MM Spring More mayhem  uofc-nsit:netsec-update (a mail list) UPDATERs: uofc-nsit:netsec OPTINs: uofc:uofc OPTOUTs: uofc-nsit:netsec-update  student:privLoss (Registrar’s s***-list) READers: uofc-nsit:services  personal-tbarton:myFriends  personal-tbarton:myTrueFriends OPTOUTs: personal-tbarton:myTrueFriends

I2MM Spring Phase 1 API highlights  Session-oriented Session subject’s privileges constrains API  “Flattened” membership Immediate & effective memberships are updated together  Designed for management of group info, not high-volume run-time query service Provision other technologies for that, such as directories or RDBMS’s  Code samples & javadoc are linked in the specifications doc on last slide Code samples javadoc But it’s not yet stable!

I2MM Spring Probable UofC deployment  Central IT ID Mgmt 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 stemspace, no personal groups), then grow  Placement of API in key distributed IT shops Where there are significant and persistent authorization mgmt operations  LDAP & AD provisioning

I2MM Spring Other deployment musings  Additional UIs tailored to new group types, common Groups Registry Course groups Signet Mail list manager?  API bundled into application, common Registry uPortal alternate Groups store Implement appropriate uPortal Groups Service interfaces  API bundled with application, separate Groups Registry? Calendar “Groupware”, of all things?

I2MM Spring Further info & participation  MACE-Dir list  MACE-Dir-groups conference calls  Upcoming Authorization CAMP  Stay tuned for further Signet & related participation opportunities  barton-christensen-grouper-phase1- specs-04.html barton-christensen-grouper-phase1- specs-04.html