Identity Management Systems: Policy, Technology, and Implementation Considerations

Identity Management Systems: Policy, Technology, and Implementation

Considerations

Tom Barton, University of Chicago

Renee Woodten Frost, University of Michigan and Internet2

21 March 2005

21 March 2005 EDUCAUSE Midwest Regional 2

Topics

• Introductions• What is Identity Management (IdM)? and Why?• IdM Components and Functional Requirements• Tools for Distributed Management of Access

and Authority• Policy and Process• Resources and Wrap up


Outcomes• Learn high-level Identity Management (IdM)

terminology, concepts, and components– Converse and ask appropriate questions about IdM topics– Comprehend more from your reading materials– Learn where to find out more, for those of you leading or

participating in a IdM project

• Learn about the role of policy and organization processes in IdM – Know about the key piece of governance, the most often

overlooked policy piece

• Learn about NMI tools for distributed access management


What is Identity Management (IdM)?Set of standards, policies, procedures, and

technologies that provide electronic credentials to individuals and maintain authoritative information about the holders of those credentials . . and assist in determining and granting access . .

• Identity Management in this sense is sometimes called “Identity and Access Management”

• What problems does Identity Management solve?


Identity Management is…

• “Hi! I’m Lisa.” (Identity)• “…and here’s my NetID / password to prove it.”

(Authentication)• “I want to open the Portal to check my email.”

(Authorization : Allowing Lisa to use theservices for which she’s

authorized)• “And I want to change my grade in last

semester’s Physics course.”(Authorization : Preventing her from

doing things she’s not supposed to do)


Identity Management is also…

• New hire, Assistant Professor Alice– Department wants to give her an email

account before her appointment begins so they can get her off to a running start

• How does she get into our system and get set up with the accounts and services appropriate to faculty? (Provisioning)


What Questions are Common to These Scenarios?

• Are the people using these services who they claim to be?

• Are they a member of our campus community?

• Have they been given permission?

• Is their privacy being protected?


As for Lisa

• Sez who?– What Lisa’s username and password are?– What she should be able to do?– What she should be prevented from doing? – Scaling to the other 40,000 just like her on

campus


As for Professor Alice

• What accounts and services should faculty members be given?

• At what point in the hiring process should these be activated?

• Methods need to scale to 20,000 faculty and staff


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• Enable online service for our constituents earlier in their

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

architectures and environments


Elements of Identity Management, 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 application

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

Buzz - “Identity management is the set of business processes, and a supporting infrastructure, for the creation, maintenance, and use of digital identities.” The Burton Group (a research firm specializing in IT infrastructure for the enterprise)


The IdM Stone Age

List of functions:• AuthN: Authenticate principals (people,

servers) seeking access to a service or resource

• Log: Track access to services/resources


The IdM Stone Age

• Every application for itself in performing these functions

