identity and access management: a functional model

98
CAMP Integration Identity and Access Management: a Functional Model http://arch.doit.wisc.edu/keith/ camp/ iamintro-050627-01.ppt Keith Hazelton ([email protected]) Sr. IT Architect, University of Wisconsin-Madison Internet2 MACE CAMP Integration, Denver, June 27, 2005

Upload: emelda

Post on 10-Jan-2016

16 views

Category:

Documents


1 download

DESCRIPTION

Identity and Access Management: a Functional Model. http://arch.doit.wisc.edu/keith/camp/ iamintro-050627-01.ppt Keith Hazelton ([email protected]) Sr. IT Architect, University of Wisconsin-Madison Internet2 MACE CAMP Integration, Denver, June 27, 2005. Topics. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Identity and Access Management: a Functional Model

CAMP Integration

Identity and Access Management:a Functional Model

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

iamintro-050627-01.ppt

Keith Hazelton ([email protected])

Sr. IT Architect, University of Wisconsin-Madison

Internet2 MACE

CAMP Integration, Denver, June 27, 2005

Page 2: Identity and Access Management: a Functional Model

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

Page 3: Identity and Access Management: a Functional Model

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?

Page 4: Identity and Access Management: a Functional Model

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)

Page 5: Identity and Access Management: a Functional Model

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?

Page 6: Identity and Access Management: a Functional Model

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

Page 7: Identity and Access Management: a Functional Model

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

Page 8: Identity and Access Management: a Functional Model

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”

Page 9: Identity and Access Management: a Functional Model

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

Page 10: Identity and Access Management: a Functional Model

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

Page 11: Identity and Access Management: a Functional Model

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

Page 12: Identity and Access Management: a Functional Model

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

Page 13: Identity and Access Management: a Functional Model

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

Page 14: Identity and Access Management: a Functional Model

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

Page 15: Identity and Access Management: a Functional Model

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

Page 16: Identity and Access Management: a Functional Model

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

Page 17: Identity and Access Management: a Functional Model

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

Page 18: Identity and Access Management: a Functional Model

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

Page 19: Identity and Access Management: a Functional Model

19

CAMP Integration Basic IAM functions mapped to theNMI / MACE components

Systems of Record

Stdnt

HR

Other

Enterprise Directory

Registr

y LD

AP

Page 20: Identity and Access Management: a Functional Model

20

CAMP Integration Basic IAM functions mapped to theNMI / MACE components

System

s of R

ecord

Enterprise Directory

Grouper Signet

WebISO

Shibboleth

Apps / Resources

Page 21: Identity and Access Management: a Functional Model

21

CAMP Integration

Alternative packaging of basic IdM

System

s of R

ecord

Enterprise Directory

Directory

Plug-ins

Kerberos

Apps / Resources

LDAP

Page 22: Identity and Access Management: a Functional Model

22

CAMP Integration Alternative packaging of basic IdM functions:

Single System of Record as Enterprise Directory

Registr

y LD

AP

Student

-HR

Info

System

Page 23: Identity and Access Management: a Functional Model

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

Page 24: Identity and Access Management: a Functional Model

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

Page 25: Identity and Access Management: a Functional Model

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

Page 26: Identity and Access Management: a Functional Model

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

Page 27: Identity and Access Management: a Functional Model

27

CAMP Integration Middleware -- Application Integration

• ERPs

• SAKAI

• uPortal

• …

Page 28: Identity and Access Management: a Functional Model

28

CAMP Integration IAM and Application Integration

Page 29: Identity and Access Management: a Functional Model

29

CAMP Integration

Inter-institutional integration

• Virtual Organization (VOs)

• Federations

• League of Federations– The Interfederation Interoperability Working

Group (IIWG). yes, it’s real

Page 30: Identity and Access Management: a Functional Model

30

CAMP Integration

Q & A

Page 31: Identity and Access Management: a Functional Model

CAMP Integration

Exceedingly Brief Intro to Shibboleth & Federations

Tom Barton, University of Chicago

Page 32: Identity and Access Management: a Functional Model

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

Page 33: Identity and Access Management: a Functional Model

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. ???

Page 34: Identity and Access Management: a Functional Model

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

Page 35: Identity and Access Management: a Functional Model

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

Page 36: Identity and Access Management: a Functional Model

36

CAMP Integration

Shibboleth

Athenticate at home org

Authorize at resource without knowing user’s identity

Page 37: Identity and Access Management: a Functional Model

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

Page 38: Identity and Access Management: a Functional Model

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

Page 39: Identity and Access Management: a Functional Model

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

