IHERO Detailed User Authentication

Proposed Profile: User Authentication and Authorization

• Proposal Editor: C.Field
• Profile Editor: C.Field
• Domain: Radiation Oncology

Summary

It is difficult for end users to remember the numerous username and passwords that are required to login and access radiotherapy systems and applications. As a result, users may insecurely record usernames and passwords, and/or forget their login information in which case system managers are burdened with resetting the user account.

The IHE-IT Enterprise User Authentication (EUA) profile refers to standards to support the user authentiation challenges. It is unclear whether standards exist to deal with the user authorization issues.

A centralized user authentication and authorization system could maintain all user authentication records (e.g. username/password, fingerprint, iris scan, photo, card access, etc), and could also maintain records of what systems, applications, and rights the user was authorized to access.

IHE-RO is an excellent venue to obtain support from the user community and industry to put a framework in place which would eventually simplify the authenication and authorization problem for the radiotherapy (and potentially other) domains.

The Problem

User Authentication (e.g. username and password) is becoming increasingly difficult to manage both from 1) a user perspective because of the requirement to have multiple usernames and passwords for a variety of systems and applications; and 2) for administrators who must maintain these various systems and applications.
User Authorization is the assignment of privileges allowing the user to perform certain functions (e.g. calculate dose, override an interlock, generate a CT scan). The assigned privileges depend upon the authenticated user and the system or application being accessed. The granularity of these functions is very poorly defined and is not standardized across systems.

Currently all radiotherapy systems and applications maintain their own user accounts and rights. "Single sign on" is an example of simplifying the user authentication process, and SSO is moving in the right direction, but it does not go far enough. A centralized system which maintains the rights and privileges for all uses across all radiotherapy systems (and ideally other systems) would simplify the user authentication and authorization processes.

Users forget the passwords because they have so many of them, which requires that system managers reset their passwords. Some users write there passwords down which pose security threats. Some systems require that passwords be changed every 3 months, and each system has different requirements on the composition of a password. A single authentication and authorization system for radiotherapy systems and applications could enforce strong passwords, and would minimize the problems associated with maintaining multiple authentication and authorization systems, both from the perspective of the end user and system manager.

Key Use Case

How it currently works: A radiation therapist comes in to work and turns on the treatment workstation computer, username1/password1 is required. Another general purpose computer is turned on: username2/password2 is required. A treatment application (e.g. scheduling, charting, …) is started up, username3/password3 is required. The first patient is treated and an interrupt occurs, username4/password4 is required to clear the interlock. The user switches to the general purpose computer to read email: usernname5/password5 is required. During the day, the therapist moves to another treatment unit to cover coffee breaks and must clear another interlock; username6/password6 is required.

How it should work: The radiation therapist arrives at each workstation and either scans their fingerprint, face, iris, or ID card, or provides a username/password and is identified by a user authentication / authorization servers. This system either grants or denies the user the ability to perform specific tasks on requested systems and applications depending upon the authenticated user. Backup (or distributed) authentication / authorization servers are required in case the primary server fails.

Standards & Systems

The IHE-IT Enterprise User Authentication (EUA) profile already in place may provide some standards. All systems and applications inside and outside the Radiation Oncology domain could utilize the user authentication / authorization server.

<List relevant standards, where possible giving current version numbers, level of support by system vendors, and references for obtaining detailed information.>

Technical Approach

Additional ideas may be provided by ID systems such as OpenID for web logins, and PGP and other similar products for encrypting/decrypting data on the authentication and authorization server and while data is being transferred from and to the server.

A phased approach may be useful that first enables user authentication (similar to EUA). Once this was in place, then the authorization component could be added on. The authorization component may also require the development of standards.

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>

Existing actors

All existing and new actors which require authentication or authorization would have to be modified to use this common authentication / authorization server.

New actors

• Get_authentication
• Update_authentication (includes additon and removal of authentication techniques)

• Get_authorization
• Update_authorization (includes addition and removal of rights to various systems)

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

Risks

Access to a authentication/authorization server through firewalls may be a problem.

<List technical or political risks that could impede successfully fielding the profile.>

Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

<If there are no Open Issues at Evaluation Time, it is usually a sign that the proposal analysis and discussion has been incomplete.>

Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA