OIDC endpoint URLs without clientname in CA Access Gateway (SPS)
search cancel

OIDC endpoint URLs without clientname in CA Access Gateway (SPS)

book

Article ID: 193287

calendar_today

Updated On:

Products

CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) SITEMINDER

Issue/Introduction

 

When running a CA Access Gateway (SPS), is it supported to call the OIDC endpoints generated for OIDC clients without the clientname part?

  <authorizationserver_base_URL>/affwebservices/CASSO/oidc/sample_client/token
  <authorizationserver_base_URL>/affwebservices/CASSO/oidc/token

 

Environment

 

CA Access Gateway (SPS) 12.8SP3 on RedHat 7;
Policy Server 12.8SP3 on RedHat 7;

 

Resolution

 

From the documentation, some modification has been brought in 12.8SP3 (1)(2).

So, according to documentation, both ways are supported, depending on the value of the "Enable Well-known" functionality. Note that an upgrade from 12.8SP2 to 12.8SP3 may break some URLs.

From the documentation, the sample_client is mentioned as "Sample" only (3).

RFC doesn't say precisely anything about the preceding URI of /token (4).

Use the clientname part in the URL as the product has been designed for that sake, mainly when OpenID Discovery is in use. The use of the URI without clientname is an old endpoint naming that still can be used, with limitations as per above.

 

Additional Information

 

(1)

    Manage Provider Metadata Feature

      From 12.8.02, CA Single Sign-on as an OpenID Connect Provider supports
      the Well-known Endpoint. To support the feature, client_name is
      appended to the URL format as shown here:

Issuer URL: https://Access_Gateway_server:port/affwebservices/CASSO/oidc/client_name
Endpoint URL: https:/Access_Gateway_server:port/affwebservices/CASSO/oidc/client_name/endpoint

      From 12.8.03, you can enable or disable the provider metadata feature
      using the new field Enable Well-known in Administrative UI. The status
      of this option manages whether Well-known endpoint is displayed when
      an OIDC Client is created, and it also determines the Issuer URL
      format

(2)

    (From Release 12.8.02) Enable Well-known

      Specifies whether the provider metadata feature is enabled or
      disabled. The status of this option manages the provider metadata
      feature and thereby the Issuer URL format.

      Default: Disabled

      If Enable Well-known is selected, CA Single Sign-on performs the
      following actions when it creates a client:

Displays the Provider Metadata endpoint in the following format in
Administrative UI:

  https://Access_Gateway_server:port/affwebservices/CASSO/oidc/client_name/.well-known/openid-configuration

Displays the other endpoints in the following format:

  https://Access_Gateway_server:port/affwebservices/CASSO/oidc/client_name/endpoint_name

Displays the Issuer URL value in the following format in
Administrative UI:

  https://Access_Gateway_server:port/affwebservices/CASSO/oidc/client_name

(Runtime) Includes Issuer URL in the following format when the iss
claim is sent in responses such as ID Token and signed UserInfo
response:

  https://Access_Gateway_server:port/affwebservices/CASSO/oidc/client_name

      If Enable Well-known is not selected, CA Single Sign-on performs the
      following actions:

Does not display the Provider Metadata endpoint in Administrative UI.

Displays the other endpoints in the following format in Administrative
UI:

  https://Access_Gateway_server:port/affwebservices/CASSO/oidc/endpoint_name

Displays the Issuer URL value in the following format in
Administrative UI:

  https://Access_Gateway_server:port

(Runtime) Includes Issuer URL in the following format when the iss
claim is sent in responses such as ID Token and signed UserInfo
response:

  https://Access_Gateway_server:port

      Note: If you are using 12.8.02 and you are upgrading your
      environment to 12.8.03, your existing endpoints URLs may not
      continue to work in 12.8.03 once you upgrade. To avoid the issue,
      you must perform the steps related to OIDC objects upgrade in Policy
      Server upgrade and policy store upgrade topics. For more information
      about the steps required to upgrade OIDC objects, see the Policy
      Server and policy store upgrading sections in In-place Upgrade and
      Rolling Upgrade.
  

(3)

    Authentication Using Implicit Flow
   

(4)

        The OAuth 2.0 Authorization Framework