Page 40: Identity and Access Management: a Functional Model

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

Page 41: Identity and Access Management: a Functional Model

41

CAMP Integration

Page 42: Identity and Access Management: a Functional Model

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

Page 43: Identity and Access Management: a Functional Model

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

Page 44: Identity and Access Management: a Functional Model

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.

Page 45: Identity and Access Management: a Functional Model

45

CAMP Integration

Basic IAM functions mapped to theNMI / MACE components

System

s of R

ecord

Enterprise Directory

Grouper Signet

WebISO

Shibboleth

Apps / Resources

Page 46: Identity and Access Management: a Functional Model

46

CAMP Integration IAM functions & big pictures

Reflect

Join

Credential

Provide/run-time

(AuthN)

Provide/provision

AuthZ

Manage Grps

Manage Privs

Log

Page 47: Identity and Access Management: a Functional Model

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

Page 48: Identity and Access Management: a Functional Model

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?

Page 49: Identity and Access Management: a Functional Model

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)

Page 50: Identity and Access Management: a Functional Model

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?

Page 51: Identity and Access Management: a Functional Model

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?

Page 52: Identity and Access Management: a Functional Model

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

Page 53: Identity and Access Management: a Functional Model

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

Page 54: Identity and Access Management: a Functional Model

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

Page 55: Identity and Access Management: a Functional Model

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”

Page 56: Identity and Access Management: a Functional Model

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

Page 57: Identity and Access Management: a Functional Model

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

Page 58: Identity and Access Management: a Functional Model

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)

Page 59: Identity and Access Management: a Functional Model

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)

Page 60: Identity and Access Management: a Functional Model

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

Page 61: Identity and Access Management: a Functional Model

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.

Page 62: Identity and Access Management: a Functional Model

62

CAMP Integration

A closer look at managing affiliations, groups and privileges

• How does this help the harried IT staff?

Page 63: Identity and Access Management: a Functional Model

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

Page 64: Identity and Access Management: a Functional Model

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

Page 65: Identity and Access Management: a Functional Model

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”

Page 66: Identity and Access Management: a Functional Model

66

CAMP Integration

Thanks to: [email protected]

Page 67: Identity and Access Management: a Functional Model

67

CAMP Integration

Page 68: Identity and Access Management: a Functional Model

68

CAMP Integration

Page 69: Identity and Access Management: a Functional Model

69

CAMP Integration

Page 70: Identity and Access Management: a Functional Model

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

Page 71: Identity and Access Management: a Functional Model

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

Page 72: Identity and Access Management: a Functional Model

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

Page 73: Identity and Access Management: a Functional Model

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

Page 74: Identity and Access Management: a Functional Model

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

Page 75: Identity and Access Management: a Functional Model

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

Page 76: Identity and Access Management: a Functional Model

76

CAMP Integration

Basic IdM functions mapped to theNMI / MACE components

Systems of Record

Stdnt

HR

Other

Enterprise Directory

Registr

y LD

AP

Page 77: Identity and Access Management: a Functional Model

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?

Page 78: Identity and Access Management: a Functional Model

78

CAMP Integration

Basic IdM functions mapped to theNMI / MACE components

System

s of R

ecord

Enterprise Directory

Grouper Signet

WebISO

Shibboleth

Apps / Resources

Page 79: Identity and Access Management: a Functional Model

79

CAMP Integration

Provisioning

System

s of R

ecord

Enterprise Directory

Grouper Signet

WebISO

Shibboleth

Apps / Resources

Page 80: Identity and Access Management: a Functional Model

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

Page 81: Identity and Access Management: a Functional Model

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

Page 82: Identity and Access Management: a Functional Model

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

Page 83: Identity and Access Management: a Functional Model

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

Page 84: Identity and Access Management: a Functional Model

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

Page 85: Identity and Access Management: a Functional Model

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

Page 86: Identity and Access Management: a Functional Model

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

Page 87: Identity and Access Management: a Functional Model

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

Page 88: Identity and Access Management: a Functional Model

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

Page 89: Identity and Access Management: a Functional Model

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

Page 90: Identity and Access Management: a Functional Model

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

Page 91: Identity and Access Management: a Functional Model

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

Page 92: Identity and Access Management: a Functional Model

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

Page 93: Identity and Access Management: a Functional Model

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

Page 94: Identity and Access Management: a Functional Model

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*

Page 95: Identity and Access Management: a Functional Model

95

CAMP Integration

Page 96: Identity and Access Management: a Functional Model

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

Page 97: Identity and Access Management: a Functional Model

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

Page 98: Identity and Access Management: a Functional Model

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