PlanSource API

The PlanSource API Developer Hub

Welcome to the PlanSource API developer hub. You'll find comprehensive guides and documentation to help you start working with PlanSource API as quickly as possible, as well as support if you get stuck. Let us help you jump right in!

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:

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

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!

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.