2-hop/2-key: Portal – PingFederate interaction

Last update:
Aug 21, 2026
Portal needs to initiate either
  • GET request: Agentless integration for user attribute sharing (recommended for new integration)
  • POST request: Opentoken agent integration for user attribute sharing (only for migration from HSID legacy purposes)
    to PingFederate, passing along below information.
    Some part of changes has been done in this step will be propagated into the subsequent steps in 2-hop SSO flow. For the details, see each change item below.

Agentless integration example – Recommended, especially for new integration, this method needs to be used

  • Query Parameters (all values should be query-parameter-value encoded)
    • PARTNER
      • Non-prod: uhg.stage.hsidportalsref.sp.hsid
      • Prod: uhg.prod.hsidportalsref.sp.hsid
      • For portals migrating from Legacy HSID, PARTNER parameter value would be different.
    • TARGET
      • This is a URL of HSID Inbound SSO. Please see the next section “PingFederate – HSID Interaction”.
      • For portals migrating from Legacy HSID, TARGET parameter value would be different.
        Note: URLs are double-nested query-parameter-value encoded in this flow.
        • TARGET parameter has a URL (Aikyam HSID domain) as its value.
        • This Aikyam HSID domain URL (see in 2-hop/2-key: PingFederate – HSID Interaction section) has a parameter, “redirect_uri”, and it has another URL (Portal domain) as its value.
        • This Portal domain URL (see in “HSID – Portal Interaction” section) should
          • Start HSID OIDC automatically
          • Take the inbound SSO user to the desired location (by utilizing deeplink parameter, etc) o Carry 2-key information (if needed)
        • For every step when a URL is provided to the query parameter as its value, the entire URL should be query-string-value encoded.
          Note: for 2-key SSO: If Portal utilizes 2-key SSO explained above, Portals needs to do either:
          • encrypted value or reference ID of 2-key needs to be passed to URL parameter “redirect_uri” specified for TARGET query parameter (for the details, please see PingFederate – HSID Interaction section below).
          • encrypted value or reference ID of 2-key needs to be set as Portal domain’s cookie, before PingFederate POST call above. These methods allow Portals to carry 2-key information as “pass-through” manner without involving PingFederate or HSID Inbound SSO logic.
        • pfidpadapterid
          • This is a unique PingFederate IdP Adapter identifier per portal, which would be provided by PingFederate team. This PingFederate IdP Adapter would be associated with attribute drop off’s request headers: Basic Authorization’s username:password and Ping.instanceid header (see this document for the details).
        • REF
        Provides a retrieved reference ID, when Portal drops off the user attributes. Portal needs to drop off these user attributes (Note: the actual attribute names vary based on OCIS team’s setup. Please check these names with OCIS team):
        • firstName
        • lastName
        • dob: date of birth, MM/dd/yyyy format
        • idValue: one of search_keys identifier.
        • subject: The string that uniquely identifies the user. e.g. External Vendor identifier + SAML subject originally included in External Vendor’s SAML. The uniqueness of this subject string is useful when some SSO issue needs to be investigated.
        • authn_cntx: ACR value originally included in External Vendor’s SAML. (See ACR requirements for inbound SSO and portal implementation changes) • email: Optional. Provided email will be prefilled upon SSO Registration, if matching HSID account does not exist.

Opentoken agent integration example – only for HSID legacy external Inbound SSO migration to EDA

Query Parameters (all values should be query-parameter-value encoded)
  • PARTNER
    • Non-prod: uhg.stage.hsidportals.sp.hsidaikyam
    • Prod: uhg.prod.hsidportals.sp.hsidaikyam
    • PARTNER parameter value would be different from the one used in Legacy HSID External Inbound SSO.
    • TARGET
      • See “GET Example” above.
  • form-urlencoded data
    • opentoken
      • It is an encrypted token generated by OpenToken Agent.
      • For migration case, Portal can keep using the same opentoken agent setup used in HSID legacy.
      • For user attribute claims and values, please see “REF” above.

On this page

Powered by Aikyam @2025 All rights reserved