Identity and Access Management: Why It Matters AAMCs Journey of Discovery Kirke B. Lawton Director, Enterprise Data February 9, 2005 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.
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. 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 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. 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. 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. 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. 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 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. Enter CBRS Decided to spin off a stand-alone system for just doing AAMC IDs.
Common Biographical Record System (CBRS). An Oracle database with its 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() The Fundamental CBRS Responsibility is to Match People with AAMC_IDs Input A persons name, SSN and/or other ID information Output
CBRS Black Box Internal AAMC presentation Sept 1999 An AAMC_ID 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
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) 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 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 its 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.
(202) (202)884-3436 884-3436 Step 1: Find similar people using SSN Step 2: Compute score Step 3: If best score < 20 continue ID ID11203355 11203355 J.J.T. T.Kirk Kirk
2555 255535th 35thSt. St.NYC NYC Total: 17 Candidates Base Person Input data James JamesT. T.Kirk Kirk Input Data DOB:
12/05/1980 DOB: 12/05/1980 SSN: SSN:530-11-3333 530-11-3333 [email protected] [email protected] (202) (202)884-3436 884-3436 Step 4: Find similar people using e-mail Step 5: If best score < 20 continue Step 6: Find similar people
using strict name Step 7: Compute score Step 8: If best score < 18 continue ID ID11203355 11203355 Score Score17 17 ID None found ID10357621 10357621
James JamesMarcus MarcusKirk Kirk +1 SSN: SSN:xxx-xx-5488 xxx-xx-5488 -6 MD, MD,Penn Penn1978 1978 +0
Total: -5 Candidates Base Person Input data James JamesT. T.Kirk Kirk Input Data DOB: 12/05/1980 DOB: 12/05/1980 SSN: SSN:530-11-3333 530-11-3333
[email protected] [email protected] (202) (202)884-3436 884-3436 Step 9: Find similar people using loose name Step 10: Compute score Step 11: If best score < 8 then return new ID, else return best match ID ID11203355
11203355 ID Score 17 ID10357621 10357621 Score 17 Score -5 Input ScoreData -5 ID ID12003652 12003652 Joan JoanAlice AliceDove
2003 Total: -11 Database Record Base Person Input data James JamesT. T.Kirk Kirk Input Data DOB: 12/05/1980 DOB: 12/05/1980 SSN:
J.J.T. T. James T.Kirk Kirk T.Kirk Kirk DOB: 05/12/1980 Input Data DOB: 05/12/1980 DOB: 05/12/1980 DOB: 05/12/1980 DOB: 12/05/1980 DOB:
12/05/1980 SSN: 530-11-3333 SSN: 530-11-3333 SSN: 530-11-3333 [email protected] SSN: 530-11-3333 [email protected] 2555 [email protected] 35th 2555 35thSt. St.NYC NYC [email protected] [email protected] [email protected]
2555 255535th 35thSt. St.NYC NYC (202) (202)884-3436 884-3436 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. 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 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. 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. 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. 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. 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.
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. 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. How we got there After lots of talk and little progress, we decided to tackle the problem as part of another longstanding 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). 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 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. The Result? A very nice reporting application with overengineered 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. 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 SLAM provides the login screen QuickTime and a TIFF (LZW) decompressor are needed to see this picture.
SLAM Roles Institution-specific (Dean) or not (MSPS General User) Role-to-role grants (inheritance), arbitrarily deep nesting supported a Musketeer is a Kings 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) 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. 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. 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. 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 COD051 (inst) Dean is defined as relationship COD051 (by inst). Dean (inst) Each Dean gets MSPS Confidential for their school. MSPS Conf. (inst)
MSPS Reports MSPS Confidential is one of the roles that provides login access to MSPS Reports. COD051 (inst) Dean (inst) Each Dean gets access to the COD private site. MSPS Conf. (inst) MSPS Reports COD
Private Site COD051 (inst) Dean (inst) Deans also get access to the COTH private site. MSPS Conf. (inst) MSPS Reports COD Private Site COTH Private Site
COD051 (inst) Dean (inst) Deans (and others) are considered AAMC constituents. AAMC Constituent MSPS Conf. (inst) MSPS Reports COD Private Site
COTH Private Site Notice that (at least as envisioned here) the AAMC Constituent role is not linked to an institution. 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 Indicates a particular person, in this case a medical school dean.
Indicates assignment of this relationship to a particular person. COD051 (inst) Dean (inst) So, as soon as someone is designated a Dean, he or she automatically gets access to a portfolio of private AAMC resources. AAMC Constituent MSPS Conf. (inst) MSPS
Reports COD Private Site COTH Private Site GIR Private Site Other App COD051 (inst) There is no direct link between the person and the other (non-Dean) roles or applications. In other words, these arrows dont exist.
Dean (inst) AAMC Constituent MSPS Conf. (inst) MSPS Reports COD Private Site COTH Private Site GIR Private Site
Other App COD051 (inst) Dean (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 persons access rights are instantly and automatically updated. AAMC Constituent MSPS Conf. (inst)
MSPS Reports COD Private Site COTH Private Site 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 wont affect other independent grants. CAS052 (inst) CAS Exec (inst) Dean (inst) AAMC Constituent MSPS Conf. (inst)
MSPS Reports COD Private Site COTH Private Site GIR Private Site Other App Another way to get a role Up to this point, weve 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.
Weve seen that relationship-based grants are automatically granted and revoked as a persons relationships are updated. On the other hand, direct grants are independent of relationship changes and must be explicitly granted or revoked (or allowed to Some Role expire). Direct grants have advantages and disadvantages, but as a general rule relationship-based grants are preferable to direct grants. More about direct grants A direct grant is executed one of two ways: 1. A person uses an Access Code that gives them the role. 2. Someone (AAMC staff) uses UnlockPlus to grant a role to a person. A directly granted role is revoked when 1. It expires, or 2. Is explicitly revoked (by AAMC staff or an institution admin user).
Well come back to the topic of Access Codes later. Some Role Back to our example of an Academic Society President who used to be a Dean. CAS052 (inst) For completeness, lets add the rule that CAS folks get general, noninstitution-specific access to MSPS Reports. CAS Exec (inst) MSPS General
MSPS Reports AAMC Constituent GIR Private Site Other App Back to our example of an Academic Society President who used to be a Dean. CAS052 (inst) As currently implemented, former deans dont inherit any SLAM roles. But one could imagine the new Dean giving the
Dean Emeritus access to school data under some circumstances. So lets show this as a direct grant of MSPS Conf. CAS Exec (inst) MSPS Conf. (inst) MSPS Reports MSPS General AAMC Constituent GIR Private Site
Other App What weve learned SLAM implements role-based access controls through a collection of simple statements/definitions: What roles are exist For each role or relationship, what roles are directly inherited For each application/resource, what roles allow access SLAM is designed to take advantage of indirect grants, allowing us to hand out high-level roles that provide a broad array of access rights. The system works best when roles can be linked to a person through an AAMC relationship, but direct grants are also supported. It can get complicated. But really its based on a few simple concepts. A Dean
A COTH CEO Inst: 101 Inst: 10325 Inst: 101 Staff member A Chair Inst: 101 COD051 (inst) CTH051
Dean (inst) CTH051 CTH051 Hospital CEO (inst) CHAIR_DENT (inst) Dept. Chair (inst) AAMC001 AAMC Staff
AAMC Constituent MSPS Conf. (inst) MSPS Reports CHAIR_ANAT (inst) Data Book subscriber COD Private COTH Private
GIR Private Other App Data Book Remember, each dotted line represents the direct grant of a role (or relationship) to a person. In this example, the University of Alabama (inst 101) Chair of Anatomy has been granted MSPS Confidential for his school (perhaps by the Dean) and has paid for a Data Book subscription. Registration and Access Codes Many users have the right to access some SLAM apps (thanks to their STARS relationships), but dont have AAMC Login accounts. These people just need a targeted access code to get started. Essentially the access code says, The bearer of this access code is John Doe and should be allowed to create a personal account.
In practice, we send them a custom e-mail with a click-here-to-register link. Registration and Access Codes But we also need to provide access to yet-to-beidentified people. Non-targeted or general access codes are used for this. Essentially, The bearer of this access code is entitled to the role X for institution Y [with admin rights] [until date Z|for Z days]. Let him register and create a personal account. General access codes are either one-time use or multiple use and include an expiration date. Achieving Critical Mass A year after the roll-out of MSPS as the first SLAM app (in Spring 2003), there were a few SLAM apps, but not many. Consequently some member groups had accounts (and few benefits) but most did not. Almost every member group had an AAMC private Web
site. By SLAMming the private sites, we could solve a longstanding problem and get all our members registered. Just one technical solution needed. What could be easier? 10+ months later, after many meetings, presentations and debates, after mailing and e-mailing thousands of constituents, it was done in time. Presentation Overview SLAM as the latest technique for improving login and registration for AAMC Web applications. Part 1: Timeline A look back at ancient history The dawn of EIS Auth From the Data Services Portal project comes SLAM Part 2: What is SLAM? Part 3: Implications and next steps. Questions and Answers November 2003 Presentation to AAMC Management Staff
In the beginning (circa. 2001) Lots of secured Web applications Service applications (AMCAS 2002, MCAT ASR, FAP, MyERAS, NRMP, etc.) Surveys and reports and other institutional apps (GQ, MSQ, OpFin, Development Survey, FSS, GIR, CurrMIT, etc.) Lots of independent sets of usernames/passwords Person-specific usernames and passwords (some linked to aamc_ids) for service applications. Institution-specific usernames and passwords for most other applications. Usernames and passwords (and access rights) stored in each applications database November 2003 Presentation to AAMC Management Staff Advantages and Disadvantages The good: Fairly easy to support. If a person forgets their password, staff can look it up and tell them. Need to test the application? Look up a username and password and login. Few (if any) cross-application dependencies. Easy to develop and roll out new applications
since no coordination required. November 2003 Presentation to AAMC Management Staff Advantages and Disadvantages The bad: Inconsistent security across applications. Passwords stored in numerous locations and usually viewable by staff. Institution users forced to remember (or at least use) one or more sets of usernames/passwords that they didnt select. Institution usernames/passwords left unchanged for years to mitigate the previous point. No visibility or control over who at the institutions are using these usernames/passwords. User privileges are set on an application-by-application basis and therefore likely to be inconsistent. November 2003 Presentation to AAMC Management Staff
Gradual centralization/standardization The reengineering of GME Track led to the development of a new username and password system known internally as EIS Auth. [now termed AAMC login] EIS Auth is the centralized system for creating, storing and managing person-specific usernames and passwords. Over the past 18 months all the major service applications have migrated to using EIS Auth for usernames and passwords. AMCAS 2004, MCAT THx, FAP, NRMP, MyERAS, GME Track, STARS, etc. November 2003 Presentation to AAMC Management Staff Characteristics of EIS Auth EIS Auth is a service of EIS and resides in the EIS database If the EIS database is down, EIS Auth is unavailable, preventing login and registration for affected applications.
but is logically distinct from the main EIS database schema. There are 142,000 people in EIS Auth and 1.3 million people in the main EIS person table. An EIS Auth username is essentially a user-selected synonym for that persons aamc_id. E.g. klawton maps to 11000000. Passwords are encrypted in the database. Help desk staff reset passwords rather than looking them up. Applications develop registration processes to meet their needs, but store usernames and passwords in EIS Auth. A persons username and password works across applications, but EIS Auth is not a central repository of rights and privileges. EIS Auth does not apply to applications with institution-specific usernames. November 2003 Presentation to AAMC Management Staff Which brings us to SLAM Stands for Shared Login and Membership Management First implemented for the Medical School Profile System (MSPS) Benchmarking project which went live this summer. SLAM builds on
EIS Auth as a way to transition from institution-specific usernames/ passwords to person-specific accounts. Key Features/Characteristics: Essentially invisible to end users Central user role/privilege management Standardized Access Code-based registration process Single Sign-on across SLAM applications Help desk application for staff use Not designed for applications that are open to anyone who wants to register (such as AMCAS). November 2003 Presentation to AAMC Management Staff Essentially invisible to end users SLAM, like EIS Auth, is a name only used internally. Its not a brand name. Users interact with SLAM when they register for the first time, when they login, or when they review or add privileges to their account, but as far as they are concerned they are just interacting with the supported application (e.g., MSPS
Benchmarking). November 2003 Presentation to AAMC Management Staff Central User Role/Privilege Management At Login to a SLAM application: SLAM uses EIS Auth to convert a username/password to an aamc_id. Then determines if the user has a role or privilege authorizing them to use that application. Sources of roles and privileges: Inherited from a STARS relationship or SLAM role. Granted to an individual directly by an AAMC staff member or an institutional admin user. Tools for reviewing and managing roles: Manage Users tab for external users. UnlockPlus for AAMC staff. November 2003 Presentation to AAMC Management Staff Standardized Access Code-Base
Registration Process Access Codes serve two purposes: To allow someone to register to get a username/password To (optionally) grant them a specific role or privilege. There are targeted and untargeted Access Codes: Targeted Access Codes are directed to a specific person/aamc_id who is already in STARS, such as a dean. These provide a short cut for registration. Untargeted Access Codes are usable by any recipient to register and receive the corresponding role or privilege. Access Codes can be generated individually as needed or en masse for AAMC groups. November 2003 Presentation to AAMC Management Staff Example: Targeted Access Code When MSPS Benchmarking went live an email was sent to all the medical school deans inviting them to register and try it out. Each was given a unique Access Code.
By clicking on the link in the email they were taken to a page that said essentially Welcome [name here], please select a username and password. After doing so they were entered into the MSPS application. The next time they want to use the application, they use that username/password to get in. They dont need the Access Code any more. November 2003 Presentation to AAMC Management Staff SLAM short cut registration November 2003 Presentation to AAMC Management Staff MSPS main page November 2003 Presentation to AAMC Management Staff SLAM Login Page for MSPS
November 2003 Presentation to AAMC Management Staff Example: Untargeted Access Code To roll out the new Group Designation application, a letter is going to each of the medical school deans and hospital CEOs providing an Access Code for them to hand off to the appropriate person or persons. To use the Access Code, the recipient goes to the Group Designation start page and clicks on the Register link where they type in the Access Code. The user is then asked to fill in a short registration page so that we can assign them (or match them to) an aamc_id. Then the user is asked to select a username and password. They are emailed a confirmation and logged into the application. The next time they want to use the application, they use that username/password to get in. November 2003 Presentation to AAMC Management Staff SLAM login page for Designation
November 2003 Presentation to AAMC Management Staff Enter Access Code November 2003 Presentation to AAMC Management Staff Registering with an untargeted code November 2003 Presentation to AAMC Management Staff Finishing Untargeted registration November 2003 Presentation to AAMC Management Staff Main Designation page November 2003 Presentation to AAMC Management Staff Single Sign-on across SLAM applications SLAM allows users to move from one application
to another without logging in a second or third time. Will become relevant to external users when more applications are using SLAM. Allows for a more seamless, less applicationcentric user experience. November 2003 Presentation to AAMC Management Staff Help Desk Application for Staff Use As for any EIS Auth-based application, if a user forgets his or her password, can get a new one if they remember all of the following: Username Email address Response to security question Or they can call or email and have someone do it for them. UnlockPlus is the application that supports this for SLAM applications. It also allows authorized staff to Review user roles/privileges Create Access Codes UnlockPlus works in conjunction with application-specific admin/help
desk software. November 2003 Presentation to AAMC Management Staff Current SLAM Applications MSPS. Audience: Medical school deans, principal business officers, and their designees. Other groups coming soon. Compliance Officers Forum. Audience: Compliance officers at medical schools and COTH hospitals. Adviser Information Service. Audience: Undergraduate Chief Health Professions Advisors Group Designation. Audiences: Deans/CEOs and their designees. UnlockPlus Audience: Selected AAMC staff.
November 2003 Presentation to AAMC Management Staff Who supports these applications? An evolving support model. The applications themselves are supported by different groups associated with each application. Going to start having STARS Central support the general login and registration questions across applications. November 2003 Presentation to AAMC Management Staff Implications and Next Steps Now have the means to transition all applications to person-specific usernames/passwords (EIS Auth) Member applications (applications with audiences related to STARS relationships/groups) should use SLAM if feasible. Other applications can use EIS Auth directly. In either case a person only has one username and password.
Currently SLAM applications are the exception, but as that changes well need to make sure our members understand the implications. Between the Group Designation application and the distributed admin features of SLAM, institutional super users will have more visibility and control over who has access to their AAMC data and services. November 2003 Presentation to AAMC Management Staff Building a Foundation under existing applications SLAM AAMC Login SLAM AAMC Login AAMC IDs Circa 2004. SLAM reaches a critical mass
with the conversion of the private Web sites and AAMC and OIR buy-in. 60+ SLAM apps. Momentum for the conversion of institution apps to personal logins finally achieved. New SLAM apps every few weeks. Hundreds of old accounts retired. SLAM Log stats SLAM Sessions/Users Users 2500 Sessions 2000 1500 1000 Unique Users 500
0 20000 18000 16000 14000 12000 10000 8000 6000 4000 2000 0 Jul-03 Jul-04 Oct-03 Apr-04 Oct-04 Jun-03
Jan-04 Jun-04 Jan-05 Feb-04 Mar-04 Aug-03 Sep-03 Nov-03 Dec-03 Aug-04 Sep-04 Nov-04 Dec-04 May-04 2004 Totals: 5,233 Users 85,669 Sessions Session
AAMC Login Log stats AAMC Login Sessions/Users Users 60000 Sessions 600000 50000 500000 40000 400000 30000
300000 20000 Users Unique 10000 200000 100000 0 0 Jul-04 Apr-04 Oct-04 Jan-04 Jun-04 Jan-05 Feb-04
Mar-04 Aug-04 Sep-04 Nov-04 Dec-04 May-04 2004 Totals: 115,805 Users 2,186,802 Sessions Session AAMC Login accounts # of accounts (as of 11:00am): 226,652 # of accounts created since Private Site tipping point (Aug 1): 29,919 Caveat: The vast majority of these accounts are student/applicant-type people rather than faculty, doctors. On-going challenges:
Data management Technologies Eating our own dog food Biometrics? Expansion beyond our locally hosted apps? Black-list negative roles Improved distributed admin tools