Raftr SSO (SAML2) Technical Implementation Guide

Purpose

This document outlines the various approaches to implementation of a unified or single sign on (SSO) approach when using the Raftr service. The Raftr service currently supports the SAML2 specification for supporting SSO.

Background

The Raftr service is delivered to the end user in the form of a web application, an iOS application, or an Android application. The user-facing software runs on the public Internet, and is accessible from any location in the world. Users can be authenticated in various ways, but primarily through the use of an email address and password. For customers who wish to unify the Raftr authentication system with their own existing SSO system, this document highlights what is needed to complete an integration. 

Authentication in Raftr

It should be noted that the Raftr service can be used without any SSO integration. The Raftr service includes several ways to authenticate users before they are allowed to create a new account. These registration restrictions include the use of restricting logins to emails in certain domains (useful if the customer assigns email addresses to all users) or the use of access/invitation codes sent to specific users to allow registration. Finally, the Raftr service supports the use of SAML2 based SSO authentication before allowing a new user to complete registration. 

Considerations

For customers who have consolidated their user authentication inside an SSO service, leveraging that service to control access to registration on the Raftr system provides many benefits. Because an SSO implementation is a system integration between two parties (Raftr and Customer), the use of SSO adds significant complexity to the initial rollout of the Raftr service. This complexity also requires time to complete a successful integration.

Despite SAML2 being an SSO standard, each SSO vendor has implemented SAML2 in a slightly different way. In addition, there are several configuration tasks needed to ensure the Raftr service and the Customer’s SAML2 (SSO) service can properly communicate. There are also several “trust certificates” that must be created, shared, and validated in order for the SSO link via SAML2 to be secure. A basic SAML2 integration may take as little as a few weeks of time if the SSO vendor system has a fairly standard SAML2 implementation and the customer has access to a high level of vendor support to assist with configuration and validation. A typical implementation could take up to 2 months to complete, allowing time to work around any non-standard SAML2 implementation issues and also allowing time for vendor support escalations where needed. 

SSO Overview

There are three major components to SSO: the Raftr system, the Customer authentication system, and the end user. SAML2 is fundamentally designed with all three entities in mind. Through the use of browser redirects, SAML2 accepts SSO credentials from the end user and passes verification of those credentials to the Raftr system via browser redirects. Once the end user is authenticated in the Raftr system (using email as the shared identity key), the user is then redirected to a final registration page.

For SSO to work properly, all three of these components must be in lockstep with each other. The Raftr and Customer systems must be up and running, and able to authenticate requests from each other to prevent fraud. The end user must have a modern browser that can properly connect with both the Customer and Raftr systems to securely complete the authentication process. And finally, connectivity between the end user and both the Raftr and Customer systems must be available and reliable.

Requirements

General 

As mentioned above, the Raftr system relies on the SAML2 protocol for authentication. Because SAML2 is a standard protocol, a SAML2 compliant authentication server (with proper configuration) is all that is needed to enable SSO for Raftr. The bulk of the time during implementation is typically spent ensuring that configurations are correct and that the two back end systems are able to authenticate each other.

Customer SSO information needed by Raftr

As a way to get started with the SAML2 based SSO integration, Raftr has assembled the following checklist which will assist us in completing the initial configuration for a SAML2 SSO integration from the Raftr service perspective.

In addition to the SSO/SAML2 information, in order for Raftr to complete end-to-end testing, a customer test account in the customer production SSO environment is needed. This is typically an email address and a password, shared during the implementation process.

To properly configure Raftr for use with Single Sign On, we request that the customer provides the following information to Raftr:

• Metadata File (XML format)
  • It’s recommended that this be a URL hosted on your side.
  • IDP Entity ID  (Should be part of the XML Metadata)
  • Note: The Name Identifier in the Metadata file must be the user email address.
  
  
• Test Account credentials in customer SSO environment for use by Raftr

Raftr SSO Information for Customer SSO configuration

The customer should configure their production SSO environment to support SSO integration with both the Raftr Production and Raftr Testing environments specified below. Contact your customer success partner for your specific URLs.

Raftr Production:

• Raftr SSO Metadata URL
• Raftr Service Provider URL

Raftr Testing:

• Raftr Testing SSO Metadata URL
• Raftr Testing Service Provider URL