Versions Compared

Old Version 3

changes.mady.by.user Caleb Miller

Saved on

compared with

New Version 4

changes.mady.by.user Caleb Miller

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Note

Read this section before attempting an SSO setup. It contains important information which will help you understand the configuration you will be performing!

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.

...

  • 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.

...

  • 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.

Panel
panelIconId1f510
panelIcon:closed_lock_with_key:
panelIconText🔐
bgColor#DEEBFF

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

...

Step

Technical Detail

  1. Request the target resource at the Service Provider (SP).

    1. In this case, the address in the User Agent/Browser is the login page at https://wpm.apicasystem.com/ and the Service Provider is the ASM service

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:

Code Block
 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.

  1. The service provider (ASM) returns a redirect to the browser with a SAML request).

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.

Code Block
302 Redirect
Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

The RelayState token is an opaque reference to state information maintained at the service provider. The value of the SAMLRequest parameter is a deflated, base64-encoded and URL-encoded value of an <samlp:AuthnRequest> element:

Code Block
  <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.

  1. The UA/browser requests the SSO Service at the IdP.

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:

Code Block
GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP/1.1
Host: idp.example.org

where the values of the SAMLRequest and RelayState parameters are the same as those provided in the redirect. The SSO Service at the identity provider processes the <samlp:AuthnRequest> element (by URL-decoding, base64-decoding and inflating the request, in that order) and performs a security check. If the user does not have a valid security context, the identity provider identifies the user with any mechanism.

  1. IdP responds with an XHTML form.

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:

Code Block
  <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 RelayState parameter has been preserved from step 3. The value of the SAMLResponse parameter is the base64 encoding of the following <samlp:Response> element:

Code Block
  <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>

  1. UA/Browser requests the Assertion Consumer Service at the SP/ASM.

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:

Code Block
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 SAMLResponse and RelayState parameters are taken from the XHTML form at step 4.

  1. ASM redirects the response to the target resource

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.

  1. UA/Browser requests the target resource at the ASM again

UA/Browser: “Please login/get an ASM Asset/Resource with these rights.”

The user agent requests the target resource at the service provider (again):

Code Block
 https://sp.example.com/myresource

  1. ASM responds with the requested resource to the UA/Browser which is a redirect to the target landing page within Apica WPM. i.e. Apica WPM returns the landing page.

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.

...