• User list, credentials = if you’re on the list, you’re in (AuthN is authorization (AuthZ)

• As Hobbes might say: Stone age IdM “nasty, brutish & short” on features


Vision of a Better Way to do IdM

• IdM as a middleware layer at the service of any number of applications

• Requires an expanded set of basic functions– Reflect: Track changes to institutional data from

changes in Systems of Record (SoR) & other IdM components

– Join: Establish & maintain person identity across SoR

– …


Vision of a Better Way to do IdM

• More in the expanded set of basic functions– Mng. Affil.: Manage affiliation and group information– Mng. Priv.: Manage privileges and permissions at

system and resource level – Provision: Push IdM info out to systems and services

as required– Deliver: Make access control / authorization

information available to services and resources at run time

– AuthZ: Make the allow/deny decision independent of AuthN


IdM Functions

Reflect Data of interest

Join Identity across SoR

Credential NetID, other

Manage Affil/Groups AuthZ info

Manage Privileges More AuthZ info

Provision For apps w attitude

Deliver Get AuthZ info to app

Authenticate Check identity claim

Authorize Make allow/deny decision

Log Track usage for audit


Your Digital Identity and The Join

• The collection of bits of identity information about you in all the relevant IT systems at your institution

• For any given person in your community, do you know which entry in each system’s data store carry bits of their identity?

• If more than one system can “create a person record,” you have identity fragmentation


The Pivotal Concept of IdM: The Join

• Identity fragmentation cure #1: The Join• Use business logic to

– Establish which records correspond to the same person

– Maintain that identity join in the face of changes to data in reflected systems

• Once cross-system identity is forged, assign a unique person identifier (often a registry ID)


Identity Information Access and Reachability

• Direct from Enterprise Directory via reflection from SoRs» or

• Need to be made reachable by identifier crosswalks– For new apps, leverage “join” by carrying Registry ID

as a foreign key - even if not in crosswalk – Key to reachability is less about technology, more

about shared practice across system owners

Registry ID Sys A ID Sys B ID Sys C ID Sys D ID

3a104e59 fsmith32 86443 freds 864164

8c2f916d abecker1 45209 amyb 752731


When You Cannot Integrate

• Identity Fragmentation Cure #2: federate• Federated Identity Management means

– Relying on the Identity Management infrastructure of one or more institutions or units

– To authenticate and pass authorization-related information to service providers or resource-hosting institutions or enterprises

– Via institution-to-provider agreements– Facilitated by common membership in a federation

(like InCommon)


A Closer Look at Managing Affiliations, Groups and Privileges

• How does this help the harried IT staff?


Authorization, the Early Years

• IdM value realized only when access to services & information enabled

• Authorization support is the keystone• Crude beginnings: If you can log in, you get it

all• Call to serve non-traditional audiences breaks

this model:– Applicants– Collaborative program students



First refinement on “Log in, get it all:”• Add service flags to the enterprise directory

as additional identity information– Lisa: Eligible for email– Fred: Eligible for student health services– Sam: Enrolled in Molecular Biology 432

• The horrendous scaling problem


Thanks to: [email protected]



• Bringing in groups to deal with the scaling problem

• Here groups are being used to carry affiliations or “roles”



Groups and Affiliation Management Software?

• Middleware Architecture Committee for Education (MACE) in Internet2 sponsoring the Grouper project– Infrastructure at University of Chicago– User interface at Bristol University in UK– $upport from NSF Middleware Initiative (NMI) and Joint

Information Systems Council (JISC)

• http://middleware.internet2.edu/dir/groups/grouper


Role- and Privilege-based AuthZ

• Privileges are what you can do

• Roles are who you are, which can be used for policy-based privileges

• Both are viable, complementary for authorization


Roles (cf. isMemberOf)

• Inter-realm, specific privileges vary in different contexts– e.g. Instructor can submit grades at one site, read

only at another

• Eligibility (can have) instead of authorization (can do)– e.g. Faculty/Staff/Students get free email from

specific provider


Privileges (cf. eduPersonEntitlement)

• Permissions should be same across service providers

• Service providers do not need to know rules behind authorization– e.g. Building access regardless of why

• has office in building• taking class in building• authorized by building manager


Privilege Management Feature Summary

By authority of the Dean grantor

principal investigators role (group)

who have completed training prerequisite

can approve purchases function

in the School of Medicine scope

for research projects up to $100,000 limits

until January 1, 2006 condition


Privilege Management Software?

• Project Signet of Internet2 MACE– Development based at Stanford– $upport from NSF Middleware Initiative

• http://middleware.internet2.edu/signet


Basic IdM functions

Systems of Record

Stdnt

HR

Other

Enterprise Directory

Registr

y LD

AP


IdM Components and Functional Requirements


Provisioning

System

s of R

ecord

Enterprise DirectoryApps / Resources


Two Modes of App/IdM Integration

• Domesticated applications:– Provide them the full set of IdM functions

• Applications with attitude (comes in the box)– Meet them more than halfway by provisioning


Provisioning

• Getting identity information where it needs to be

• For “Apps with Attitude,” this often means exporting reformatted information to them in a form they understand

• Using either App-provided APIs or tricks to write to their internal store

• Change happens, so this is an ongoing process


Provisioning Service Pluses

• Provisioning decisions governed by runtime configuration, not buried in code somewhere

• Single engine for all consumers has obvious economy

• Config is basis for healing consumers with broken reflection

• Config could be basis of change management: compare as is provisioning rule to a what if rule


How Full IdM Layer Helps

• Improves scalability: IdM process automation• Reduces complexity of IT ecosystem

– Complexity as friction (wasted resources)

• Improves user experience• Functional specialization: App developer can

concentrate on app-specific functionality– Concentrate valuable business logic in IdM config

• Improves security & auditability


A Successful Enterprise DirectoryAttracts Data

• People start to see the value in reflecting data there• App. owners start asking to put person-level specifics

– Service config– Customization– Personalization

• What about non-person data?• Why do we never see “data warehouse” and

“directory” in the same book or white paper?


Basic IdM Functions Mapped to theNMI / MACE Components

System

s of R

ecord

Enterprise Directory

Grouper Signet

WebISO

Shibboleth

Apps / Resources


Same IdM Functions, Different Packaging

• Your IdM infrastructure (existing or planned) may have different boxes & lines

• But somewhere, somehow this set of IdM functions is getting done

• Gives us all a way to compare our solutions by looking at various packagings of the IdM functions


IdM Functions

Reflect Data of interest

Join Identity across SoR

Credential NetID, other

Manage Affil/Groups AuthZ info

Manage Privileges More AuthZ info

Provision For apps w attitude

Deliver Get AuthZ info to app

Authenticate Check identity claim

Authorize Make allow/deny decision

Log Track usage for audit



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



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

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

directly to authoritative sources



• 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


Tools

for Distributed Management

of Access and Authority


IdM Reality

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

• Common middleware infrastructure should be operated centrally – To not oblige departments/programs/activities to build their

own core middleware• Management of the information it conveys should be

highly distributed– Hook up all of those SoAs to the middleware


Relative Roles of Signet & Grouper

Grouper Signet

RBAC model

• Users are placed into groups

• Privileges are assigned to groups

• Groups can be arranged into static hierarchies to effectively bestow privileges

• Signet manages privileges

• Grouper manages, well, groups


Signet


Nutshell Description of Signet

• Analysts write XML descriptions of “business views” of privileges and store them in the Authority Registry

• Signet UI presents business views found in the Authority Registry

• Authoritative persons use the Signet UI to assign privileges and delegate authority across all “subsystems” in which they have any authority– Signet UI stores assignments in the Authority Registry

• XML “permissions documents” are exported from the Authority Registry, transformed, and provisioned into integrated systems and infrastructure services


Privileges Building Blocks

• Business view– Subsystems– Categories– Functions– Scope– Limits– Prerequisites– Conditions

• System view– Permissions

• Assignment to– Individual– Group– With/without ability to

further delegate

• Proxy assignment


Signet Subsystems

• Define domains of ownership and responsibility

• Reflect real world boundaries

• Can be large or small

Financial systemStudent systemHR systemNetwork address plan

managementNetwork access

managementResearch administrationClinical resourcesIdMS UI (Person Registry)Signet (Authority Registry)Grouper (Group Registry)


Authority Elements by Example

By authority of the Dean grantor

principal investigators grantee (group)

who have completed training prerequisite

can approve purchases function

in the School of Medicine scope

for research projects up to $100,000 limits

until January 1, 2006 condition


Business View System Permissions


Provisioning Permissions into Systems


Provisioning Permissions into Infrastructure



Nutshell Description of Grouper

• Mix of humans and automation processes manage a common Group Registry, an information asset peer to the Person Registry– Affiliations, courses, depts/programs, service blacklists and

whitelists, self-selecting communities, teams, RBAC roles, …

• Groups are managed within distinct namespaces for distinct activities or authorities

• Automation processes provision info from the Group Registry into LDAP, AD, apps with attitude, wherever

• Delegatable group management authority


Grouper Groups

• Attributes of groups– Names: name, displayName, guid– Description– Members – Can extend the set of attributes to support groups

with more specific purposes

• Subgroups, compound groups, and aging • Stored in an RDBMS, the Group Registry


Group Namespaces

• Groups are created within namespaces– Scopes the authority to create and name groups– Support distinct activities with own authority

• Namespaces can be arranged hierarchically

nsit all central IT activities

nsit:usite manage USITE computer labs

bsd all Bio Sci Division activities

bsd:peds Pediatrics resource access


Example: Groups for USITE Access

nsit:usite:usite_eligible(manual)

nsit:usite:admin_admit(manual)

uc:faculty(auto)

uc:staff(auto)

categories of entitled students (auto)

time dependent student categories (auto)

nsit:usite:admin_deny(manual)

categories of barred students (auto)

nsit:usite:usite_barred(manual)

ACL is “usite_eligible but not usite_barred”


Grouper Privileges

• Access privileges– Who has what access (read, write) to a group’s attributes

• Naming privileges– Who can create a group in each namespace– Who can create a new namespace subordinate to an

existing one

• Privilege interfaces are abstracted– Can use external privilege management system, like Signet

• Grouper’s built-in privilege management– Subgroups, compound groups, and aging can be used to

manage privileges with built-in capability


Three Ways to Distribute Group Management

• Create a group and assign someone to manage its membership

• Create a group and assign someone to manage who manages the group’s membership and who can see what about the group

• Create a namespace and assign someone to manage who can create groups within it


USITE Group Access Privileges

nsit:usite:usite_eligible A nsit:usite:dir_learning_envV,R all

nsit:usite:admin_admit U nsit:usite:usite_manageV,R nsit:usite:usite_view

uc:facultyV,R all

uc:staffV,R all

categories of entitled students

time dependent student categories

categories of barred students

nsit:usite:admin_deny U nsit:usite:usite_manageV,R nsit:usite:usite_view

nsit:usite:usite_barred A nsit:usite:dir_learning_envV,R all

V all V all

V allV all V all

V all V all V all

V all

Legend: A-admin, U-update, V-view, R-read)


