Management Track

Monday afternoon …1. Tom Barton – The Model: Policy & Politics2. Amy Brooks & Bret Ingerman – Data, Policy,

Stakeholders, and GovernanceTuesday morning …3. Mike Berman & Bret Ingerman – IdM Projects:

Business Case, Planning, and Resources4. Panel – Putting It All Together

5 February 2003 Base CAMP 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.

5 February 2003 Base CAMP 3

Management Track Q Cards

1. Write a question you’d like to ensure gets discussed

2. Give it to Ann West at end of this talk

3. Management Track presenters & Ann will meet and try to ensure that Qs are covered

4. We might ask you to say a few words about your Q during the panel session!

The Model: The Policy and Politics

Tom Barton, University of Chicago

5 February 2003 Base CAMP 5

Outline

• Review some of what Keith just said• Identifier discovery process: method,

purpose, key questions to resolve• Non-technical IdM operational requirements• Policy & process implications & questions• Roundup of what it takes to make IdM

happen

5 February 2003 Base CAMP 6

What We’re All Trying to Accomplish

• Simplify end user access to multitude of online services

• Facilitate operation of those services by IT organizations

• Increase security & reliability• Enable online service for our constituents earlier in

their affiliation with us, wherever they are, and forever• Participate in new, inter-organizational, collaborative

architectures

5 February 2003 Base CAMP 7

Terminology Review

• Identity: set of attributes about, and identifiers referring to, a subject (or actor).

• Authentication: process used to associate a subject with an identifier. – Produces a security context.

• Authorization: process of determining if policy permits an intended action to proceed. – Efficacy is limited by availability of subject attributes and by

how faithfully policy is incorporated into the infrastructure or the application.

• Customization: presentation of user interface tailored to user’s identity.

5 February 2003 Base CAMP 8

What Identity Management is,Take 1

• Integration of pertinent information about people from multiple authoritative sources

• Processes that transform source data, derive affiliation information, maintain status of assigned, entitled, or authorized information resources, and provision resultant data where it can be of use to applications

• Locus for implementation of policies concerning visibility and privacy of identity information and entitlement policies

• Buzz plug-in goes here …

5 February 2003 Base CAMP 9

Comparative Service Architectures

Stovepipe (or silo): Each application performs its own authentication and consults its own database for authorization and customization attributes.

application N

authNattributes

groups

application 1

authNattributes

groups

5 February 2003 Base CAMP 10

Comparative Service Architectures

Integrated: Suite of applications refer authentication to and obtain attributes for authorization and customization from common infrastructure services.

application 1authenticationservice

attribute/groupservice application N

• •

•

5 February 2003 Base CAMP 11

Comparative Service Architectures

Stovepipes are run by separate offices• Environment is more challenging to users, who may

need to contact each office to arrange for service and remember several sets of credentials

• Any life cycle management of service specific resources is undertaken by each service specific office independently

• Per-service identifiers and security practices make it more difficult to achieve a given level of security across the enterprise

• Per-service marshalling of attributes scatters business logic

5 February 2003 Base CAMP 12

Comparative Service Architectures

Common identity management processes are coordinated by a central office

• Attributes known by the organization about a person can be integrated and made available to applications

– Fewer end-user credentials, more homogeneous experience– Lower marginal cost to deploy an application– Consolidation of business logic

• Automated & consistent life cycle resource management becomes possible across all integrated applications

• Common identifiers facilitate achieving uniform security and policy implementation across integrated applications

5 February 2003 Base CAMP 13

Core Middleware for an Integrated Architecture

5 February 2003 Base CAMP 14

Identifier (Re-)Discovery

• Core middleware will convey identity information from authoritative sources to applications, so …– Find out who assigns what identifiers to which

constituencies for what purposes– Find out which applications use or might use which

identifiers and are intended to serve which constituencies– Make the rounds of IT service providers. Ask what they do

and what their top issues are.

• Keep a record of identifiers discovered by this process and their characteristics– Lucency, persistence, uniqueness, structure, granularity, …

• Assess service providers’ drivers, ability to execute, & existing technique … picture on next slide …

5 February 2003 Base CAMP 15

Articulation Factors

Project ManagementTechnology

Drivers

Institutional Goals

Constituent Requirements

Standards

Practices

Products

Budget

Staff Skills/Expertise

Goal

Ability to

Execute

Governance

5 February 2003 Base CAMP 16

Identifier Discovery

• How hard is this environment for users? For service providers?

• Should you reduce/increase the number of namespaces in use?– Usernames– Key identifiers in source or consumer systems – SSNs versus campus-issued identifier for administrative

services• Is simplification worth the effort?

– Unification of namespaces can be painful & requires serious organizational cooperation and commitment

– But it may be the best choice!

5 February 2003 Base CAMP 17

Functional Requirements for Managing Identity Information

• Have a single authoritative source for identity– The Person Registry is the System of Record for one or two

foundational identifiers • Persistent, unreleased registry ID

