New Features

The content in this section provides information on new features for . 
casso128
The content in this section provides information on new features for 
CA Single Sign-On
 
 
Release 12.8
Support for Microsoft Windows 2016
 
CA Single Sign-On
 now supports Policy Server, Administrative UI, SDK, and 
CA Access Gateway
 on Windows 2016.
 
CA Single Sign-On
 as OpenID Connect Provider
 
CA Single Sign-On
 supports the following new features when it acts as OpenID Connect Provider (OP):
 
Note
: To use 
CA Single Sign-On
 as OP, ensure that you configured a session store and that 
CA Access Gateway
 is installed. Additionally, SSL must be enabled in 
CA Access Gateway
.
OIDC Implicit Flow
Besides Authorization Code Flow, 
CA Single Sign-On
 can now authenticate users using OIDC Implicit Flow for supporting clients that are browser-based, use a scripting language, and are Single-Page Applications (SPA). Authorization Endpoint issues Access Token and ID Token to a Client directly. 
CA Single Sign-On
 Implicit Flow is certified with OpenID Conformance Implicit Profile.
For more information, see Authentication Using Implicit Flow.
Refresh Tokens
You can use the Refresh Token grant type to generate Access Token without re-authenticating a user. You can specify the scopes with which the access token must be generated. 
Step-up Authentication Using ACRs
You can configure authentication levels that allows step-up authentication, which is based on a minimum authentication level for OpenID Connect Provider. Configure a minimum authentication level in each Authorization Provider for user authentication. 
CA Single Sign-On
 compares the SMSESSION value with the configured minimum authentication level to determine whether the user must be re-challenged for credentials.
Secure Communication for Public Clients Using PKCE
To mitigate the interception attack on Authorization Code Flow for public clients, you can configure Proof Key for Code Exchange (PKCE) and secure the communication between Authorization Endpoint and Access Token Endpoint.
Custom Client IDs
You can now use a custom name for Client ID when you register a Client with 
CA Single Sign-On
. If a value is not specified, 
CA Single Sign-On
 generates an ID during client registration.
For more information, see Clients Dialog.
Introspection Endpoint
The Validate Token Endpoint is renamed to 
Introspection Endpoint
. The endpoint validates the received Access Token or Refresh Token, and returns information such as token status and scope.
User Attribute Mappings
 
CA Single Sign-On
 supports user directory attribute mapping of various types such as alias, expression, and group. If user attribute mapping exists for a user directory attribute, the mapped user directory attribute value is returned in claims. Else, the actual value of the user directory attribute is returned.
For more information, see Authorization Provider Dialog.
Response Mode
You can now specify whether the authentication response to redirect_uri must be sent in the form of query parameters or encoded as HTML form values that are sent in POST method. By default, Authorization Code Flow uses 
query
 and Implicit Flow uses 
fragment
 as the response mode. If you want the response in the default format, you need not send this parameter in the authentication request. If you want the response encoded as HTML form values, specify 
form_post
 as the value in the authentication request.
User Info Request in a Query Format
You can now send a User Info request in a query format too besides a bearer header to User Info Endpoint.
Custom URI as Redirect URI
Besides HTTP and HTTPS, you can now specify a custom URI in redirect_uri. The custom URI must be in the 
scheme
:// format. 
JSON Web Token (JWT) Authentication Scheme
 
CA Single Sign-On
 supports JSON Web Token (JWT) template as an authentication scheme to authenticate and authorize the protected resources by accepting the JWT. The authentication scheme requires 
CA Access Gateway
 or 
CA Single Sign-On
 SDK for implementation. 
For more information, see JWT Authentication Scheme.
CA Single Sign-On as OpenID Connect Resource Server
 
CA Single Sign-On
 can act as an OpenID Connect Resource Server for web resources that are protected by the JWT authentication scheme. 
CA Single Sign-On
 accepts JWT that is generated by any OpenID Connect Provider. This feature requires 
CA Access Gateway
.
Authentication Scheme Level IP Whitelisting
 
CA Single Sign-On
 supports IP Whitelisting at authentication scheme level to restrict access by validating the requested Agent IP against the list of IPs to allow transaction.
IP whitelist is available for the following limited set of authentication templates:
  • X509 Client Cert Template
  • X509 Client Cert or Basic Template
  • X509 Client Cert or Form Template
  • Windows Authentication Template
  • Custom Template
JSON Request and Response Format for Authentication and Authorization Web Services
 
CA Single Sign-On
 now extends support for JSON request and response formats through REST Interface along with the existing XML request and response formats. This feature requires 
CA Access Gateway
 as a prerequisite.
Release 12.8.02
From Release 12.8.02, 
CA Single Sign-On
 supports the following additional new features: 
 
CA Single Sign-On
 as OpenID Connect Provider
 
CA Single Sign-On
 supports the following additional new features when it acts as OpenID Connect Provider (OP):
 
Note
: To use 
CA Single Sign-On
 as OP, ensure that you configured a session store and that 
CA Access Gateway
 is installed. Additionally, SSL must be enabled in 
