It is possible to configure your ASM setup so that users sign in using Single Sign On (SSO) via an Customers who have adopted a centralized SAML 2.0-compatible Identity Provider (IdP) rather than using static credentialscan utilize SSO to sign into the ASM portal and to manage and administer user accounts.
Overview
| Note |
|---|
Read this section before attempting an SSO setup. It contains important information which will help you understand the configuration you will be performing! If you have already read the Overview or otherwise wish to proceed to SSO setup from within the ASM Portal, see the section https://apica-kb.atlassian.net/wiki/spaces/ASMDOCS/pages/2150498502/Configuring+SSO+Within+ASM#SettingASM#Step-up2%3A-SSOConfigure-FromASM-theto-ASMUtilize-PortalSSO. |
Understanding the Roles of Identity and Service Providers in Relation to ASM
SSO enables customers that have adopted a centralized SAML 2.0-compatible Identity Provider (IdP) to integrate this with the ASM WPM portal login and also to manage and administrate its users.
SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about an end-user between an IdP and a service provider identity provider (IdP) and a service provider (SP). SAML 2.0 enables web-based authentication and authorization scenarios including cross-domain SSO, which helps reduce the administrative overhead of distributing multiple authentication tokens to the user.
The Single Sign-On screen allows you to enable and configure settings for SSO Identity Providers/ IdPs such as:
Centrify
Okta
CA SSO (formerly CA Siteminder)
Azure and ADFS
OpenAM
Symantec/Broadcom VIP Access Manager
...
Comparing SP-initiated
...
and IdP-initiated Authentication
In order to correctly set up/define RelayState, you must first determine which kind of authentication flow you need. There is a difference between a Service Provider (SP)-Initiated authentication and an Identity Provider (IdP)-Initiated authentication flow.
SP-Initiated authentication flow
In this first case, the SP-Initiated authentication flow is when you type the Service Provider URL and it redirects to the IdP. This is considered a common setup, where Apica is sending the request to the IDP for authentication.
The RelayState here is a token/value.
...
| panelIconId | 1f510 |
|---|---|
| panelIcon | :closed_lock_with_key: |
| panelIconText | 🔐 |
| bgColor | #EAE6FF |
...
The ASM portal is capable of accepting SSO configurations which utilize either SP or IdP-initiated authentication flows.
In a SP-initiated authentication flow, the end user browser sends an authentication request to the SP login URL (in this case, ASM/ALT is the SP). The SP responds to the browser with a redirect to the IdP for authentication with a SAML request that includes a RelayState token/value. When the browser sends the request to the IdP (e.g. Okta, Centrify, Azure AD., etc.)
...
Therefore, in this case, the IdP knows who is initiating the (SAML) authentication flow.
This is important because the IdP can serve more than one SP, so the IdP knows who is sending the request: We do not need to modify the URL to tell the IDP who we are.
So, the RelayState is a token/value that gets relayed (without modification/inspection) between Apica (the SP) and the IdP.
IdP-Initiated authentication flow
In this second case, the IdP-Initiated authentication flow is when you type the IdP URL into a browser (a browser is a User-Agent) and therefore the IdP does not know who is sending the SAMLRequest.
In this case, you’d need to authenticate to the IdP and attempt to access an SP asset via the IdP. A set of predetermined, additional, attributes associated with the authenticated user would be populated in the SAML response back/POSTed to the SP.
An IdP-Initiated authentication flow uses RelayState to signal to the SP what URL the SP should POST/Redirect to after successful sign-on.
The SAML 2.0 Standard, states that RelayState “MAY be the URL of a resource at the service provider.”
So, in this IdP-initiated SSO case, the RelayState field in the SAML post from the browser is empty/absent but used by the IdP for the URL redirect for the POST for the SP.
...
| panelIconId | 1f510 |
|---|---|
| panelIcon | :closed_lock_with_key: |
| panelIconText | 🔐 |
| bgColor | #DEEBFF |
...
, the IdP authenticates the user and responds with a browser redirect that includes a SAML message with a SAML assertion and the unmodified RelayState. When the browser sends the SAML response with the unmodified RelayState to the SP, the SP uses the RelayState to validate the that the assertion is the result of a request originating from the SP.Once SSO configuration is complete in ASM/ALT, SP-initiated authentication is supported by default. Although it is generally accepted that IdP-initiated authentication is less secure because the SP is unaware of an authentication request when it receives the SAML message/assertion and therefore cannot detect if the message/assertion was stolen or replayed, IdP-initiated authentication can be supported with appropriate configuration on the IdP.
| Tip |
|---|
Apica utilizes SP-initiated authentication flow by default! |
In an IdP-initiated authentication flow, the end user navigates to the IdP URL, is prompted for authentication and is presented with a link to the SP (in this case, ASM/ALT is the SP). A set of predetermined additional attributes associated with the authenticated user and the SP will be populated in the SAML response sent to the browser (customerName (required), RelayState (optional?), etc.), with a redirect to the SP. The browser then POSTs the SAML message/assertion to the SP. For Apica, this login flow can include RelayState to indicate what URL Apica should redirect to after a successful SAML assertion.
When this flow is utilized, the end user logs into their IdP (e.g. Okta, Centrify, Azure AD., etc.) and
...
clicks on a link to
...
ASM from there. Then, the IdP sends the browser a customerName and RelayState attribute in the SAML response, which will redirect the user to the ASM dashboard.
Understanding SP-initiated Authentication as it Relates to Apica SSO Login
The following diagram further explains the roles of the Service ProviderSP, User-Agent, and Identity Provider IdP in the ASM SSO login process as it relates to ASM when SP-initiated authentication is used. Here, of course, Apica is the Service Provider and does the configuring of SP and configures the target assets.
| Note |
|---|
These target assets have no access controls on them (just an association to ASM), so the access controls and rules are set on the IdP side. |
User Role: List of User Roles in ASM to associate with the Identity Provider Role.
Monitoring Groups: List of Monitor Groups in ASM to associate with the Identity Provider Role.
Co-Owned Monitoring Groups: List of Monitor Groups for the Customer’s Power User Role to associate as co-owner with the Identity Provider role.
The browser (an HTTP user agent) is our the User-Agent.
The IdP is the Identity Provider that identifies the IdP Role / Group and the levels of access/permissions they are allowed
...
.
Their relationship and their communications are illustrated here (This illustration is an annotated excerpt from the SAML 2.0 Wikipedia Article):
...