Key Concepts for Orbital Lite STS

From
Revision as of 08:23, 15 January 2020 by 99.244.72.184 (talk) (Created page with " There are a few logical items that the administrator or Service Provider should understand prior to modifying or reviewing the configuration of Orbital Lite STS. While many...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

There are a few logical items that the administrator or Service Provider should understand prior to modifying or reviewing the configuration of Orbital Lite STS.

While many examples focus on healthcare settingsdue its origins, STS has been deployed in non-clinical legacy systems. The terminology such as EHR/HIS/EMR, clinical or “clinicians” should not be taken as prescriptive and merely reflects the primary client profile of Radius Works.

 


 

 

UserContextMode

There are currently five modes of operation as of version 1.93. These modes allow the STS to establish the trust with the originating system (an EMR, EHR a HIS). The concept is that the STS needs to confirm that the request is coming from a trusted system or processed on behalf of an authorized user (typically a clinician or other staff member).

Find out more here about UserContextModes.

 

 

UserContext

UserContext is the key attribute that establishes the security context between the source (clinical) system and the STS. It’s typically the username by which the user logged into the source system or by which the workstation (also RDP or Citrix session) has authenticated the user.

Group membership lookups are driven by the UserContext attribute so it’s important that the user identity being retrieved from Active Directory, LDAP or a database matches this value.

 

 

NameQualifier

 

The NameQualifier is very much a SAML term that is used by STS to define sets of users that will be processed in the same manner.

Typically NameQualifiers align with (AD) domains in the organization. In the SAML sense a NameQualifiers allows an organization to ensure that the identity attributes can be used to uniquely identify a users (<NameQualifier>+<NameID>). Specifically this refer to the situation where an organization has two domains and may not be able to enforce uniqueness in usernames (e.g. samAccountName). For example you have two users called jsmith; one in the “corporate” domains and one in the “research” domain. In Windows/NetBIOS terms this would be “corporate/jsmith” and “research/jsmith”.

STS uses the NameQualifier to determine how to process the user identity information. It may go to Active Directory to obtain additional user attributes for “corporate/jsmith” and may go to a MSSQL data to retrieve information about “research/jsmith”.

 

 

Service

 

Since version v1.7, the STS supports multiple Service Provider profiles. One instance of STS can be used to integrate with different external Service Providers simplifying maintenance. This can be an attribute that the source system can submit to the STS, providing flexibility and reducing complexity for integrating vendors.