This article will describe how Single Sign-On (SSO) can be implemented using Security Assertion Markup Language 2.0 (SAML) to enable employees who have been authenticated by a third-party system to access Reward Gateway without credentials.

Single sign-on (SSO) helps you give your users streamlined access to SaaS, mobile, cloud and enterprise applications. With SSO, you can deliver the experience your users demand and strengthen your security in the process.

SAML

Reward Gateway uses the XML-based Security Assertion Markup Language 2.0 (SAML) protocol for Single Sign-On.

SAML is a standardized way to tell external applications and services that a user is who they say they are. SAML makes single sign-on (SSO) technology possible by providing a way to authenticate a user once and then communicate that authentication to multiple applications.

Considerations

• Reward Gateway supports SAML version 2.0

• Reward Gateway supports Identity Provider Initiated SSO and Service Provider initiated SSO

• Reward Gateway supports HTTP POST binding, not HTTP REDIRECT. You must configure HTTP POST bindings in the IDP metadata. 

• The Identity Provider must ensure a user is both authenticated and authorized before sending an assertion. If a user isn't authorized, assertions should not be sent. We recommend your identity provider redirects people to an HTTP 403 page or something similar.

• Reward Gateway supports Just-In-Time user provisioning via SAML. Read more about JIT here.

Configuring your identity provider

To get started, you need to set up a connection on Reward Gateway with the Identity Provider. You can check our guides below for the different providers we’ve worked with.

If the Identity Provider is not listed above, it is nothing to worry about. You can set up a custom Inbound SSO. Check our guide on how to do that here.

Setting up the Integration on Reward Manager

Each of the Identity Providers listed above has its own associated Integration on the Integration Dashboard in Reward Manager. 

Select the integration you wish to proceed with and follow the instructions below to complete the setup. 

The setup process includes 4 steps:

1. Initial setup: Capturing identity provider details

2. Mapping: Mapping SAML attributes from the IDP to SP

3. Testing: Testing the connector

4. Review and Publish: Review the setup and request it to be published  

Testing your SAML Integration

You need to test the integration in order for it to be published. During the testing stage, an actual SAML Response must be sent to the SAML Consumer URL (ACS). This could be done by attempting to log in using the new SAML connector with the Identity Provider. 

If there are any errors with the connection, the testing step would provide a detailed list of the errors and also show the raw SAML Response related to that attempt.

Management 

SAML is a method for authentication, not for the management of the accounts. Although we can set up Just-In-Time provisioning, the administrators of the programme would still have to remove users.

Removing the users could be done through sFTP, SCIM API or any of the other provisioning applications that we support.

Further Reading

Additional information on SAML can be found through the following links:

• http://en.wikipedia.org/wiki/SAML_2.0

• https://www.oasis-open.org/standards#samlv2.0