Identity and Access Management: Why It Matters

1. Identity and Access Management: Why It MattersAAMC’s Journey of Discovery Kirke B. Lawton Director, Enterprise Data February 9, 2005

2. Who am I (disclaimers) • I am not a… • Certified ______, lawyer, computer scientist, engineer, etc. • I am not an expert of HIPAA, hospital and healthcare regulations or hospital or university business practices. • Background in social sciences, statistics and data management. • Mostly self-taught on topics of software design and development.

3. Topics/Goals • Explain what we, the AAMC, have done regarding identity management in recent years. • Introduction to CBRS and the AAMC ID. • Our (on-going) efforts to improve (simplify, standardize, extend) our access-control methods. • SLAM as a case-study. • Encourage you to think “Hey, if they can do it, so can we.”

4. Who is the AAMC - the public view • Our Members • the 125 accredited U.S. medical schools • the 17 accredited Canadian medical schools • some 400 major teaching hospitals, including 98 affiliated health systems and 68 Veterans Affairs medical centers • 94 academic and professional societies, representing 109,000 faculty members • the nation's 67,000 medical students and 104,000 residents

5. Who is the AAMC - the public view • What We Do • The AAMC represents and supports our constituents through a broad array of programs and studies: • We work with our members to set a national agenda for medical education, biomedical research, and health care. • We provide services at the national level that help our members accomplish their missions. • We strive to strengthen the quality of medical education and training, to enhance the search for biomedical knowledge, to advance research in health sciences, and to integrate education into the provision of effective health care.

6. Who is the AAMC - the public view • The administrative leadership of medical schools and teaching hospitals are served by a variety of professional development groups housed within the AAMC. • The AAMC provides services to those entering the medical field, including • American Medical College Application Service (AMCAS), • The Medical College Admissions Test (MCAT) • The Electronic Residency Application Service (ERAS), • MEDLOANS, and • The National Resident Matching Service.

7. Who is the AAMC - a view from the IS trenches • Us: the Office of Information Resources (OIR) • 6 development project teams (4-12 per team) • Infrastructure, quality/testing, production services, help desk staff. • Our Customers: Dozens of divisions and sections representing AAMC groups and services. • 350+ AAMC employees; 70+ “management staff” • Over 2 dozen governance and professional development groups. • A dozen or so major, high-profile services • Well over 100 “lesser” applications and surveys (now almost entirely Web-based). Many revised annually. • For the most part customers are “assigned” to a particular development team/project manager.

8. Where we stood circa 1998 • Migrating away from long-established mainframe apps. • Deploying new Web-based replacements. • Membership tracking system in need of replacement. • SSN used (imperfectly) to link person data. • Little commonality between systems, few linkages. • Research data warehouse used to integrate data.

9. Major Goals in 1998 • Convert old mainframe membership system to be a better integrated, more encompassing enterprise database with user-friendly tools. (STARS project) • Convert the AMCAS system from a mail-in diskette service to a Web-based service. • Improve the utility of the data warehouse. • Common element: all needed a way to uniquely identify people

10. Enter the AAMC ID • Obvious need for an “AAMC ID” personal identifier everything could use. • Less obvious was how to • Assign AAMC IDs to our hundreds of thousands of records from diverse systems. • Assign AAMC IDs in real time for applications. • Manage the AAMC ID data. • The solution: hard work and hubris.

11. Enter CBRS • Decided to “spin off” a stand-alone system for just doing AAMC IDs. • “Common Biographical Record System” (CBRS). • An Oracle database with it’s own specialized view of every person. • Explicitly designed and advertised as a “black box” to preempt attempts to repurpose the data (and get saddled with other requirements). • Exposed to the “world” via a single API “CBRS_get_aamc_id()”

12. The Fundamental CBRS Responsibility is to Match People with AAMC_IDs Input Output CBRS “Black Box” A person’s name, SSN and/or other ID information An AAMC_ID Internal AAMC presentation Sept 1999

13. Opening the CBRS Black Box • Services Inside the Black Box • Matching algorithms • Updates/additions of records • Web interactivity • Bulk processing • Review/handling of pending data • Communications with other systems • Query capabilities (limited) • Transaction logging Internal AAMC presentation Sept 1999

14. Getting started with CBRS • Initial data load (first year) • Years of work. Initialized using AutoMatch, later CBRS itself. • Well over a million people. Data of mixed quality. • Results: better than using SSN (and fake SSNs), but lots of duplicates. Initial development • Surprisingly easy once we took the plunge • Experience with the data paid off • Remarkably good performance (~10/minute)

