CAMP Integration

Identity and Access Management:a Functional Model

http://arch.doit.wisc.edu/keith/camp/

iamintro-050627-01.ppt

Keith Hazelton (hazelton@doit.wisc.edu)

Sr. IT Architect, University of Wisconsin-Madison

Internet2 MACE

CAMP Integration, Denver, June 27, 2005

2

CAMP Integration Topics

• What is Identity and Access Management (IAM)?

• The IAM Stone Age• A better vision for IAM• Basic IAM functions mapped to NMI/MACE

components• Integration as a theme

3

CAMP Integration Identity and Access Management(IAM) defined

• What is Identity Management?“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)

• Identity Management in this sense is often called “Identity and Access Management” (IAM)

• What problems do Identity and Access Management address?

4

CAMP Integration IAM is…

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

(Authentication)• “I want to do some E-Reserves reading.”

(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)

5

CAMP Integration IAM 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?

6

CAMP Integration 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?• Policy/process issues lurk nearby

7

CAMP Integration The IAM Stone Age

• List of functions:

• AuthN: Authenticate principals (people, servers) seeking access to a service or resource

• Log: Track access to services/resources

8

CAMP Integration The IAM 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 IAM “nasty, brutish & short on features”

9

CAMP Integration Vision of a better way to do IAM

• IAM 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– …

10

CAMP Integration 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

11

CAMP Integration The pivotal concept of IAM: 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 collected systems

12

CAMP Integration Identity Information Access

• Some direct from the Enterprise Directory via reflection from SoR

• Other bits need to be made reachable by identifier crosswalks

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

3a104e59 fsmith32 86443 freds 864164

8c2f916d abecker1 45209 amyb 752731

13

CAMP Integration Identity Information Reachability

• In System B, to get info from System D– Lookup Sys D ID in identifier crosswalk– Use whatever means Sys D provides to access info

• For new apps, leverage join by carrying Registry ID as a foreign key--even if not in crosswalk

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

3a104e59 fsmith32 86443 freds 864164

8c2f916d abecker1 45209 amyb 752731

14

CAMP Integration Identity Information Reachability

• 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

15

CAMP Integration Identity Fragmentation Cure #2

• When you can’t integrate, federate• Federated Identity & Access Management

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

– To authenticate and pass authorization-related information to service providers or resource hosts

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

InCommon)

• Shibboleth is a way to move the authNZ info between parties

16

CAMP Integration Vision of a better way to do IAM

• More in the expanded set of basic functions– Credential: issue digital credentials to people in

the community– Mng. Affil.: Manage affiliation and group

information– Mng. Priv.: Manage privileges and permissions at

system and resource level

17

CAMP Integration Managing Roles & Privileges:The Internet2 way

Grouper Signet

Role-Based Access Control (RBAC) model

• Users are placed into groups

• Privileges are assigned to groups

• Groups can be arranged into hierarchies to effectively bestow privileges

• Signet manages privileges

• Grouper manages, well, groups

18

CAMP Integration Vision of a better way to do IAM

• More in the expanded set of basic functions– Provision: Push IAM info out to systems and

services as required– Relay: Make access control / authorization

information available to services and resources at run time

– AuthZ: Make the allow deny decision independent of AuthN

19

CAMP Integration Basic IAM functions mapped to theNMI / MACE components

Systems of Record

Stdnt

HR

Other

Enterprise Directory

Registr

y LD

AP

20

CAMP Integration Basic IAM functions mapped to theNMI / MACE components

System

s of R

ecord

Enterprise Directory

Grouper Signet

WebISO

Shibboleth

Apps / Resources

21

CAMP Integration

Alternative packaging of basic IdM

System

s of R

ecord

Enterprise Directory

Directory

Plug-ins

Kerberos

Apps / Resources

LDAP

22

CAMP Integration Alternative packaging of basic IdM functions:

Single System of Record as Enterprise Directory

Registr

y LD

AP

Student

-HR

Info

System

23

CAMP IntegrationSingle SoR as Enterprise Directory

• Who “owns” the system?• Do they see themselves as running shared

infrastructure?• Will any “external” populations ever become

“internal?”– What if hospital negotiates a deal?

• Stress-test alternative packaging by thinking through the list of basic IdM functions

24

CAMP Integration IAM functions

Reflect Data of interest

Join Identity across SoR

Credential NetID, other

Manage Affil/Groups AuthZ info

Manage Privileges More AuthZ info

Provision Gen. AuthNZ info into app space

Relay AuthZ info to app on request

Authenticate Identity claim

Authorize access decision (allow/deny)

Log usage for audit, accounting,…

25

CAMP Integration From Construction to Integration

• Construction– Raw materials into systems

• Integration – Subsystems into whole systems– Multiple systems into ecosystems

• We’re all moving from construction to integration

• Let’s review state of middleware systems’ readiness for integration

26

CAMP Integration

Next-up integration services

• Message queuing (pub-sub, point-to-point)

• Workflow (business process orchestration)

• Policy info mgmt

• Policy decision point

