Management Track Monday afternoon … 1.Tom Barton – The Model: Policy & Politics 2.Amy Brooks & Bret Ingerman – Data, Policy, Stakeholders, and Governance Tuesday morning … 3.Mike Berman & Bret Ingerman – IdM Projects: Business Case, Planning, and Resources 4.Panel – Putting It All Together

5 February 2003Base CAMP 2 Copyright Tom Barton 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 2003Base 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 2003Base 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 2003Base 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 2003Base 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 2003Base 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 2003Base 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 authN attributes groups application 1 authN attributes groups

5 February 2003Base CAMP 10 Comparative Service Architectures Integrated: Suite of applications refer authentication to and obtain attributes for authorization and customization from common infrastructure services. application 1 authentication service attribute/group service application N

5 February 2003Base 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 2003Base 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 2003Base CAMP 13 Core Middleware for an Integrated Architecture

5 February 2003Base 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 2003Base CAMP 15 Articulation Factors Project Management Technology Drivers Institutional Goals Constituent Requirements Standards Practices Products Budget Staff Skills/Expertise Goal Ability to Execute Governance

5 February 2003Base 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 2003Base 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 2003Base 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), 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 2003Base 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 2003Base 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 2003Base 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 2003Base 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 2003Base 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 2003Base 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 2003Base 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 2003Base 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 2003Base 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 2003Base 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