CA Access Gateway
.
Generate ID Token in Refresh Token Flow
The Refresh Token flow lets you generate an ID Token along with Access Token. Relying Party can use the ID Token to grant seamless access to a user.  The Clients dialog of Administrative UI now includes a new field 
Generate ID Token in Refresh Token Flow
 to enable this feature.
Generate Custom Claims
You can customize the format of claims if a target application requires claims in a format that is different from the format in which they are configured in the user store. Use the OIDC IClaimsPlugin plug-in to customize the claims and return the customized claims in ID Token or UserInfo response. The plug-in lets you customize claims for each Client application without changing the attribute schema in your user store, and this lets you save resources. 
For more information, see Generate Custom Claims.
Support for Discovery Profile Using Well-known Endpoint
Relying Party or OIDC Client can use the Well-known Endpoint to dynamically retrieve the metadata of OP. Relying Party can use the latest provider metadata in constructing requests to various endpoints. This feature lets you build, deploy, and integrate applications with more ease.
For more information, see Discovery Profile of Provider Metadata.
Support for Native Applications
You can use 
CA Single Sign-On
 as OP to authenticate users and generate tokens for native applications along with web applications. 
To support native applications, the endpoints do not require client credentials in the Public Client requests. Also, custom URI is supported for Public Client redirect URIs. You can configure a custom redirect URI in Client configuration in the scheme:// format where scheme = alphabet *(alphabet|digit|+|-|.). 
 
Examples of Custom Redirect URIs 
:
cipe.mobile.native://callback
app.mobile.native://callback
Support for New Encoding Format in Authorization Header
In the previous versions, the Client ID and Client Secret values are specified in the 
Base64 encoded (Client ID:Client Secret)
 format in the authorization header for a Basic client authentication. From this release, the values can be specified in the 
Base64 encoded (URL encoded Client ID:URL encoded Client Secret)
 format too.
Kerberos Fallback to Forms Using Authentication Chain
 
CA Single Sign-On
 supports Kerberos fallback to forms-based authentication scheme. If the primary authentication scheme fails, the authentication process falls back to the secondary authentication scheme. The fallback process helps you combine multiple authentication schemes as a new Authentication Chain. This feature requires 
CA Access Gateway
 12.8.02.
For more information, see Configure Kerberos Fallback to Forms.
Retrieve User Attributes from Multiple User Directories
You can use the IDENTITY_MAP function to retrieve user attributes from other user directories besides the authorization user directory.  The following scenarios detail how you can use the function:
Consider that:
  • AD is authentication and authorization user directory, and AD LDS is a user directory that contains required additional attributes but it is not mapped with a realm.
    Without IDENTITY_MAP configuration, you can retrieve user attributes only from AD.
    With IDENTITY_MAP configuration, you can retrieve user attributes from AD LDS too if an identity mapping exists between AD-AD LDS.
  • AD is authentication user directory, LDAP is authorization user directory that is mapped with a realm, an authentication-authorization identity mapping exists between AD-LDAP, and AD LDS is a user directory that contains required additional attributes but it is not mapped with a realm.
    Without IDENTITY_MAP configuration, you can retrieve user attributes only from LDAP.
    With IDENTITY_MAP configuration, you can retrieve user attributes from AD LDS too if an identity mapping exists between AD-AD LDS
Retrieve Multiple Claim Values in Single JSON Array
When a claim is mapped with a user attribute, the mapped user directory attribute value is returned in claims if a user attribute mapping exists for the specified attribute. Multiple values in a claim are separated by the caret symbol (^). If you want to retrieve the multiple values in a single JSON array without the caret symbol (^), you can now prefix the attribute name with FMATTR:.
For information about the prefix, see Authorization Provider Dialog.
New ACO Parameters
 
CA Single Sign-On
 supports the following new ACO parameters:
 
Note
: The new ACO parameters require 
CA Access Gateway
 12.8.02 to function.
 
URITransform
 
Transforms a resource (URI) to an internal form that is more suitable for policy expression. This is a multi-value property that contains the expressions to perform URI transformation. The transformed URI is treated as a resource in the IsProtected call that triggers the realm access policy at Policy Server.
For information, see Resource Transformation.
 
MaxAuthorizationCacheSize
 and 
AuthorizationCacheTimeout
 
Controls the authentication and authorization of Agent caches independently, including a time-to-live setting that can supersede the existing realm-based timeout. This benefits by allowing tighter refresh limits on authorization versus authentication or by fully disabling the authorization cache.
For information, see Web Agent Caches.
 
OverlookSessionForQuery
 
Defines strings which can appear as substrings in the URL's query that ignore specific Ajax call requested by user based on the attributes in the query string.
For information, see Session Cookie Management.
Customize Tomcat Server in Logs
By default, 
CA Access Gateway
 displays the Tomcat Server information in the Response header using Server Header. You can now use the 
serverheader
 parameter in server.conf file to customize the Tomcat Server header in the logs.
For information, see Customize Tomcat Server.