GrouperTom Barton
University of Chicago
I2MM Spring 2004 2
Outline
Grouper’s place in the world
Some Grouper guts
Deployment scenarios
I2MM Spring 2004 3
Core middleware for an integrated architecture
I2MM Spring 2004 4
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 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
I2MM Spring 2004 6
Grouper in Context
I2MM Spring 2004 7
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 2004 8
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 2004 9
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 2004 10
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 2004 11
Access Privileges
VIEW group’s name in lists & can refer to group
READ basic information about a groupUPDATE 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 listOPTOUT can remove self from the members list
I2MM Spring 2004 12
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 2004 13
Grouper’s privilege implementation
Hierarchical or flat stem space, per configurationPersonal 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 2004 14
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 2004 15
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:myTrueFriendsOPTOUTs: personal-tbarton:myTrueFriends
I2MM Spring 2004 16
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
• But it’s not yet stable!
I2MM Spring 2004 17
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 2004 18
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 2004 19
Further info & participation
MACE-Dir list
MACE-Dir-groups conference calls
Upcoming Authorization CAMP
Stay tuned for further Signet & related participation opportunities
http://home.uchicago.edu/~tbarton/draft-barton-christensen-grouper-phase1-specs-04.html