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.
- Example: RelayState = https://benefits.plansource.com/sso/employee/saml2/post/c0614294154ec70e
- Example of full URL with both POST parameters: https://benefits.plansource.com/sso/employee/saml2/post?SAMLResponse=ASDFASEDAFEQAFCVAWERQWERFAWE&RelayState=https://benefits.plansource.com/sso/employee/saml2/post/c0614294154ec70e
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 the API-SSO Lookup Code in the username 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
How to Configure SAML SSO at the Client Level
To learn more about configuring SAML SSO at the client level, click here!
Updated 4 months ago