identity and access management: why it matters aamc’s journey of discovery kirke b. lawton...

Identity and Access Management: Why It Matters

AAMC’s Journey of Discovery

Kirke B. LawtonDirector, 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


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.


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 1998Migrating 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 1998Convert 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 IDObvious 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 CBRSDecided 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()”

The Fundamental CBRS Responsibility is to Match People with AAMC_IDs

CBRS“Black Box”

A person’s name, SSN and/or otherID information

An AAMC_ID

Input Output

Internal AAMC presentation Sept 1999

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

Opening the CBRS Black Box

Internal AAMC presentation Sept 1999

Getting started with CBRSInitial 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 PrinciplesGoal 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 AlgorithmData 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.

“Candidates”

Input Data

James T. KirkJames T. Kirk

DOB: 12/05/1980DOB: 12/05/1980

SSN: 530-11-3333SSN: 530-11-3333

[email protected]@ufp.org

(202) 884-3436(202) 884-3436

“Base Person” Input data

Step 1: Find similar people

using SSN

Step 2: Compute score

Step 3: If best score < 20 continue

+4

+1

+10

+2

Total: 17

Input Data

J. T. KirkJ. T. Kirk

DOB: 05/12/1980DOB: 05/12/1980

SSN: 530-11-3333SSN: 530-11-3333

[email protected]@sfc.mil

2555 35th St. NYC2555 35th St. NYC

ID 11203355ID 11203355

None found

“Candidates”

Input Data


DOB: 12/05/1980DOB: 12/05/1980

SSN: 530-11-3333SSN: 530-11-3333


(202) 884-3436(202) 884-3436


+1

-6

+0

Total: -5

Score 17Score 17

ID 11203355ID 11203355Step 4: Find similar people using e-mail



Step 6: Find similar people using “strict

name”

James Marcus KirkJames Marcus Kirk

SSN: xxx-xx-5488SSN: xxx-xx-5488

MD, Penn 1978MD, Penn 1978

ID 10357621ID 10357621


Input DataScore -5Score -5

ID 10357621ID 10357621

“Candidates”

Input Data


DOB: 12/05/1980DOB: 12/05/1980

SSN: 530-11-3333SSN: 530-11-3333


(202) 884-3436(202) 884-3436


-6

-5

Total: -11

Score 17Score 17

ID 11203355ID 11203355Step 9: Find

similar people using “loose

name”


Step 11: If best score < 8 then return new ID,

else return best match

Input Data

Joan Alice DoveJ. Dove-Church

Joan Alice DoveJ. Dove-Church

DOB: 01/20/1980DOB: 01/20/1980

[email protected]@med.ucla.edu

[email protected]@med.ucla.edu

MD, UCLA 2003MD, UCLA 2003

ID 12003652 ID 12003652

Input Data

J. T. KirkJ. T. Kirk

DOB: 05/12/1980DOB: 05/12/1980

SSN: 530-11-3333SSN: 530-11-3333

[email protected]@sfc.mil


ID 11203355ID 11203355

Database Record

Input Data


DOB: 12/05/1980DOB: 12/05/1980

SSN: 530-11-3333SSN: 530-11-3333


(202) 884-3436(202) 884-3436


Step 12: Update record in the database

Step 13: Log everything

Input Data


DOB: 05/12/1980DOB: 12/05/1980

DOB: 05/12/1980DOB: 12/05/1980

SSN: 530-11-3333SSN: 530-11-3333

[email protected]

[email protected]

[email protected]

[email protected]


ID 11203355ID 11203355

(202) 884-3436(202) 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 figuresTotal 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

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.

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 IDs

“AAMC Login”

AAMC Login initial deploymentComponents:

• 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 ProblemsWhat 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 actionAAMC 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?

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

AAMC IDs

“AAMC Login”

How we got thereAfter 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).

MSPS and the PortalAs 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 generalWhile 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 “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.

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 aTIFF (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 “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)

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)

Dean(inst)


A STARS / EIS group/relationship

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(inst)

MSPS Conf.(inst)

MSPSReports


“MSPS Confidential” is a role that provides login access to MSPS Reports.

Another SLAM role

A SLAM application

COD051(inst)

Dean(inst)

MSPS Conf.(inst)

MSPSReports


MSPS Confidential is one of the roles that provides login access to MSPS Reports.

Each Dean gets MSPS Confidential for their school.

COD051(inst)

Dean(inst)

MSPS Conf.(inst)

MSPSReports

Each Dean gets access to the COD private site.

CODPrivate Site

COD051(inst)

Dean(inst)

MSPS Conf.(inst)

MSPSReports

CODPrivate Site

Deans also get access to the COTH private site.

COTHPrivate Site

COD051(inst)

Dean(inst)

MSPS Conf.(inst)

MSPSReports

CODPrivate Site

Deans (and others) are considered “AAMC constituents”.

COTHPrivate Site

AAMCConstituent

Notice that (at least as envisioned here) the AAMC Constituent role is not linked to an institution.

COD051(inst)

Dean(inst)

MSPS Conf.(inst)

MSPSReports

CODPrivate Site

AAMC constituents get access to a set of private sites and applications.

COTHPrivate Site

AAMCConstituent

GIRPrivate Site

