Introduction to Group Management

Tom Barton, Blair ChristensenUniversity of Chicago

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.

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.”

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• …

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

CAMP - 30 June 2004 6

Grouper in Context

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

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

CAMP - 30 June 2004 9

Grouper roadmap

• 3 phases of Grouper v1 development1. 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 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?)

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

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

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

CAMP - 30 June 2004 14

Privileges: Naming Interface

• Group names have two partsstem: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 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

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

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

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

CAMP - 30 June 2004 19

LDAP

Computer lab login access control scenario

SIS

HR

Dir. Learning Environments

Lab Managers

Loaders

GrouperAPI

Personregistry

Groupsregistry

GrouperUI

GrouperAPI uid: jdoe

ucAffiliation: …isMemberOf: …

lab

GrouperAPI

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 access1. Incorporate Grouper API into app’s admin view2. Use Grouper or Signet UI instead

• Options for application consumption of app-specific access lists1. Incorporate Grouper API2. Use standard protocol to read from standard repository

• When to recommend which approach?

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

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?

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

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 doc