CAMP Med Identity and Access Management Terms and

CAMP Med Identity and Access Management: Terms and Concepts Keith Hazelton Sr. IT Architect, University of Wisconsin-Madison Internet 2 MACE CAMP Med, Tempe, AZ, February 9, 2005

CAMP Med Topics • What is Identity Management (Id. M)? • The Id. M Stone Age • A better vision for Id. M – An aside on the value of affiliation / group / privilege management services • Basic Id. M functions mapped to NMI/MACE components • Demands on IT and how Id. M services help 2

CAMP Med • What is Identity Management (Id. M)? “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? 3

CAMP Med Identity Management is… • “Hi! I’m Lisa. ” (Identity) • “…and here’s my Net. ID / password to prove it. ” (Authentication) • “I want to open the Portal to check my email. ” (Authorization : Allowing Lisa to use the services 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) 4

CAMP Med 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? 5

CAMP Med 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? 6

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

CAMP Med 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 8

CAMP Med The Id. M Stone Age • List of functions: • Auth. N: Authenticate principals (people, servers) seeking access to a service or resource • Log: Track access to services/resources 9

CAMP Med The Id. M Stone Age • Every application for itself in performing these functions • User list, credentials, if you’re on the list, you’re in (Auth. N is authorization (Auth. Z) • As Hobbes might say: Stone age Id. M “nasty, brutish & short on features” 10

CAMP Med Vision of a better way to do Id. M • Id. M 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 (So. R) & other Id. M components – Join: Establish & maintain person identity across So. R – … 11

CAMP Med 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 12

CAMP Med The pivotal concept of Id. M: 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) 13

CAMP Med Identity Information Access • Some direct from the Enterprise Directory via reflection from So. R • Other bits need to be made reachable by identifier crosswalks Registry ID Sys A ID Sys B ID Sys C ID Sys D ID 3 a 104 e 59 fsmith 32 86443 freds 864164 8 c 2 f 916 d abecker 1 45209 amyb 752731 14

CAMP Med Identity Information Reachability Registry ID Sys A ID Sys B ID Sys C ID Sys D ID 3 a 104 e 59 fsmith 32 86443 freds 864164 8 c 2 f 916 d abecker 1 45209 amyb 752731 • 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 15

CAMP Med Identity Information Reachability Registry ID Sys A ID Sys B ID Sys C ID Sys D ID 3 a 104 e 59 fsmith 32 86443 freds 864164 8 c 2 f 916 d abecker 1 45209 amyb 752731 • Key to reachability is less about technology, more about shared practice across system owners 16

CAMP Med 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 In. Common) 17

CAMP Med Vision of a better way to do Id. M • 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 Id. M info out to systems and services as required – Deliver: Make access control / authorization information available to services and resources at run time – Auth. Z: Make the allow deny decision independent of Auth. N 18

CAMP Med Policy issues re “credential” function: Net. ID • • • When to assign, activate (as early as possible) Who gets them? Applicants? Prospects? “Guest” Net. IDs (temporary, identity-less) Reassignment (never; except…) Who can handle them? Argument for Web. ISO. 19

CAMP Med A closer look at managing affiliations, groups and privileges • How does this help the harried IT staff? 20

CAMP Med Authorization, the early years • Id. M 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 21

CAMP Med 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 22

CAMP Med Authorization, the early years • Bringing in groups to deal with the scaling problem • Here groups are being used to carry affiliations or “roles” 23

CAMP Med Thanks to: jbarkley@nist. gov 24

CAMP Med 25

CAMP Med 26

CAMP Med 27

CAMP Med Groups and affiliation management software? • Middleware Architecture Committee for Education (MACE) in Internet 2 sponsoring the Grouper project – Infrastructure at University of Chicago – User interface at Bristol University in UK – $upport from NSF Middleware Initiative (NMI) • http: //middleware. internet 2. edu/dir/groups 28

