PlanSource API

SAML 2.0 SSO Implementation

This document describes the implementation of SSO with PlanSource Benefits system via SAML 2.0.

Overview

SAML 2.0 is an open standard for exchanging authentication and authorization data between security domains.
PlanSource Benefits system can be both a SP (service provider) and an IdP (identity provider).

Implementation Details for Service Provider (SP)

Please see the Sample SAML MetaData File below for requirements for SAML assertions:

  • SAML attributes
  • x.509 certificate for e-signature
  • Any additional details

Configuration Highlights:

  • PlanSource currently only supports so called “unsolicited SAML SSO”, which means that the SSO is initiated by an identity provider: the customer sends SAMLResponse to PlanSource’s SSO endpoint URL via HTTP POST, from the user’s browser.
    
  • PlanSource’s SAML endpoint URL is: https://benefits.plansource.com/sso/employee/saml2/post, it is not the same as RelayState value.
  • RelayState value provided by PlanSource must be sent as a HTTP POST parameter, together with SAMLResponse parameter. SSO endpoint expects 2 POST parameters in total:
  • SAMLResponse – e-signed SAML assertion wrapped in a SAMLResponse.
    • Example: SAMlResponse = ASDFASEDAFEQAFCVAWERQWERFAWE
  • RelayState – value provided by PlanSource in the configuration.

Clarifications for Different SSO Types within PlanSource

Employee SSO:

  • Employee demographic data must be loaded into PlanSource Benefits system.
  • Each loaded employee needs to have “subscriber_code” value set: a unique identifier of an employee, provided by the organization. This code could be loaded as part of the initial demographic data import or it could be set on existing employee records via a spreadsheet import.
  • Send “subscriber_code” values in the “empID” attribute with each SAML response. For employee SSO this is the only required attribute, the rest of the attributes are optional and they would be ignored.

Admin SSO (all levels: organization, agent, and broker):

  • Admin users need to be created in the Benefits system before the first SSO request.
  • Send admin’s user name value in the “username” attribute with each SAML response. The rest of the fields are optional.

Additional Details:

  • If Audience is sent in the SAML response it must not be blank
  • If Recipient is sent in the SAML response it must match the Audience value
  •   If Name ID is sent in the subject it must not be blank
    

Implementation Details for Identity Provider (IdP)

Please see the Sample SAML MetaData File below for:

  • Information necessary to start the implementation IdP
  • Remaining information is to be negotiated on case-by-case basis.

PlanSource Sample SAML MetaData File

PlanSource SAML MetaData File

How to Configure SAML SSO at the Client Level

To learn more about configuring SAML SSO at the client level, click here!

Updated about a year ago

SAML 2.0 SSO Implementation


This document describes the implementation of SSO with PlanSource Benefits system via SAML 2.0.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.