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