15. Basic Design Principles • Goal of universal applicability across systems. • Retain all data about a person rather than the “correct” or most-recent versions (name, SSN, DOB variations). • An AAMC ID is no more sensitive than customer number printed on your LL Bean catalog. • AAMC ID as a 10-digit number that happens to have 8 digits. • “Under-matching” is preferred to “over-matching.” • Substantially less damaging • More likely to be self-reported • Easier to fix

16. Basic Algorithm • Data is submitted (by the person or someone else), standardized and logged. • Find “candidate matches” by looking for people with the same SSN, email address, phone number or similar name. • Additive scoring system (points for name match + points for SSN match etc.) with penalties for conflicts. • Pick the best match assuming it’s a high enough score. • If match found, update that record with new data; if not found initialize a new record. • Log the match results for later review. • Return the AAMC ID.

17. James T. Kirk ID 11203355 Input Data DOB: 12/05/1980 J. T. Kirk DOB: 05/12/1980 SSN: 530-11-3333 Input Data SSN: 530-11-3333 Jtk@ufp.org Jtk@sfc.mil (202) 884-3436 2555 35th St. NYC “Base Person” Input data “Candidates” Step 1: Find similar people using SSN +4 +1 +10 +2 Total: 17 Step 2: Compute score Step 3: If best score < 20 continue

18. James T. Kirk ID 11203355 Input Data DOB: 12/05/1980 Score 17 SSN: 530-11-3333 ID 10357621 Jtk@ufp.org James Marcus Kirk (202) 884-3436 SSN: xxx-xx-5488 MD, Penn 1978 “Base Person” Input data “Candidates” Step 4: Find similar people using e-mail Step 5: If best score < 20 continue None found +1 -6 +0 Total: -5 Step 6: Find similar people using “strict name” Step 7: Compute score Step 8: If best score < 18 continue

19. James T. Kirk ID 11203355 Input Data DOB: 12/05/1980 Score 17 SSN: 530-11-3333 ID 10357621 ID 12003652 Jtk@ufp.org Score -5 Input Data Joan Alice Dove J. Dove-Church (202) 884-3436 Input Data DOB: 01/20/1980 Jchurch@msn.com Jc@med.ucla.edu MD, UCLA 2003 “Base Person” Input data “Candidates” Step 9: Find similar people using “loose name” Step 10: Compute score -6 -5 Total: -11 Step 11: If best score < 8 then return new ID, else return best match

20. James T. Kirk ID 11203355 ID 11203355 Input Data DOB: 12/05/1980 J. T. Kirk James T. Kirk DOB: 05/12/1980 SSN: 530-11-3333 Input Data Input Data DOB: 05/12/1980 DOB: 12/05/1980 SSN: 530-11-3333 Jtk@ufp.org Jtk@sfc.mil SSN: 530-11-3333 (202) 884-3436 2555 35th St. NYC Jtk@sfc.mil Jtk@ufp.org 2555 35th St. NYC (202) 884-3436 “Base Person” Input data Database Record Step 12: Update record in the database Step 13: Log everything

21. CBRS/AAMC ID issues • Mistakes happen and must be identified and corrected. Staffing. • Push versus Pull models of propagating AAMC ID corrections. • How much “internalization” of AAMC IDs should systems do. (For most systems critical to have a guaranteed stable ID and an AAMC ID is not. MCAT example.) • Original algorithm/implementation was quite good but brittle. • New version allows custom match “strategies” for particular contexts. • Now object oriented and designed to be enhanced.

22. CBRS facts and figures • Total AAMC IDs 2,233,254 • Still active AAMC IDs: 2,178,706 • New AAMC IDs in 2004: 103,859 • New 2004 AAMC Ids still active: 101,683 • Consolidations per month: 40 to 400+ • Max. throughput: ~8,000+/hour

23. Building a IdM Foundation … under existing applications Circa 1998 (pre-CBRS). Lots of applications and systems doing their own thing in terms of login, registration, access control and storing person data. Each circle represents an application, database or secured private Web or FTP site.

24. Building a Foundation … under existing applications AAMC IDs Circa 2001. Systems starting to incorporate AAMC IDs, facilitating data interchange. Institutional apps/surveys, private sites, and many other systems not “on board.” Data Warehouse, STARS, AMCAS among early adopters.