• Service Oriented Architecture (SOA) as current buzz-word for the overall vision– The vision will outlast the name

27

CAMP Integration Middleware -- Application Integration

• ERPs

• SAKAI

• uPortal

• …

28

CAMP Integration IAM and Application Integration

29

CAMP Integration

Inter-institutional integration

• Virtual Organization (VOs)

• Federations

• League of Federations– The Interfederation Interoperability Working

Group (IIWG). yes, it’s real

30

CAMP Integration

Q & A

CAMP Integration

Exceedingly Brief Intro to Shibboleth & Federations

Tom Barton, University of Chicago

32

CAMP Integration

Mike Neuman’s Issues

1. Walk-ins

2. Administrative permits & denies (whitelist, blacklist, any individually granted or revoked access)

3. Multiple IdPs within a single campus

33

CAMP Integration

Alternatives to IP Address Based Access Restriction

1. User-based access restrictionA. Each service provider manages credentials for

all of its users

B. One big credential database of all users used by all service providers

C. Each user has a “home organization” whose credential database can, by magic, be used by each service provider

2. ???

34

CAMP Integration

Federated Identities

• “Federated identities” is option C on previous slide– A hierarchical approach to decompose the problem into

manageable pieces– Analogous to the problem that IAM addresses, and rests

upon IAM infrastructure

• “Federating technology” is the “magic” part of option C

• “Identity federation” (noun) is a set of service providers, identity providers, and other context in which the magic happens

35

CAMP Integration

Federating Technologies• SAML implementations

– Security Assertion Markup Language

– Shibboleth– Bodington/Guanxi– AthensIM– SourceID– SAMUEL– MS ADFS– Other proprietary

• Liberty Identity Federation implementations– SourceID– Lasso– Proprietary

• Others– MS Inter-Forest Trust

36

CAMP Integration

Shibboleth

Athenticate at home org

Authorize at resource without knowing user’s identity

37

CAMP Integration

Shibboleth Underpinnings

• Elements of shibboleth infrastructure must identify and authenticate each other– Home org or Identity Provider (IdP) pieces– Resource or Service Provider (SP) pieces

• Attribute assertions about authenticated principals are sent from IdPs to SPs

• For it all to work, IdPs and SPs must agree about which attributes and values are tossed around, and their semantics

38

CAMP Integration

Federation Value Proposition

• Set of cooperating IdPs and SPs forms a community needing agreement on:– Trust Fabric

• X.509 certs• IdP and SP identifiers & other metadata

– Community standard for attribute semantics– Community standards for IdP and SP operational practices

• Strength of authentication• Confidentiality

• For N IdPs and M SPs, which is easier?– N*M agreements– N+M agreements

39

CAMP Integration

Federations …

• Might support trust fabric maintenance– Operate a metadata distribution service

• Might be the locus for attribute standards• Might be the locus for “minimum but sufficient” IdP

and SP operational practice standards• Are not a party to the transactions between IdPs and

SPs• Are not involved with entitling access to resources

40

CAMP Integration

The Research and EducationFederation Space

REFCluster

InQueue(a starting point)

InCommon

SWITCH

The ShibResearch Club

Other national nets

Other clusters

Other potential USR+E feds

State of Penn Fin Aid Assoc

NSDL

Slippery slope- Med Centers, etc

Indiana

41

CAMP Integration

42

CAMP Integration

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

43

CAMP Integration

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

• In all of these, a full IAM infrastructure would provide the technical part of a solution

44

CAMP IntegrationPolicy issues re “credential” function: NetID

• When to assign, activate (as early as possible)

• Who gets them? Applicants? Prospects?

• “Guest” NetIDs (temporary, identity-less)

• Reassignment (never; except…)

• Who can handle them? Argument for WebISO.

45

CAMP Integration

Basic IAM functions mapped to theNMI / MACE components

System

s of R

ecord

Enterprise Directory

Grouper Signet

WebISO

Shibboleth

Apps / Resources

46

CAMP Integration IAM functions & big pictures

Reflect

Join

Credential

Provide/run-time

(AuthN)

Provide/provision

AuthZ

Manage Grps

Manage Privs

Log

47

CAMP Integration

Topics

• What is Identity Management (IdM)?• The IdM Stone Age• A better vision for IdM

– An aside on the value of affiliation / group / privilege management services

• Basic IdM functions mapped to NMI/MACE components

• Demands on IT and how IdM services help

48

CAMP Integration

• What is Identity Management (IdM)?“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)

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

• What problems does Identity Management solve?

49

CAMP Integration

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)

50

CAMP Integration

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?

51

CAMP Integration

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?

52

CAMP Integration

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

53

CAMP Integration

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

54

CAMP Integration

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

55

CAMP Integration

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”

56

CAMP Integration

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– …

57

CAMP Integration

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

58

CAMP Integration

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 collected systems

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

59

CAMP Integration

Identity Fragmentation Cure #2

• When you can’t integrate, 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)

60

CAMP Integration

Vision of a better way to do IdM

• More in the expanded set of basic functions– Credential: issue digital credentials to people in the

community– 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