LDAP

Data Flow & Grouper Roles in USITE Access

uid: jdoeucAffiliation: …isMemberOf: …

SIS

HR

Dir. Learning Environments

Lab Managers

Loaders

GrouperAPI

Personregistry

Groupregistry

GrouperUI

GrouperAPI

lab

GrouperAPI

Student staff


Signet & Grouper

• Now available– Grouper API v0.5. Basic group management by automation

processes– Demo release of Signet v0.2

• May 2005– Grouper v0.6. First complete release, including the UI

• September 2005– Initial production ready release of Signet

• Subject Interface– Standalone component used by both to integrate with

external IdMS


Policy and Process


Need for Policy and Governance

• Involves more than tools and technology• Involves more than constituent requirements,

more than data stewards or a single business office

• Requires policy and governance to work well on an on-going basis to ensure appropriate access, privacy, and security – What are your risks?– What do you value?


Potential Drivers for IdM

• New systems/applications• Legislation and regulation

– FERPA, HIPAA, GLB

• Shrinking budgets and increasing demands for online services

• Protection of resources for ethical and business reasons

• Participation in an electronic consortium


Data Policy and Process Issues

• Business Process analysis– Who will determine whether to put new information in the

common infrastructure, and how it will be represented?• “Major” & “minor” affiliations• Entitlements• Group memberships