25. Building a Foundation … under existing applications “AAMC Login” AAMC IDs Circa 2002. Standardized on a centralized user name/password system, later termed “AAMC Login.” More systems using AAMC IDs. AAMC Login starting to reduce the number of distinct accounts.

26. AAMC Login initial deployment • Components: • Central user name/password storage with AAMC ID and user name as unique keys. • Fairly low-level APIs (implemented as database calls) for authentication, change password, lock and unlock account. • Compliance by mandate. • Developers had to implement much of the functionality on their own. Inconsistencies. • <<100% utilization across systems leading to confusion in user community. • A step in the right direction, however.

27. Institution Apps Pose Problems • What is an “institution app?” • A survey or application that is intended for use by people at our member institutions that has institution-specific aspects. • E.g., a survey of hospital finances, completed by one or more people at each member teaching hospital. • Our “traditional” solution: Institution-level accounts. E.g., a hospital rep would log in with the COTH ID for their hospital and a password we had set. • Problems: • Different accounts for different applications • Unchanged passwords • Weak tracking of respondents/users • Undocumented cross application “accommodations” • Repeated logins as session crosses applications.

28. Gap between goal and action • AAMC executives aware of the problem • A dean logging into the Deans’ private site (all using the same user name/password) faced with links to various products, each requiring a second login often with a different user name/password. • and support moving to personal accounts, but… • Management-level staff not persuaded/induced to make this a priority. “It could be a lot worse.” • Developers not enthusiastic. Daunting scope/trailblazer costs. Reflecting lack of enthusiasm of divisional customers.

29. How to expand the use of AAMC Login? “AAMC Login” AAMC IDs • Achieve organization-wide buy-in • Build on existing membership management system (STARS, in our case) • Solve the critical mass problem • Make it easer for developers to use the new than the old.

30. How we got there • After lots of talk and little progress, we decided to tackle the problem as part of another long-standing goal: developing a one-stop shop for AAMC data products--a “Data Services Portal” • Decided on a joint effort with two development teams • One to create a replacement for an existing (resource gobbling) reporting app for medical school data. (Medical School Profile System) • One to build the sharable components and the infrastructure for the app (the portal itself).

31. MSPS and the Portal • As everyone predicted, the MSPS part of the effort was relatively easy and productive, • Well defined customer and audience • Existing app for baseline and comparison • Tangible product • while the Portal part was mired in ambiguity and worse. • No specific champion or customer • Vague but expansive scope • Turf issues (Web site/Application divide; other PMs) • Lack of shared vision

32. Build the specific while debating the general • While the “big picture” issues about the portal were up in the air, there were lots of specific functions that MSPS needed. • The 2-team approach let the portal developers look to the MSPS team as a customer. • MSPS needed: • AAMC Login implementation • Role-based access control tied to STARS • Registration functions • File upload/download functions • Bulk mail tool • The portal team was responsible for designing and building these for MSPS in a way that would work for a much larger universe of membership applications. • The MSPS team could focus on the business of reporting medical school data.

33. The Result? • A very nice reporting application with “over-engineered” components. • The “data services portal” part of the project ended up having no “data services” aspects and not being a “portal.” • The solution to that awkward realization? • A name change, of course: • Enter the “Shared Login and Membership Management system” AKA SLAM.

34. SLAM features • Single Sign-on * • Role-based access control, tied to STARS ** • Role-based app-implemented privileges *** • Token (“access code”) registration functionality • Staff user admin tools ** • Enables elimination of app-specific user names/passwords * • Change-password, forgot-password, update-info functionality provided to apps *** • Trivially easy implementation (literally one line of code) *** • Logging of usage by person, app and role ** * = end user is primary beneficiary ** = AAMC division staff are primary beneficiaries *** = app developers are primary beneficiaries

35. SLAM provides the login screen

36. SLAM Roles • Institution-specific (“Dean”) or not (“MSPS General User”) • Role-to-role grants (inheritance), arbitrarily deep nesting supported • a “Musketeer” is a “King’s Soldier” is a “French Citizen” is a “European” etc. • Roles can be inherited by STARS relationships. Therefore changes in STARS have immediate effect on user privileges. • Roles can be granted with or without admin rights (the right to “pass it on”) • Roles can be granted with or without expiration date • Directly granted roles versus inherited roles are treated the same (distinction hidden from the apps)

