It is possible to configure your ASM setup so that users sign in using Single Sign On (SSO) via an Identity Provider (IdP) rather than using static credentials.
Overview
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#Setting-up-SSO-From-the-ASM-Portal.
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. 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
Understanding SP-initiated Authentication vs. 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.
An Apica example is where you would do a Single Sign-On Login from the Apica Synthetic Performance Portal and sending it a RelayState Token. Your IdP (e.g. Okta, Centrify, Azure AD., etc.) would be responsible for responding to the authentication request, and authorizing access to the portal.
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.
An Apica example is where you would do a Single Sign-On, SAML 2.0, Login from your IdP (e.g. Okta, Centrify, Azure AD., etc.) and, from there, click on a link to ASM. The IdP would send the browser acustomerName and RelayState attribute in the SAML response, which will redirect the user to the dashboard.
Understanding SP-initiated Authentication as it Relates to Apica SSO Login
The following diagram explains the roles of the Service Provider, User Agent, and Identity Provider in the SSO login process as it relates to ASM when SP-initiated authentication is used
Here, Apica is the Service Provider and does the configuring of the target assets.
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 User-Agent.
The IdP is the Identity Provider that identifies the IdP Role / Group and the levels of access/permissions they are allowed
It is in the IDP where the access rules and privileges are set for each role.
Their relationship and their communications are illustrated here (This illustration is an annotated excerpt from the SAML 2.0 Wikipedia Article):
This is the first, most common, use case, where the IdP is queried to provide access to the asset that is being requested. It could be any asset, like a video, an image, document, but for Apica Synthetic Monitoring it will access to the ASM Portal.
Step | Technical Detail |
|---|---|
User-Agent/Browser: “I want to log in/get access to an ASM resource using my SSO.” | The principal (via an HTTP user agent, the browser) requests a target resource at the service provider: https://sp.example.com/myresource The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2–7. The service provider may use any kind of mechanism to discover the identity provider that will be used, e.g., ask the user, use a preconfigured IdP, etc. |
The UA/Browser follows the redirect to the IdP (e.g. Centrify, Okta, CA Siteminder, Azure, ADFS, etc.) ASM: “Please check with your Identity Provider.” | The service provider generates an appropriate SAMLRequest (and RelayState, if any), then redirects the browser to the IdP SSO Service using a standard HTTP 302 redirect. 302 Redirect Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token The <samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
AssertionConsumerServiceIndex="0">
<saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
The SAMLRequest may be signed using the SP signing key. Typically, however, this is not necessary. |
UA/Browser to IdP: “Here’s my SSO request to gain access to a ASM resource (login/asset).” The IdP authenticates the user. | The user agent issues a GET request to the SSO service at the identity provider: GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP/1.1 Host: idp.example.org where the values of the |
The identity provider returns an authentication form most commonly a login page but could utilize a 2-factor authentication. IdP to UA/Browser: “Here are your authorization details in this form.” | The SSO Service validates the request and responds with a document containing an XHTML form: <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
<input type="hidden" name="SAMLResponse" value="response" />
<input type="hidden" name="RelayState" value="token" />
...
<input type="submit" value="Submit" />
</form>
The value of the <samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_2"
InResponseTo="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z"
Destination="https://sp.example.com/SAML2/SSO/POST">
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_3"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<!-- a POSTed assertion MUST be signed -->
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
InResponseTo="identifier_1"
Recipient="https://sp.example.com/SAML2/SSO/POST"
NotOnOrAfter="2004-12-05T09:27:05Z"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2004-12-05T09:17:05Z"
NotOnOrAfter="2004-12-05T09:27:05Z">
<saml:AudienceRestriction>
<saml:Audience>https://sp.example.com/SAML2</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2004-12-05T09:22:00Z"
SessionIndex="identifier_3">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
|
UA/Browser to ASM: “Here’s my IdP information that grants me this set of privileges/rights.” | The user agent issues a POST request to the Assertion Consumer Service at the service provider: POST /SAML2/SSO/POST HTTP/1.1 Host: sp.example.com Content-Type: application/x-www-form-urlencoded Content-Length: nnn SAMLResponse=response&RelayState=token where the values of the |
ASM: “Thank you. With those privileges, please request that resource again with your access rights.” | The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource. |
UA/Browser: “Please login/get an ASM Asset/Resource with these rights.” | The user agent requests the target resource at the service provider (again): https://sp.example.com/myresource |
ASM: “You are cleared/logged in/able to get the resource you requested. Here’s your content.” | Since a security context exists, the service provider returns the resource to the user agent. |
Understanding Single-Sign-On Flow
When Single sign-on is used, the user primarily interacts with Synthetic Monitoring, and is redirected as needed to the Identity Provider configured for their Customer account.
The user directs the browser to to ASM.
The browser accesses the ASM SSO login.
ASM returns a Identity Provider redirect with a SAML request.
The browser contacts the Identity Provider.
The identity provider returns an authentication form.
The form is shown to the user.
The user submits the form.
The identity provider authenticates the user.
The identity store provides the user authentication.
The identity provider returns a a SAML response including the user attributes and roles.
The browser sends SAML response to ASM for validation.
ASM returns a redirect to the landing page.
The browser requests the landing page.
ASM returns the landing page.
Setting up SSO From the ASM Portal
Before you begin, make sure you meet the following prerequisites:
SSO must be enabled by Apica for your Customer Account. Apica will perform this step for you.
SSO must be configured for your user account. This step must be performed by your organization.
The workflow to get SSO working in Synthetic Monitoring consists of two major steps:
1: Set up the Identity Provider - setting up users and user roles in the identity provider
2: Configure Synthetic Monitoring - setting up connection and mapping user roles between the systems
In the security model deployed to the Apica WPM API, there is a static access token issued per user. SSO users will not have access to this static token because it could be used to authenticate and access the API after a user's access has been revoked within the IdP. Therefore, SSO users can only utilize their API tokens while logged in and for 15 minutes after they have logged out. As such, it is generally beneficial to create a static user whose API key you can use for static automations.
Step 1: Set Up Identity Provider
For information about how to set up accounts in your Identity Provider, see that provider's documentation. You will need some information about the SAML setup for the Synthetic Monitoring configuration.
Step 2: Configure ASM to Utilize SSO
After the Identity Provider and Service Provider has been setup the Administrators will need to map the user roles in the Identity Provider with the available Roles (Synthetic Monitoring User).
All available user roles in ASM can be mapped to any user role that the customer might have within their Identity Provider.
Step 2a: Navigate to Single Sign On Page
The Single Sign-On view allows you to enable and configure settings for Single Sign-On. First, navigate to the “Settings” page from the dropdown under your username in the top right of the ASM screen:
Next, click the “Single Sign-On (SAML 2.0)” button to access the Single Sign-On Configuration Page.
The “Single Sign-On (SAML 2.0)” button is only available to users with the Customer Admin role!
Step 2b: Configure Details in Single Sign-on (SAML 2.0) Page
The SSO view contains all settings needed to connect a user account with a SAML provider account. Configure this page with IdP-specific details as instructed in the following screenshot:
Step 3: Log in to ASM Using SSO
Step | Screenshot |
|---|---|
Click Sign In using SSO |  |
The SSO login dialog is shown.
|  |
If you have not Enabled your Customer Account for SSO, you will get a error to contact your Account Administrator. If you are unsure how to proceed at this point, contact support. |  |