Single Sign-On

Activator supports Single Sign-On (SSO). This means that if you have a third-party SAML user identity provider (IdP), you can allow users who are authenticated on that IdP to connect to the Activator user interface without additional authentication. The SSO implementation in Activator is a so-called SP-initiated SSO exchange, where Activator acts as the Service Provider (SP). The Activator SSO functionality requires the use of a third-party SAML-based identity provider (IdP).

Example sign on scenario:

Diagram showing the SSO process between Activator and an Identity Provider

When Activator is configured for SSO, the following events occur at log on:

  1. A user tries to connect through a browser to Activator (the Service Provider).
  2. The user is redirected by the Service Provider to the Identity Provider (IdP).
  3. If the user is not already authenticated on the IdP, the user is prompted to provide account credentials. If the user is already authenticated, the IdP redirects the user back to the Service Provider.
  4. The IdP analyzes the logon credentials and returns a signed response to the browser.
  5. The browser sends the signed response to the Service Provider (to the assertion consumer URL from the Service Provider). In Activator, this is a standard URL: https://< Activator>/ui/core/SsoSamlAssertionConsumer .
  6. The Service Provider parses the SAML assertion details in the response and maps them to Activator roles, then provides the requested resource (assuming the identified user has access rights).

User authentication cases

  • If the user is not logged into the IdP server, when the user attempts to log on to Activator, he or she is redirected to the IdP login page.
  • For Activator-defined users, the normal authentication logic is applied, including the defined user roles.
  • For externally validated users, the SAML assertion must be mapped to a defined role in Activator. You can map Activator roles to SAML assertion attributes in the Activator user interface.
  • If a user that tries to log over SSO SAML does not exist in Activator, Activator creates the user with a flag that prevents the account from being used for normal (non-SSO) logins.
  • Logging out of Activator does not log the user out at the IdP level.

Features and characteristics

  • The third-party IdP is used for identification, not for authorization. Authorization details remain in the Activator role definitions.
  • In the Activator user interface, you can specify the certificates to use for encryption and for validation of the signature of the assertion that is sent by the IdP.
  • SSO authenticated users cannot change their own passwords.
  • None of the settings on the Change global settings page apply to external users, except Maximum session length.
  • Your SSO configuration settings are included in the global system backup and restore.
  • Activator supports the SSO connection via a dedicated embedded server. This server is automatically started at system startup. Select System management > Manage embedded servers to open the Embedded servers page and view the CnHttpsSamlSsoServer in the embedded servers list.

Single Logout

Activator supports the SAML SSO Single Logout (SLO) process from the Identity Provider (IdP) or from the Activator Service Provider (SP).

For single logout requests, Activator supports the following two SAML protocol bindings:

HTTP-redirect binding

For SP initiated single logout only.

The HTTP Redirect binding defines a mechanism by which SAML protocol messages can be transmitted within URL parameters.

HTTP Redirect binding is used in cases in which the SAML requester and responder must communicate using an HTTP user agent as intermediary. This may be necessary, for example, if the communicating parties do not share a direct path of communication.

It may also be needed if the responder requires an interaction with the user agent in order to fulfill the request, such as when the user agent must authenticate to it.

HTTP-POST binding

For IdP and SP initiated single logout.

The HTTP POST binding defines a mechanism by which SAML protocol messages may be transmitted within the base64-encoded content of an HTML form control.

The HTTP POST binding is intended for cases in which the SAML requester and responder need to communicate using an HTTP user agent (as defined in HTTP 1.1 [RFC2616]) as an intermediary. This may be necessary, for example, if the communicating parties do not share a direct path of communication.

It may also be needed if the responder requires an interaction with the user agent in order to fulfill the request, such as when the user agent must authenticate to it.

Single Logout scenarios

The following scenarios illustrate the results of the various logout configuration settings.

Scenario 1

Configuration:

Single logout parameter Setting
Activator logout redirect URL Not configured
IdP HTTP-POST binding URL Not configured
IdP HTTP-Redirect binding URL Not configured

User action: Logout link clicked from Activator UI.

Result: Page is displayed to close the browser and terminate the session.

Scenario 2

Configuration:

Single logout parameter Setting
Activator logout redirect URL Not configured
IdP HTTP-POST binding URL Not configured
IdP HTTP-Redirect binding URL Configured

User action: Logout link clicked from Activator UI.

Result: Page is displayed to close the browser and terminate the session.

Scenario 3

Configuration:

Single logout parameter Setting
Activator logout redirect URL Not configured
IdP HTTP-POST binding URL Configured
IdP HTTP-Redirect binding URL Not configured

Initiator: Activator (SP Initiated Logout)

User action: Logout link clicked from Activator UI.

Result: LogoutRequest with POST binding is sent to IDP.

Scenario 4

Configuration:

Single logout parameter Setting
Activator logout redirect URL Configured with POST binding URL
IdP HTTP-POST binding URL Configured
IdP HTTP-Redirect binding URL Not configured

Initiator: IdP (IdP initiated logout - POST binding)

User action: Logout link clicked from Activator UI.

Result: Activator redirect to the URL that triggers IDP initiated POST single logout.

Scenario 5

Configuration:

Single logout parameter Setting
Activator logout redirect URL Configured with Redirect binding URL
IdP HTTP-POST binding URL Not configured
IdP HTTP-Redirect binding URL Configured

Initiator: IdP (IdP initiated logout - Redirect binding)

User action: Logout link clicked from Activator UI.

Result: Activator redirect to the URL that triggers IdP initiated Redirect single logout.

Scenario 6

Configuration:

Single logout parameter Setting
Activator logout redirect URL Configured with POST binding URL
IdP HTTP-POST binding URL Not configured
IdP HTTP-Redirect binding URL Configured

User action: Logout link clicked from Activator UI.

Result: Logout URL error displayed in SP browser.

Scenario 7

Configuration:

Single logout parameter Setting
Activator logout redirect URL Configured with Redirect binding URL
IdP HTTP-POST binding URL Configured
IdP HTTP-Redirect binding URL Not configured

User action: Logout link clicked from Activator UI.

Result: Logout URL error displayed in SP browser.

SAML metadata

Activator provides SAML metadata to provision Single Logout Service endpoints for sending logout requests and responses.

Configure SSO / SLO

To set up SSO and SLO in Activator, see Configure SSO SAML.

Related topics

Related Links