This article will describe the different settings that must be configured to make a SAML connection work between an IDP and Reward Gateway (SP).
Whether using an existing IDP or a Custom SAML connector this guide will help make better understanding of the settings involved with completing the setup.
Please note, some of these fields may not be required depending on the Identity Provider used with Reward Gateway.
A name to uniquely identify the integration. This name will be used if a “Sign In with” button for this IDP is displayed on the landing page of the client program. I.e. “Sign in with Okta”.
This is the POST parameter a client’s SAML Response is posted to us in. It is defaulted to 'SAML Response' but if it is different it can be changed.
We require that the SAML response is signed to verify the client’s identity. This is different from the SSL certificate. Clients can then either upload a .crt file or paste a valid X.509 .pem Certificate.
Signature check to be performed on
What element of the SAML Response is signed? Is it the full SAML Response or just the SAML Assertions that are signed using the certificate uploaded above. One option must be chosen.
Service Provider Initiated Authentication?
This option can provide more secure authentication between the IDP and the SP by sending an additional SAML Request parameter to the IDP which must be returned to the SP as a part of the SAML Response.
Identity Provider URL
Depending on the mode of SSO (SP initiated or IDP initiated) this field will be mandatory or optional. If it is SP Initiated, it is a mandatory field as a SAML Request must be sent to initiate the authentication attempt.
If it is an IDP initiated setup, it is optional. However, if there is a sign-in page or something similar for the IDP, clients can include this here as it will help redirect users to the correct place to get authenticated.
This section will allow mapping of the outgoing fields / claims from the IDP to fields on Reward Gateway.
SAML Identity Location
There must be one field that is used to identify the employee and is mandatory to be selected. Clients can choose to send the employee identifier through the Name Identifier or as a separate attribute claim. If it is a separate attribute claim, clients need to make sure they include what the outgoing claim type or alias is.
Additionally clients can configure any of the attributes displayed on this page. Including the outgoing claim types or aliases for these and they will automatically be mapped during the SAML transfer.
Just in Time Provisioning
If enabled, employees will be automatically provisioned (after an one time registration process). The additional attributes configured above will be used to pre-populate the fields during the onboarding of the member.
At this stage, clients can make some sample attempts / assertions to the service provider Assertion Consumer Service URL provided. These attempts should be picked up automatically and in case of any errors, they will be displayed on the screen along with the assertion attempt.
Once any errors identified are fixed and a successful assertion attempt has been made, the greyed out “Next” button would turn green and allow you to proceed to the next step.
Review and Publish
Finally, the integration details can be reviewed and “Publish” can be clicked to enable the SSO Integration. Once published the SSO integration will be in a 'Pending' state. One of our Implementation Specialists will be informed and it will "Go Live" when required.