Identity Management Systems: Policy, Technology, and Implementation Considerations

1. Identity Management Systems: Policy, Technology, and Implementation Considerations Tom Barton, University of Chicago Renee Woodten Frost, University of Michigan and Internet2 21 March 2005

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 EDUCAUSE Midwest Regional 2

3. 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 EDUCAUSE Midwest Regional 3

4. 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? EDUCAUSE Midwest Regional 4

5. 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) EDUCAUSE Midwest Regional 5

6. 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) EDUCAUSE Midwest Regional 6

7. 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? EDUCAUSE Midwest Regional 7

8. 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 EDUCAUSE Midwest Regional 8

9. 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 EDUCAUSE Midwest Regional 9

10. 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 EDUCAUSE Midwest Regional 10

11. 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) EDUCAUSE Midwest Regional 11

12. 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 EDUCAUSE Midwest Regional 12

13. 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 EDUCAUSE Midwest Regional 13

14. 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 • … EDUCAUSE Midwest Regional 14

15. 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 EDUCAUSE Midwest Regional 15

16. IdM Functions EDUCAUSE Midwest Regional 16

17. 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 EDUCAUSE Midwest Regional 17

18. 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) EDUCAUSE Midwest Regional 18

19. 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 EDUCAUSE Midwest Regional 19

20. 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) EDUCAUSE Midwest Regional 20

21. A Closer Look at Managing Affiliations, Groups and Privileges • How does this help the harried IT staff? EDUCAUSE Midwest Regional 21

22. 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 EDUCAUSE Midwest Regional 22

23. 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 EDUCAUSE Midwest Regional 23

24. Thanks to: jbarkley@nist.gov EDUCAUSE Midwest Regional 24

25. Authorization, the Early Years • Bringing in groups to deal with the scaling problem • Here groups are being used to carry affiliations or “roles” EDUCAUSE Midwest Regional 25

26. EDUCAUSE Midwest Regional 26

27. 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 EDUCAUSE Midwest Regional 27

28. 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 EDUCAUSE Midwest Regional 28

29. 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 EDUCAUSE Midwest Regional 29

30. 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 EDUCAUSE Midwest Regional 30

31. Privilege Management Feature Summary EDUCAUSE Midwest Regional 31

32. Privilege Management Software? • Project Signet of Internet2 MACE • Development based at Stanford • $upport from NSF Middleware Initiative • http://middleware.internet2.edu/signet EDUCAUSE Midwest Regional 32

33. Basic IdM functions Enterprise Directory Systems of Record Stdnt Registry LDAP Reflect HR Join Other Credential EDUCAUSE Midwest Regional 33

34. IdM Components and Functional Requirements EDUCAUSE Midwest Regional 34

35. Provisioning Apps / Resources Enterprise Directory AuthN Systems of Record AuthN Log Reflect Provision Join Credential AuthZ Mng. Affil. Mng. Priv. Deliver Log EDUCAUSE Midwest Regional 35

36. 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 EDUCAUSE Midwest Regional 36

37. 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 EDUCAUSE Midwest Regional 37

38. 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 EDUCAUSE Midwest Regional 38

39. 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 EDUCAUSE Midwest Regional 39

40. 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? EDUCAUSE Midwest Regional 40

41. 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 EDUCAUSE Midwest Regional 41

42. 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 EDUCAUSE Midwest Regional 42

43. IdM Functions EDUCAUSE Midwest Regional 43

44. EDUCAUSE Midwest Regional 44

45. 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 EDUCAUSE Midwest Regional 45

46. Functional Requirements for Managing Identity Information • 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 EDUCAUSE Midwest Regional 46

47. Functional Requirements for Managing Identity Information • 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 EDUCAUSE Midwest Regional 47

48. Tools for Distributed Management of Access and Authority EDUCAUSE Midwest Regional 48

49. 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 EDUCAUSE Midwest Regional 49

50. Relative Roles of Signet & Grouper 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 Grouper Signet EDUCAUSE Midwest Regional 50