Single sign-on

Activator supports Single Sign-On (SSO). This means that if you have a third-party SAML 2.0 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 an "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; the Service Provider is Activator:

Single sign on authentication sequence.

 

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. Activator redirects the user 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 user logs on to the IdP.
  5. The IdP analyzes the logon credentials and returns a signed response to the browser.
  6. 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.
  7. 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

  • Activator supports only SAML version 2.0.
  • The third-party IdP is used for identification, not for authorization. Authorization details are configured 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".
  • Activator manages 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

Activator only supports redirect for IdP-initiated logouts.

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.

This metadata display becomes available only after you do the initial set up of Single Sign On/Single Sign Off:

  • Configure the UI connection via HTTPS
  • Import the IDP certificate
  • Complete the IdP and Service Provider fields in the Activator UI

Once the SSO features are configured, you can view the metadata page at the URL:

https://< Activator _install_machine>:6643/ui/core/SamlSsoMetadata

Configure SSO / SLO

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

For an example of how to configure Activator with an IdP, see Example SSO IdP configuration.

Limitations

  • Activator does not support:
    • The <Conditions> elements <OneTimeUse> or <ProxyRestriction>.
    • The <AuthnRequest> attributes "ForceAuthn" or “IsPassive".

Related topics

Related Links