– If necessary info is not already collected, who will judge whether business processes should be changed to do so?

– Determine set of core principles that guide the use of and data stored in the IdM system


Dependent on Institutional Environment: Organizational, Policy & Legal Constraints

• Ownership of Data– Is data stewardship well-defined?– Is it centralized or distributed?

• Access to Data– Formally or loosely governed?– Access authority centralized or distributed?

• Data Administration– Centrally managed or distributed?– FERPA and HIPAA compliant?


Sample Core Data Principles/Policy• Data infrastructure serves more than one

institutional application.• Data is protected and requires permission for its

use unless declared “public” by the data custodians or owners.

• Access to private directory data must be granted for each application and be approved by the data stewards.

• Applications using that data should meet the security and data definition guidelines put forth by the technical service administrators.

• Data will be made available for all valid administrative and educational purposes.


Example: University of Michigan Data Resource Policy

• Institutional data resource is a University asset

• Data resource will be safeguarded/protected

• Data will be shared based on institutional policies

• Data will be managed as an institutional resource

• Institutional data will be identified and defined

• Databases will be developed based on functional needs

• Information quality will be actively managed


More Principles for Consideration• 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


Operational Policy and 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


Credentialing Policy and Process Issues

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


Specifically

• Who is eligible for electronic identity?• How are electronic identity credentials issued?