CAMP Med Role- and Privilege-based Auth. Z • 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 29

CAMP Med Roles (cf. edu. Person. Is. Member. Of) • 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 30

CAMP Med Privileges (cf. edu. Person. Entitlement) • 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 31

CAMP Med 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 32

CAMP Med Privilege Management software? • Project Signet of Internet 2 MACE – Development based at Stanford – $upport from NSF Middleware Initiative • http: //middleware. internet 2. edu/signet 33

CAMP Med Basic Id. M functions mapped to the NMI / MACE components Systems of Record Enterprise Directory Stdnt Other 34 LDAP Registry HR

CAMP Med A successful enterprise directory attracts 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? 35

CAMP Med Basic Id. M functions mapped to the NMI / MACE components Apps / Resources Enterprise Directory Systems of Record Web. ISO Grouper Signet Shibboleth 36

CAMP Med Provisioning Apps / Resources Enterprise Directory Systems of Record Web. ISO Grouper Signet Shibboleth 37

CAMP Med Two modes of app/Id. M integration • Domesticated applications: – Provide them the full set of Id. M functions • Applications with attitude (comes in the box) – Meet them more than halfway by provisioning 38

CAMP Med 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 39

CAMP Med 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 40

CAMP Med Same Id. M functions, different packaging • Your Id. M infrastructure (existing or planned) may have different boxes & lines • But somewhere, somehow this set of Id. M functions is getting done • Gives us all a way to compare our solutions by looking at various packagings of the Id. M functions 41

CAMP Med Id. M functions Reflect Join Credential Manage Affil/Groups Manage Privileges Provision Deliver Authenticate Authorize Log Data of interest Identity across So. R Net. ID, other Auth. Z info More Auth. Z info For apps w attitude Get Auth. Z info to app Check identity claim Make allow/deny decision Track usage for audit 42

CAMP Med Alternative packaging of basic Id. M functions: Single System of Record as Enterprise Directory 43 LDAP Registry Student -HR Info System

CAMP Med Single So. R 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 Id. M functions 44

CAMP Med Alternative packaging of basic Id. M Apps / Resources Enterprise Directory Systems of Record Kerberos LDAP Directory Plug-ins 45

CAMP Med 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 46

CAMP Med What else is IT being asked to do? • Student record access for life • Submission and/or maintenance of information online • Privacy protection 47

CAMP Med 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 48

CAMP Med More on the To Do list • Serve new populations (alumni, applicants, …) • More requests for new services and new combinations of services • Increased interest in e. Business • There is an Identity Management aspect to each and every one of these items 49

CAMP Med How full Id. M layer helps • Improves scalability: Id. M 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 50

CAMP Med Q&A Reflect Join Credential Manage Affil/Groups Manage Privileges Provision Deliver Authenticate Authorize Log Data of interest Identity across So. R Net. ID, other Auth. Z info More Auth. Z info For apps w attitude Get Auth. Z info to app Check identity claim Make allow/deny decision Track usage for audit 51

CAMP Med Appendix: Id. M 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 52

CAMP Med 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 53

CAMP Med 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 noticed until after go-live Or implementors did their best to work around the problems Or, sometimes, the project stalled 54

CAMP Med Responding to requests: A new approach at UW-Madison • Campus leaders are defining new ways of channeling and responding to requests • Groups like the Auth. NZ 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* 55

CAMP Med 56

CAMP Med Responding to requests: A new approach • The Identity Management Leadership Group (IMLG) will provide leadership on Id. M issues when responding to: • Submission and/or maintenance of information online • Privacy protection • Increased compliance demands • Increased security threats 57

CAMP Med 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 58

CAMP Med One key resource to help you start building the Id. M infrastructure • Enterprise Directory Implementation Roadmap http: //www. nmi-edit. org/roadmap/ directories. html • Parallel project planning paths: – Technology/Architecture – Policy/Management 59