User Link Theory of Operation
A user can securely access any User-Link-enabled application on a clinical desktop using a single sign-on authentication with User links. User links are an example of secure links. User links enable institutions to designate applications as trusted for user authentication and implement multiple methods of authentication (e.g. passwords, biometrics, etc).
The context identity subjects defined for User-Link-enabled applications are User subjects. User subjects are secure subjects designated with authenticated data sets. The context data identifier item for the User subject is the user’s sign-on name to an application. Because a user’s sign-on name is unlikely to be universally unique, different applications in a context system may identify a single user with different User subject identifier items. Therefore, application-specific suffixes differentiate each item. The User subject is not dependent on any other subject.
In addition to identifier items, the User subject may contain corroborating data items. The Health Level-Seven Standard Context Management Specification, Data Definition: User Subject document defines the actual names, meaning, and data types used to represent these context data items.
The data used to authenticate a user is not included in the user context data and each application is expected sign on a user given just the application-specific logon name for the user. Before tuning to the user context, an application needs to verify the authenticity of the context data. The chain of trust verifies the authenticity of this data. For more information about establishing a chain of trust, see Establishing a Chain of Trust
A common context system that supports User Links includes:
- context participant applications
- a context manager
- user mapping agents (optional)
- authentication repositories (optional)
When an application sets the user context, the context manager instructs an optional user-mapping agent, to map the application specific logon names for additional logon names known to the agent. The mapping agent uses the application suffix for each of the mapped items to inform the application that the mapped logon name is valid.
Any User-Link-enabled application can be can be configured to sign on to a context session on a clinical desktop. The implementation specific configuration of a context manager designates specific applications to perform the log on task. In this situation, the context manager allows only the designated applications to complete context change transactions that change the user subject. The one exception to this rule is that any User-Link-enabled application is allowed to set the user subject to empty to facilitate a user’s log-off from all User linked application from any User-Link-enabled application. As a result, any User-Link-enabled applications not designated to authenticate users on a particular device should not allow the user to sign on to the application or set the User subject. To sign on to a linked but non-designated application the user must log on to a designated application first. To log on to a non-designated application, a user has to break the link with the common context.
The CCOW Context Management Architecture standard provides means for an application to determine in runtime whether it has been designated for authenticating users. Additionally, User-Link-enabled application can co-exist with participant applications that are not User-Link-enabled. In such a case, the user will need to specifically log-on and log-off from each non-User-Link-enabled application.