A Model for Enterprise Group and Affiliation Management RL “Bob” Morgan University of Washington CAMP, June 2005

2Topics System models, information models Registry model Groups, Affiliations, Roles, Privileges

3 Institutional 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 Flow

5 Management info flow

6 Registry 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-managed information 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 A Party-based info model

9 Person-stuff management Identity / Affiliation person registry, eg... ? Group group registry, eg Grouper Privilege privilege registry, eg Signet Other registries: Organization Application Host... note overlapping areas...

10 Person-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 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

12 Affiliation 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

13Groups 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” apps imply

15Roles? 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

16Example “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

17Conclusion 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