Inbound Single Sign On (SSO)

Last update:
Aug 21, 2026
Aikyam Client Application (Portals) can have different types of SSOs (Single Sign-On).
  • Web SSO: SSO among Portals. Portal A → Portal B without authentication. See the linked section.
  • Inbound SSO: SSO from the external vendor (with non-HSID authentication / identity) into Portal. This section explains this “Inbound SSO” implementation.
  • Outbound SSO: SSO from Portal to the external vendor. For this case, Portal is responsible for collecting user attributes that the external vendor needs to identify their user, and Portal sends the attributes to Optum PingFederate, Optum PingFederate generates SAML and send it to the external vendor. This implementation does not require HSID itself directly, therefore out of scope for this implementation document.
    For Inbound SSO, currently these three flows can be used.
  • 2-hop SSO: External Vendor’s user attributes are passed to Portal first, then Portal refines the user attributes and/or uses 2-key method to get user attributes, that can be used by EiMP golden record matching (called BigN, firstname, lastname, date of birth, and unique identifier e.g. member ID, SSN, subscriber ID, etc). User attributes are passed around by either using opentoken (encrypted), or, PingFederate Agentless Adapter.
  • 1-hop SSO: External Vendor’s user attributes are directly passed to HSID Inbound SSO through PingFederate. For this flow, External Vendor is required to pass complete BigN required for EiMP golden record matching.
  • 2-key SSO: 2-key SSO is a special setup of 2-hop SSO (see above). This setup is useful when Portal does not have a way to self-resolve BigN collection after the first hop to Portal. If partial BigN is provided to HSID Inbound SSO, HSID asks a missing part of BigN to the user, complete SSO process, then Portal creates a mapping between External Vendor provided identifiers (2-key, vendor’s unique user identifier + SITE_URL) and EiMP-identification requiring BigN.
    Where to store this 2-key – BigN mapping is up to Portal owner. For example, UHC group currently (May 2025) uses OBAPI as a storage.
In “HSID Inbound SSO” processing above, if the incoming user already has an HSID account associated with the identified EiMP golden record, the user is authenticated and redirected to Portal (happy path). However, if they do not have an associated HSID account, HSID will create an account for this user at the time of first-time inbound SSO. This is called SSO Registration.
SSO Registration requires user interactions, similar to the regular HSID account registration. It has less user interactions compared to the regular registration, as BigN are provided to HSID already).
  • Email setup and possession verification (with one time password delivered to the email).
  • Phone number setup and possession verification (with one time password delivered to the phone, either SMS or call method).
  • Password setup for the direct HSID login.
For a new SSO integration, please reach out to OCIS team to complete Inbound SSO onboarding process first.

On this page

Powered by Aikyam @2025 All rights reserved