Single Sign On
Integration Guide
2
Table of Contents
About this document ... 3
Purpose ... 3 Target ... 3 Support ... 3 Overview ... 4 SAML ... 5 SAML in general ... 5
How SAML is used for SSO ... 5
What you need ... 7
Single Sign On 3
About this document
Purpose
This document describes in general how a partner may set up a Single Sign On environment with one of Signicat's customers.
Target
The document's intended audience is technical personnel with a general understanding of web technology. The reader should also preferably have a general understanding of how SAML 1 and/or SAML 2 can be used for federating between two web sites.
Support
Our support staff will be happy to help you with any questions. Phone: +47 4000 3410
4
Overview
Signicat provides an online service for authenticating end users on the web. Web sites that use Signicat's service for authenticating end users will typically send their users to
Signicat's web site for authentication whenever this is needed. Signicat will do what is needed to authenticate the end user before sending the end user back to the customer’s site with a verified identity.
Signicat also provides SSO between selected partners and Signicat's customer. The partner and Signicat will set up a SSO environment that is further extended by a SSO environment between Signicat and Signicat's customer.
The SSO environment between the partner and Signicat can be set up using either SAML 1 or SAML 2.
Single Sign On 5
SAML
SAML in general
A complete description of how SAML works is outside the scope of this document. A technical overview of SAML can be downloaded from oasis-open.org (http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf). The complete specification is also available from oasis-open.org.
SAML defines a framework for exchanging security information between online business partners. In this context SAML will be used to exchange the end users identity between the partner and Signicat when the end user is about to follow a link from the partners web site to the customers web site.
How SAML is used for SSO
The partner has to detect that the end user is about to open a web page on Signicat's customers web site. The partner must at this point create a SAML message with the end users identity. The end user must be sent to Signicat with this message. Signicat will verify the end users identity and forward the user to Signicat's customer in the same way as if the end user had just logged in at Signicat. Signicat's customer may detect that the end user was forwarded from the partner, but they may also choose to ignore this and treat the end user in the same way as if he had just logged in.
6 Signicat supports SAML 1 and SAML 2. In this scenario the "IdP-Initiated SSO: POST Binding" profile is used. The partner will take the role as IdP (since the end user was identified here) while Signicat will take the role as SP.
The SAML message that is sent from the partner to Signicat will contain the end users identity. This identity must be in the form of a customer number, user name or other attribute that is known for Signicat's customer. In the Scandinavian countries a national identity number like the Swedish "personnummer", Norwegian "fødselsnummer", Danish "CPR" or Finnish "Hetu" is typically used if available.
Along with the SAML message, the partner must also send a "target url" (also specified by SAML). The target url is the url where Signicat is supposed to forward the end user when his identity is verified. This url must point to the web site that the end user should see. It may contain http parameters as long as the parameters is embedded in the url. Signicat will redirect the end user to this url using http code 302 (that is, a normal http redirect). The end user will normally not see any web pages at Signicat. The user experience should be that he clicks on a link on the partner web site and is immediately sent to the desired target web page. The whole SAML operation for transmitting the users identity and redirect from Signicat to Signicat's customer is done "behind the scenes".
Single Sign On 7
What you need
Overview
The partner will need some sort of SAML enabled software to take the role as "identity provider" in this scenario. There is no need for a full-fledged SAML identity management suite. The software only need to handle the IdP role in the "IdP-Initiated SSO: POST Binding" protocol and the protocols for session shareing and single logout.
Three different ways to fulfil this requirement is by:
• Using a SAML enabled federation product. A wide range of major industry players like IBM, Oracle and others provides this kind of products. Any SAML compliant product would probably work "out of the box".
• Using a SAML library that is integrated into the partners own software • Implementing SAML functionality from scratch
Signicat will strongly discourage implementing SAML from scratch, as this is a major task. Signicat provides a SAML Library for Java. This library is easy to use and Signicat