– Admin process– Technology

• Is the primary electronic identifier unique for all time to the individual? if not, what is the policy for reassignment and timeframe between uses?

• How is information in electronic identity database acquired and updated?

• What is public vs private info in the database?


Access Policy and Process Issues

• What are the entitlement or access policies for each service?– Which sets of affiliations are needed to evaluate

policies?– From which authoritative sources can these be

identified?– Who is authoritative for these policies?– What processes should determine entitlement

policies?


Use Policies and Processes

• What Policies Govern Use of Information? – What restrictions are placed on use of identity

information? – What assertions are acceptable for what

purposes?


Security and Privacy Policies

• How does this IdM infrastructure connect with broader security and privacy goals?

• Are there special security issues that must be considered when extending the IdM to a system (e.g. single sign-on, ERP)?

• What security will be in place to protect the IdM infrastructure?


Example: Access to Protected Resources

• Risk and trust requirements determined by the resource holder as well as the user who considers personal privacy risk. Taken together, these requirements determine the technologies and policies implemented.– At the low risk and low trust end . . .

• Risk management measures– Authentication and authorization standards– Security practices– Risk assessment– Change management controls– Audit trails


Test Your Policy/Process - Internally

• What might your central IT org ask of a peer campus id provider (central Library, Med Center) to decide whether to accept its id assertions for access to resources that the IT org controls?

• What might campus depts ask about the central identity mgmt system if they wanted to leverage it for use with its own applications?


Test Your Policy/Process - Externally

• What would you need to know about an electronic identity provider to make an informed decision whether to accept their assertions to manage access to your online resources or applications?

• What would you need to know about a resource provider to feel confident providing it info it might not otherwise be able to have?


Governance

• Why• Who • What


Role of Governance

• Prioritization of new development (if needed)• Review of data use requests and requests for

new data • On-going legal, source system, and policy

changes • Identity Management policy and decision-

making• Additions of new communities to the IdM

infrastructure


Role of Governance

Development of policy for:• Access and use of service for performance

and security implications • Service maintenance, management, and

changes – ie., logging• Attribute access and use derived from

campus policyDetermination of compliance requirements to

make certain the IdM meets policy and privacy directives


Resources

and

Wrap Up


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


Moral of the Story

• IdM is valuable & essential– Easier, more robust & secure environment

• Business systems analysis and policy, governance, & organizational process are critical aspects of IdM

• Access management needs to be distributed, and supportive tools & infrastructure are nearly there


One Key Resource to Help you Start Building the IdM Infrastructure

• Enterprise Directory Implementation Roadmap

http://www.nmi-edit.org/roadmap/directories.html

Parallel project planning paths:– Technology/Architecture– Policy/Management


More Resources• Websites

– www.nmi-edit.org• Development • Getting Started • Readiness Assessment Tool

– middleware.internet2.edu• Projects/software• Best practices/standards• Related national and international activities

• Workshops: Summer 2005 in Denver – CAMP Identity Management Integration Jun 27-29 – ADV CAMP Virtual Organizations Jun 30 - Jul 1


Acknowledgements

• Thanks to– Keith Hazelton, U of Wisconsin – Madison– Mike Berman, Cal Poly Pomona/Art Center

College of Design, Pasadena– Carrie Regenstein, U of Wisconsin – Madison– And all those we didn’t name…

• Thanks also to NSF for funding the NMI-EDIT Project


Questions

Tom BartonUniversity of [email protected]

Renee Woodten FrostUniversity of Michigan/[email protected]

Documents

Identity Management Systems: Policy, Technology, and Implementation Considerations