SAML Integration

From idenprotect Knowledge Base
Jump to: navigation, search


The idenprotect Authentication Portal allows for multiple applications to be integrated with idenprotect and for users to authenticate once, but then access those applications without further authentication required.

The standard integration method is to use SAML.

This article explains the concepts behind such an integration. Other integration approaches are possible but these are not covered in this article.


There are two roles within a SAML authentication

Service Provider is a cloud/web service that the user must be authenticated to before they can access

Identity Provider (idenprotect Authentication Portal) is responsible for authenticating the user.

SAML uses a Federation Model, whereby the roles of Service Provider and Identity Provider are separate.

For example, if User A has access to corporate data belonging to Company A in a cloud service such as Then to access that data, User A must authenticate to the Authentication Portal belonging to Company A.

Authentication Flow

There are a number of different ways (called bindings) that are supported by the SAML standard, but the most common ones are based around browser-based (https) interactions.

  1. The user goes to the service provider
  2. The service provider has been configured to use federation and redirects the user to the Authentication Portal it has been configured to use.
  3. The user authenticates to the Authentication Portal.
  4. The Authentication Portal creates a SAML assertion, which it signs using its private key
  5. The user is redirected back to the Service Provider with the SAML assertion
  6. The Service Provider validates the SAML assertion and allows the user access

Therefore to support these integrations the Service Provider needs to know the details of the idenprotect Authentication Portal and the idenprotect Authentication Portal needs to know the details of the Service Provider.

Configuring The Service Provider

The details that need to be entered on the service providers are

  1. The entity-id of the idenprotect Authentication Portal, by convention, this is the URL of the idenprotect Authentication Portal. This is set as part of the idenprotect configuration
  2. The URL the user needs to be sent to in order to authenticate
  3. The certificate that the Service Provider should use to validate the signature on the SAML assertion
  4. You may also need to set the signature algorithm (SHA-1)

An Authentication Portal may publish these details via metadata.

For example, if you go to https://<hostname>/idp/metadata, where <hostname> is the hostname of the idenprotect Authentication Portal, you can download an XML file that has all the above information in it along with other settings that may be required.

Some Service Providers can be automatically configured by providing this metadata URL or file.

Configuring The idenprotect Authentication Portal

The configuration of the idenprotect Authentication Portal is the mirror of the Service Provider, so the following elements need configuring

  1. The entity-id of the Service Provider.
  2. The URL the user needs to be sent after they have authenticated (this is the Assertion Consumer Service or ACS)
  3. An additional optional setting is an Authentication Portal initiated URL. This allows the user to authenticate first and then go to the service provider with a SAML assertion. Not all service providers support this

Some examples of required settings are shown in Authentication Portal Service Provider Configuration