• Persistent, “publically visible”, ID for linking with external databases when needed

• Resolve “is this person new?”– Maintain one-to-one mapping between fundamental

identifiers and real-world people (“join” function)– Rely on external identifiers: name, birthday, …– Don’t get me started on “Rational Identity Management”!

5 February 2003 Base CAMP 18

Functional Requirements for Managing Identity Information

• Integrate data from authoritative sources and provision to consuming locations– Store foreign keys for all connected repositories– Reduce need to determine “is this person new?”

• Provide authentication credentials & contact info – Some authoritatively housed in Registry

• Username(s), email address(es)

– Other data sourced elsewhere• Phones, USMail addresses, office location, …

• Provide “unique-ification”– Store secrets to help with initial account claim and password

reset procedures• Qs & As, initialization codes

5 February 2003 Base CAMP 19

Functional Requirements for Managing Identity Information

• Be a clearinghouse for affiliations– Which source systems define which affiliations? – “Major” values derived from authoritative sources– “Minor” values for course, program, department, …– Group memberships

• Be a clearinghouse for other data of common value in application security, customization, and messaging contexts– localDomainPerson categories … next slide …– Enables single locus for business logic– Simpler application integration requirements vs. connecting

directly to authoritative sources

5 February 2003 Base CAMP 20

localDomainPerson categories

• Additional Personal Characteristics• Additional Contact Information• Student-Specific Information• Employee-Specific Information• Multi-campus Information• Linkage Identifiers• Entry Metadata• Security Attributes• Privacy Attributes• Authorization Information• Other Miscellaneous Attributes

5 February 2003 Base CAMP 21

Functional Requirements for Managing Identity Information

• Store data for managing provisioning processes

• Implement constraining policy– Privacy & visibility– Security & audit – Manage the authority to manage identity data in

distributed administration environments

• Meet operational objectives– Availability, fault tolerance

5 February 2003 Base CAMP 22

Boundary Conditions Between Services & Middleware

• Ability to identify each user by an identifier authoritatively located in core middleware is a requirement for integration into this architecture

• Service requirements map to middleware requirements …– Selection of valuable identity attributes– Source(s) of authority for each identifier or attribute– Manner of their representation– Consequent requirements for transformation and business

logic– Special case: archival use of an identifier vs. its persistence

and reassignability

5 February 2003 Base CAMP 23

Policy & Process Issues

How will the University operate its identity management infrastructure?

• What balance between centralized and distributed operation?– Registry – singular, centralized function– Consumers – high degree of distribution possible– Registration Authorities – small number??

• Who may have which role in managing Registry data under what authority & obligations?

• Leverages & extends existing data administration policies & processes, or begs if those are insufficient

• Highly cross-functional activity demanding organizational flexibility

5 February 2003 Base CAMP 24

Policy & Process Issues

What are the entitlement or access policies for each service?

• Which sets of affiliations or other info to be conveyed by common infrastructure are needed to evaluate access policies?

• From which authoritative sources can these be identified?

• Who’s authoritative for these policies?• What processes should determine entitlement

policies?

5 February 2003 Base CAMP 25

Policy & Process Issues

Systems analysis• Who will determine whether to put new information in

the common infrastructure, and how it will be represented?– “Major” & “minor” affiliations– Entitlements & privileges– Group memberships– …

• If necessary info isn’t already collected, who will judge whether business processes should be changed in order to do so?

• Determine a set of core principles that guide the selection and use of data stored in the IdM system

5 February 2003 Base CAMP 26

Sample Principles for Discussion

• Data not of value in managing the IT operational infrastructure in which services operate should not be handled within the IdMS– It’s not a decision support tool

• Databases that collect information from two or more systems of record should integrate with the IdMS– Don’t duplicate the join function; run only one IdMS.

• Information should be handled by the IdMS if it tends to expand the set of integrated services– Make the IdMS more “adoptable” around campus

• Don’t store application-specific data in the IdMS, with the exception of apps that are part of the IdM operation (e.g., provisioning)– Enough to embody security & lifecycle management policies across

the suite of integrated services

5 February 2003 Base CAMP 27

Policy & Process Issues

How will the University handle loosely affiliated persons?

• Who should be issued a credential? What assurance level should authentication for each constituency achieve? What constraints may pertain to each?– Applicants (student, faculty, staff)– Admitted students, accepted faculty or staff– Alums– Parents– Library patrons– Guests: visiting academics, conference attendees, hotel

guests, arbitrary “friends”, …

5 February 2003 Base CAMP 28

Elements of Identity Management, Take 2• Integrated service strategy & architecture

– Incremental determination of valuable identity information– Promotes the high level objectives on slide 4

• Systems analysis– What business processes might produce the info?– Where does/can it enter the IT infrastructure?– Do actual semantics fit the perceived value?

• Middleware infrastructure services– Schema, systems design, operation– Conveying attributes from sources to where their run-time

value is realized• Policy issues & governance processes• An organization conducive to new types of

professional relationships