37. SLAM Roles related to apps • What roles exist, how they relate, who has them, what applications they grant access to is stored centrally. • If a new group is granted a particular role the application code and database is untouched. • What privileges each role provide within a particular application is stored locally (in that app). • Thus applications (developers) essentially get sophisticated role-based access control without having to • Reinvent the wheel or • Give up control over fine-grained intra-application business rules.

38. Examples of rules that can be directly implemented in SLAM “Dean” is defined as relationship COD051 (by inst). “MSPS Confidential” is a role that provides login access to MSPS Reports. Each Dean gets MSPS Confidential for their school. Each Dean gets access to the COD private site. Deans also get access to the COTH private site. Deans (and other people) are considered “AAMC constituents.” AAMC constituents get access to a set of private sites and applications. “AAMC staff” is defined as relationship AAMC001. AAMC staff get access to the Data Book and… The Data Book online is available to subscribers.

39. COD051 (inst) A STARS / EIS group/relationship “Dean” is defined as relationship COD051 (by inst). Dean (inst) A SLAM role The (solid) arrow represents inheritance and can be read as “gets”, “has” or “inherits.” The parenthetical “inst” indicates that the role or relationship must be associated with a particular institution when assigned to a person.

40. COD051 (inst) “Dean” is defined as relationship COD051 (by inst). Dean (inst) Another SLAM role MSPS Conf. (inst) “MSPS Confidential” is a role that provides login access to MSPS Reports. MSPS Reports A SLAM application

41. COD051 (inst) “Dean” is defined as relationship COD051 (by inst). Dean (inst) Each Dean gets MSPS Confidential for their school. MSPS Conf. (inst) MSPS Confidential is one of the roles that provides login access to MSPS Reports. MSPS Reports

42. COD051 (inst) Dean (inst) Each Dean gets access to the COD private site. MSPS Conf. (inst) MSPS Reports COD Private Site

43. COD051 (inst) Dean (inst) Deans also get access to the COTH private site. MSPS Conf. (inst) MSPS Reports COD Private Site COTH Private Site

44. COD051 (inst) Dean (inst) Deans (and others) are considered “AAMC constituents”. AAMC Constituent MSPS Conf. (inst) Notice that (at least as envisioned here) the AAMC Constituent role is not linked to an institution. MSPS Reports COD Private Site COTH Private Site

45. COD051 (inst) AAMC constituents get access to a set of private sites and applications. Dean (inst) AAMC Constituent MSPS Conf. (inst) MSPS Reports COD Private Site COTH Private Site GIR Private Site Other App

46. Indicates a particular person, in this case a medical school dean. Indicates assignment of this relationship to a particular person. COD051 (inst) So, as soon as someone is designated a Dean, he or she automatically gets access to a portfolio of private AAMC resources. Dean (inst) AAMC Constituent MSPS Conf. (inst) MSPS Reports COD Private Site COTH Private Site GIR Private Site Other App

47. In other words, these arrows don’t exist. COD051 (inst) There is no direct link between the person and the other (non-Dean) roles or applications. Dean (inst) AAMC Constituent MSPS Conf. (inst) MSPS Reports COD Private Site COTH Private Site GIR Private Site Other App

48. COD051 (inst) There is no direct link between the person and the other (non-Dean) roles or applications. Thus, as soon as a relationship change is recorded (via STARS or Designation) the person’s access rights are instantly and automatically updated. Dean (inst) AAMC Constituent MSPS Conf. (inst) MSPS Reports COD Private Site COTH Private Site GIR Private Site Other App

49. CAS052 (inst) CAS Exec (inst) AAMC Constituent GIR Private Site Other App SLAM has no trouble with “redundant” grants (a person who inherits a role via two or more paths). For example, suppose our dean is also the president of an academic society (and thereby a CAS member and AAMC constituent). COD051 (inst) Losing the Dean relationship won’t affect other independent grants. Dean (inst) AAMC Constituent MSPS Conf. (inst) MSPS Reports COD Private Site COTH Private Site GIR Private Site Other App

50. Another way to get a role Up to this point, we’ve only discussed relationship-based grants. The other way someone gets a role is by a direct grant. A direct grant is represented by a (dotted) arrow connecting a person directly to a SLAM role. We’ve seen that relationship-based grants are automatically granted and revoked as a person’s relationships are updated. On the other hand, direct grants are independent of relationship changes and must be explicitly granted or revoked (or allowed to expire). Direct grants have advantages and disadvantages, but as a general rule relationship-based grants are preferable to direct grants. Some Role