Identity and Access Management: Terms and Concepts

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

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

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

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

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

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

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

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

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

10. 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” 10

11. 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 • … 11

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

13. 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) 13

14. Identity Information Access • Some direct from the Enterprise Directory via reflection from SoR • Other bits need to be made reachable by identifier crosswalks 14

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

16. Identity Information Reachability • Key to reachability is less about technology, more about shared practice across system owners 16

17. 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) 17

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

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

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

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

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

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

24. Thanks to: jbarkley@nist.gov 24

25. 25

26. 26

27. 27

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

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

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

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

32. Privilege Management Feature Summary 32

33. Privilege Management software? • Project Signet of Internet2 MACE • Development based at Stanford • $upport from NSF Middleware Initiative • http://middleware.internet2.edu/signet 33

34. Basic IdM functions mapped to theNMI / MACE components Enterprise Directory Systems of Record Stdnt Registry LDAP Reflect HR Join Other Credential 34

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

36. Basic IdM functions mapped to theNMI / MACE components Apps / Resources Enterprise Directory AuthN Systems of Record AuthN Log Reflect Provision Join WebISO Credential AuthZ Mng. Affil. Mng. Priv. Deliver Log Grouper Signet Shibboleth 36

37. Provisioning Apps / Resources Enterprise Directory AuthN Systems of Record AuthN Log Reflect Provision Join WebISO Credential AuthZ Mng. Affil. Mng. Priv. Deliver Log Grouper Signet Shibboleth 37

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

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

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

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

42. IdM functions 42

43. Alternative packaging of basic IdM functions: Single System of Record as Enterprise Directory Student -HR Info System Registry LDAP "Join" Reflect Credential 43

44. Single 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 44

45. Alternative packaging of basic IdM Apps / Resources Enterprise Directory AuthN Systems of Record AuthN Log Reflect Provision Join Kerberos Credential AuthZ LDAP Mng. Affil. Deliver Log Directory Plug-ins 45

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

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

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

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

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