Difference between revisions of "UserContextModes"

From
Jump to: navigation, search
 
Line 12: Line 12:
 
#UserContextMode 1 - SHA-256 hash with User-Specific Secret Key  
 
#UserContextMode 1 - SHA-256 hash with User-Specific Secret Key  
 
#UserContextMode 2 - SHA-256 hash with System-Specific Secret Key  
 
#UserContextMode 2 - SHA-256 hash with System-Specific Secret Key  
#UserContextMode 3 - User-Specific '''''Plaintext'''''Key  
+
#UserContextMode 3 - User-Specific '''''Plaintext''''' Key  
 
#UserContextMode 4 - User Windows Credentials  
 
#UserContextMode 4 - User Windows Credentials  
 
#UserContextMode 5 - Client Certificates  
 
#UserContextMode 5 - Client Certificates  

Latest revision as of 08:50, 15 January 2020

In order to provide a certain level of security in order to assert the identity of a user between the HIS
and the receiving STS, there are certain requirements that need to be fulfilled.

In a standard SAML 2.0 token exchange, the confidence (or “trust”) level is provided by the use of
digital certificates in order to encrypt and/or sign the message so that the information cannot be
easily disseminated or intercepted.

All user context exchanges should be conducted via a HTTP-POST to a specific processing web form
(or service) on the STS. To ensure the security of the transmission, this communication should
always occur over HTTPS.

 

The STS supports 5 context modes:

  1. UserContextMode 1 - SHA-256 hash with User-Specific Secret Key
  2. UserContextMode 2 - SHA-256 hash with System-Specific Secret Key
  3. UserContextMode 3 - User-Specific Plaintext Key
  4. UserContextMode 4 - User Windows Credentials
  5. UserContextMode 5 - Client Certificates

 

v1.95 has two additional modes planned for implementation; ADFS and SSO tokens.

What is the right UserContextMode for my STS integration?

Our experience is that most organizations are split between UserContextMode 2 and 4.

If the HIS/EMR/EHR or legacy application vendor has the ability to generate cryptographic hashes, the UserContextMode 2 is recommended as it makes the integration effort a lot simpler.

For environments where the Windows credentials are available (workstation, RDP/Citrix session, or a SSO client), then UserContextMode 4 is used.

[[File:]]

 

UserContextMode 1 - SHA-256 hash with User-Specific Secret Key

 

In this mode the source system provides six attributes

  • NameID – source system username
  • NameQualifier - optional
  • UserContextTimeDate - in “YYYY-MM-DD hh-mm-ss” format
  • UserContextID - also set to the source system username
  • UserContextMode - set to “1”
  • UserContextHash - generated using a user-specific secret key

 

UserContextMode 2 - SHA-256 hash with System-Specific Secret Key

 

The system-specific key is set in the STS web.config.

 

In this mode the source system provides six attributes

  • NameID – source system username
  • NameQualifier - optional
  • UserContextTimeDate - in “YYYY-MM-DD hh-mm-ss” format
  • UserContextID - also set to the source system username
  • UserContextMode - set to “1”
  • UserContextHash - generated using a system-specific secret key

 

UserContextMode 3 - User-Specific PlaintextKey

  • NameID – source system username
  • NameQualifier - optional
  • UserContextTimeDate - in “YYYY-MM-DD hh-mm-ss” format
  • UserContextID - also set to the source system username
  • UserContextPassword - user specific password that will allow STS to validate the user
  • UserContextWorkstation -

 

UserContextMode 4 - User Windows Credentials

Additional user and security context will be obtained from the Windows credentials

  • NameID – source system username
  • NameQualifier - optional
  • UserContextID - also set to the source system username

 

UserContextMode 5 - Client Certificates

Additional user and security context will be obtained from the client certificate

  • NameID – source system username
  • NameQualifier - optional
  • UserContextID - also set to the source system username