Other App

COD051(inst)

Dean(inst)

MSPS Conf.(inst)

MSPSReports

CODPrivate Site

So, as soon as someone is designated a Dean, he or she automatically gets access to a portfolio of private AAMC resources.

COTHPrivate Site

AAMCConstituent

GIRPrivate Site

Other App

Indicates assignment of this relationship to a particular person.

Indicates a particular person, in this case a medical school dean.

COD051(inst)

Dean(inst)

MSPS Conf.(inst)

MSPSReports

CODPrivate Site

There is no direct link between the person and the other (non-Dean) roles or applications.

COTHPrivate Site

AAMCConstituent

GIRPrivate Site

Other App

In other words, these arrows don’t exist.

COD051(inst)

Dean(inst)

MSPS Conf.(inst)

MSPSReports

CODPrivate Site

There is no direct link between the person and the other (non-Dean) roles or applications.

COTHPrivate Site

AAMCConstituent

GIRPrivate Site

Other App

Thus, as soon as a relationship change is recorded (via STARS or Designation) the person’s access rights are instantly and automatically updated.

COD051(inst)

Dean(inst)

MSPS Conf.(inst)

MSPSReports

CODPrivate Site

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

COTHPrivate Site

GIRPrivate Site

Other App

AAMCConstituent

AAMCConstituent

CAS052(inst)

CAS Exec(inst)

GIRPrivate Site

Other App

Losing the Dean relationship won’t affect other independent grants.

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

More about direct grantsA 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).

We’ll come back to the topic of Access Codes later.

Some Role

AAMCConstituent

CAS052(inst)

CAS Exec(inst)

GIRPrivate Site

Other App

Back to our example of an Academic Society President who used to be a Dean.

MSPSReports

MSPSGeneral

For completeness, let’s add the rule that CAS folks get general, non-institution-specific access to MSPS Reports.

AAMCConstituent

CAS052(inst)

CAS Exec(inst)

GIRPrivate Site

Other App

Back to our example of an Academic Society President who used to be a Dean.

MSPSReports

MSPSGeneral

MSPS Conf.(inst)

As currently implemented, former deans don’t inherit any SLAM roles. But one could imagine the new Dean giving the Dean Emeritus access to school data under some circumstances. So let’s show this as a direct grant of MSPS Conf.

What we’ve 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 it’s based on a few simple concepts.

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.

A Dean

Dean(inst)

COD051(inst)

MSPS Conf.(inst)

MSPSReports

COD PrivateCOTHPrivate

GIR Private Data BookOther App

AAMCConstituent

AAMC Staff

Data Booksubscriber

Dept. Chair(inst)

HospitalCEO (inst)

AAMC001CHAIR_ANAT

(inst)CHAIR_DENT

(inst)CTH051 CTH051 CTH051

ACOTHCEO

A ChairStaff

member

Inst: 101 Inst: 10325Inst: 101

Inst: 101

Registration and Access CodesMany “users” have the right to access some SLAM apps (thanks to their STARS relationships), but don’t 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 CodesBut we also need to provide access to yet-to-be-identified 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 MassA 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 long-standing 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 OverviewSLAM 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 application’s database


Advantages and DisadvantagesThe 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.


Advantages and DisadvantagesThe 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 didn’t 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.


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.


Characteristics of EIS AuthEIS 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 person’s 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 person’s 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.


Which brings us to SLAMStands 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).


Essentially invisible to end users

SLAM, like EIS Auth, is a name only used internally. It’s 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).


Central User Role/Privilege ManagementAt 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.


Standardized Access Code-BaseRegistration 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.


Example: Targeted Access CodeWhen 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 don’t need the Access Code any more.


SLAM short cut registration


MSPS main page


SLAM Login Page for MSPS


Example: Untargeted Access CodeTo 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.


SLAM login page for Designation


Enter Access Code


Registering with an untargeted code


Finishing Untargeted registration


Main Designation page


Single Sign-on across SLAM applicationsSLAM 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 application-centric user experience.


Help Desk Application for Staff UseAs 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.


Current SLAM ApplicationsMSPS.

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


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.


Implications and Next StepsNow 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 we’ll 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.



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.

AAMC IDs

“AAMC Login” “AAMC Login”

SLAMSLAM

SLAM Log statsSLAM Sessions/Users

0

500

1000

1500

2000

2500

Jun-03Jul-03Aug-03Sep-03Oct-03Nov-03Dec-03Jan-04Feb-04Mar-04Apr-04May-04Jun-04Jul-04Aug-04Sep-04Oct-04Nov-04Dec-04Jan-05

Unique Users

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

Sessions

Users Sessions

2004 Totals: 5,233 Users 85,669 Sessions

AAMC Login Log statsAAMC Login Sessions/Users

0

10000

20000

30000

40000

50000

60000

Jan-04Feb-04Mar-04Apr-04May-04Jun-04Jul-04Aug-04Sep-04Oct-04Nov-04Dec-04Jan-05

Unique Users

0

100000

200000

300000

400000

500000

600000

Sessions

Users Sessions

2004 Totals: 115,805 Users 2,186,802 Sessions

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

identity and access management: why it matters aamc’s journey of discovery kirke b. lawton...

Documents