Activator 6.0.0 Administrator Guide 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: When Activator is configured for SSO, the following events occur at log on: A user tries to connect through a browser to Activator (the Service Provider). Activator redirects the user to the Identity Provider (IdP). 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. The user logs on to the IdP. The IdP analyzes the logon credentials and returns a signed response to the browser. 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. 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 Example SSO IdP configuration Related Links
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: When Activator is configured for SSO, the following events occur at log on: A user tries to connect through a browser to Activator (the Service Provider). Activator redirects the user to the Identity Provider (IdP). 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. The user logs on to the IdP. The IdP analyzes the logon credentials and returns a signed response to the browser. 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. 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 Example SSO IdP configuration