61

CAMP Integration

Policy issues re “credential” function: NetID

• When to assign, activate (as early as possible)

• Who gets them? Applicants? Prospects?

• “Guest” NetIDs (temporary, identity-less)

• Reassignment (never; except…)

• Who can handle them? Argument for WebISO.

62

CAMP Integration

A closer look at managing affiliations, groups and privileges

• How does this help the harried IT staff?

63

CAMP Integration

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

64

CAMP Integration

Authorization, the early years

• 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

65

CAMP Integration

Authorization, the early years

• Bringing in groups to deal with the scaling problem

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

66

CAMP Integration

Thanks to: jbarkley@nist.gov

67

CAMP Integration

68

CAMP Integration

69

CAMP Integration

70

CAMP Integration

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)

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

71

CAMP Integration

Role- and Privilege-based AuthZ

• Privileges are what you can do • Roles are who you are, which can be

the used for policy-based privileges • Both are viable, complementary for

authorization

72

CAMP Integration

Roles (cf. eduPersonIsMemberOf)

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

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

73

CAMP Integration

Privileges (cf. eduPersonEntitlement)

• Permissions should be same across service providers

• Service providers do not need to know rules behind authorizatione.g. Building access regardless of why -- has

office in building, taking class in building,

authorized by building manager

74

CAMP IntegrationPrivilege 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 projectsup to $100,000

limits

until January 1, 2006 condition

75

CAMP Integration

Privilege Management software?

• Project Signet of Internet2 MACE– Development based at Stanford

– $upport from NSF Middleware Initiative

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

76

CAMP Integration

Basic IdM functions mapped to theNMI / MACE components

Systems of Record

Stdnt

HR

Other

Enterprise Directory

Registr

y LD

AP

77

CAMP Integration

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?

78

CAMP Integration

Basic IdM functions mapped to theNMI / MACE components

System

s of R

ecord

Enterprise Directory

Grouper Signet

WebISO

Shibboleth

Apps / Resources

79

CAMP Integration

Provisioning

System

s of R

ecord

Enterprise Directory

Grouper Signet

WebISO

Shibboleth

Apps / Resources

80

CAMP Integration

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

81

CAMP Integration

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

82

CAMP Integration

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

83

CAMP Integration

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

84

CAMP Integration 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

85

CAMP Integration

What is IT being asked to do?

• Automatic creation and deletion of computer accounts

• Personnel records access for legal compliance• One stop for university services (portal)

integrated with course management systems

86

CAMP Integration

What else is IT being asked to do?

• Student record access for life• Submission and/or maintenance of information

online• Privacy protection

87

CAMP Integration

More on the To Do list

• Stay in compliance with a growing list of policy mandates

• Increase the level of security protections in the face of a steady stream of new threats

88

CAMP Integration

More on the To Do list

• Serve new populations (alumni, applicants,…)• More requests for new services and new

combinations of services• Increased interest in eBusiness

• There is an Identity Management aspect to each and every one of these items

89

CAMP Integration

How full IdM layer helps

• Improves scalability: IdM process automation

• Reduces complexity of IT ecosystem– Complexity as friction (wasted resources)

• Improved user experience

• Functional specialization: App developer can concentrate on app-specific functionality

90

CAMP Integration Q & A

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

91

CAMP Integration

Appendix: IdM and the rise of policy concerns

• New systems and applications have come in two primary ways

1. A campus unit approaches a central IT group to build a new application

2. Some Request for Proposal (RFP) process leads to a new system

92

CAMP Integration

1) A campus unit approaches a Central IT group to build a new application

• If the IT group encountered policy issues– It had no standard place to turn for answers– Technologists either made policy decisions– Or they referred the issue back to the requestor– Or, sometimes, the project stalled

93

CAMP Integration

2) RFP process leads to purchase of a new system

• If the new system affected business process and/or policies

– The campus struggled to create a forum to address the issues

– Or the effect was not noticed until after go-live– Or implementors did their best to work around

the problems– Or, sometimes, the project stalled

94

CAMP Integration

Responding to requests:A new approach at UW-Madison

• Campus leaders are defining new ways of channeling and responding to requests

• Groups like the AuthNZ Coordinating Team (ACT) anticipate policy issues and sort through the concerns

• They route findings and recommendations to the CIO office

• The CIO Office take the issue to an appropriate campus body*

95

CAMP Integration

96

CAMP Integration

Responding to requests:A new approach

• The Identity Management Leadership Group (IMLG) will provide leadership on IdM issues when responding to:

• Submission and/or maintenance of information online

• Privacy protection• Increased compliance demands• Increased security threats

97

CAMP Integration

Why a new group?

• Technology is now more robust and services are considered foundational to the institution

• Broader scope, e.g., new populations

• New policy issues and more of them

• Need for flexibility and quick turn-around time

98

CAMP Integration

One key resource to help you start building the IdM infrastructure

• Enterprise Directory Implementation Roadmaphttp://www.nmi-edit.org/roadmap/ directories.html

• Parallel project planning paths:– Technology/Architecture

– Policy/Management