A Model for Enterprise Group and Affiliation Management

RL “Bob” Morgan

University of Washington

CAMP, June 2005

2

TopicsTopics

• System models, information models

• Registry model

• Groups, Affiliations, Roles, Privileges

3

Institutional Info SpaceInstitutional Info Space

• Each person’s online activities are shaped by many Sources of Authority (SoAs)• Resource managers• Program/activity heads• Other policy making bodies• Self

• The challenge is coordination• many applications, many models, many flows, many orgs

• middleware provides the coordination venue

• Our principal weaponry• centralized registries

• distributed delegated management

4

SoA FlowSoA Flow

5

Management info flowManagement info flow

6

Registry modelRegistry model

• coordination point for key institutional data• well-defined, well-identified objects

• standardized naming, attributes• managed lifecycle, clear ownership

• institution-wide controlled access via UI• accepts feeds from input systems of record

• often also SoR for some objects/attributes

• output feeds to apps, publishing points (LDAP)• provisioning, connectors, real-time services, etc

7

Modeling of registry-managedModeling of registry-managedinformationinformation

• Relationships among basic constructs• person, org, group, role, affiliation, privilege ...

• Lives behind representations in many venues:• user tables in myriad apps• central registry / warehouse tables• LDAP directory schema• SAML attribute definitions• XML document schema/DTD

8

Outside of Scope

AFFILIATION

AFFILIATION CHARACTERISTIC

AFFILIATION TYPE

AFFILIATION TYPE PERSPECTIVE

CHARACTERISTIC CHARACTERISTIC VALUE

DOCUMENT

ELECTRONIC LOCATOR

EMAIL BOX

HIERARCHY TYPE

LOCATION

LOCATOR

MAIL LOCATOR

MAILBOX

OBJECT OBJECT STATUSOBJECT TYPE

ORGANIZATION

PARTY

PARTY ADDITIONAL NAME

PARTY ADDITIONAL NAME

PARTY ALTERNATE IDENTIFIER

PARTY ALTERNATE IDENTIFIER TYPE

PARTY CHARACTERISTIC VALUE

PARTY CHARACTERISTIC VALUE LOCATOR

PARTY GROUPPARTY GROUP TYPE

PARTY HIERARCHY LINK

PARTY LOCATOR

PARTY NAMEPARTY NAME TYPE

PARTY ROLE

PARTY ROLE ASSOCIATION

PARTY ROLE TYPE

PERSONPERSON GENDER

PERSPECTIVE

POSTAL LOCATOR

PRODUCT SERVICE

SITESITE LOCATOR

TELEPHONETELEPHONE LOCATOR

TIME

TRANSACTION

WEB LOCATOR WEB SITE

A Party-based info modelA Party-based info model

9

Person-stuff managementPerson-stuff management

Identity / Affiliationperson registry,

eg ... ?

Groupgroup registry,

eg Grouper

Privilegeprivilege registry,

eg SignetOther registries:

OrganizationApplication

Host...

note overlapping areas ...

10

Person-stuff venuesPerson-stuff venues

• Affiliation• tightly person-linked, relatively few of them• driven by core institutional processes

• Group• wide range from “official” to “ad-hoc”• lots of them, for many purposes

• Privilege• driven by apps or functional areas• narrower scope, richer content

11

Enterprise AffiliationsEnterprise Affiliations

• (isn't “faculty” just a group? people ask ...)

• top-level set of “connections” to institution• relatively few: 5 min to 15 max

• may be affiliation qualifiers, eg student:undergrad

• many “members” of each affiliation • already in use for many policies/authorizations• likely to have useful lifecycle characteristics

• eg student: prospect, applicant, admitted, enrolled, former

• affiliations at lower levels?• eg faculty@english-dept, learner@cs-307-fall-2005

12

Affiliation integrationAffiliation integration

• top-level understanding of “who users are” • e.g., tabs in an institutional portal• basic population units in other apps

• reflected as groups in group reg• eg student:undergrad:enrolled

13

GroupsGroups

• simple primitive with very wide applicability• subject is member of named collection

• (membership types? starts to look like affiliation)

• official vs ad-hoc• or is it process-driven vs manual• or institutional vs personal

• names and namespaces• many many contexts for group objects• organizational, application, personal, platform

• need organization registry to make it work?

14

Groups and “appness”Groups and “appness”

• apps imply

15

Roles?Roles?

• least well-defined concept (in I2MI at least)

• institutional business-level roles• high-level org-chart driven, eg “dean”, “director”• widespread lower-level functions, eg “hiring coord”• tend to be starting point of analysis, not end-point

• role as defined in RBAC• named element aggregating priv set, holders• hence linkage point between group reg and priv reg

16

ExampleExample

• “group” UI from a popular image manager:

... defines roles, user membership in group is done via User UI ...

infra concepts have to be mapped to app functions

17

ConclusionConclusion

• Registry model• both system integration model, and

information model among registry objects• affiliations, groups, privileges are building

blocks

• Many variations of these concepts in deployed systems• infrastructure must clarify and support