Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > 2019 > January

In the world of digital technology, with rapid transformation of technologies supporting various business functions, you deal with disparate applications posing a variety of challenges. One such challenge of paramount importance is "Providing seamless access to users with uncompromised security".


What you are finding as you introduce more SaaS applications and partner applications into your topology is that each application requires user attributes in a precise format, unfortunately, is not in the same format as they exist in your user store.   You feel an identity headache coming on. The last thing you want to do is start introducing application-specific attribute schemas into your user stores.  Where would that problem end?


To help you avoid this headache and the associated cost of application-specific attribute proliferation, this article provides details about how you can customize the claim (attribute) formats in OIDC ID tokens produced by CA SSO.  This capability has been available for SAML assertions issued by CA SSO, but with the 12.8.02 release of CA SSO this customization capability is extended to OIDC


CA SSO OIDC Provider generates user claims as part of an ID token and a User info response to OIDC client applications.  Your OIDC client applications use both of these claim sources in order to authorize the user to access specific resources. 


Let’s see how this works by looking at an example. One of your client applications is looking for a user attribute in this format:’.  The client application requires this type of user attribute value to map the user to the desired resource in order to grant access to users.   Perhaps, this format does not exist in your user store.   Instead, your user store has separate attributes firstname, lastname, DoJ and department.   To address the application’s requirement, you would need to update the user store with a new attribute in a format combining of all of these attributes. Tomorrow, some other application would ask you to provide the claim in a different format like ‘


To address these types of scenarios, a custom plugin in the OIDC Provider provides a flexible mid-flight method to customize attributes to the specific format expected by your client applications.


In the below diagram, a user tries to access SaaS applications AWS and Salesforce. Both applications expect the DoB claim in a different format.  CA SSO builds the ID token claims from a single user store.  The plugin in the CA SSO OIDC Provider supports customization of the DOB claim to the specific format that is expected by AWS and Salesforce applications.



Various other use cases for customizing claims to be carried by an OIDC ID token can be addressed by CA SSO’s OIDC Provider. For example, if you don’t want to share some claims or if you want to add a specific claim that is not available in the user store, those cases also can be  achieved with CA SSO’s OIDC Provider.  Another common use case is the need to share the same ID token with multiple OIDC client applications.  In this case, the ID token can be adjusted to add the multiple audiences with the client names on top of the default client id.


The code snippet below shows how to add a new claim which does not exist in the user store. The default ID token is modified with the new claim, ‘amr’, which may be a requirement for a client application.


 public Map<String, Object> customizeClaims(APIContext apiContext, String params, Map<String, Object> origClaims) throws PluginException {
    Map<String, Object> customClaims = new HashMap<>();
    customClaims.put("amr", "pwd");
    return customClaims;



The main message here is…without changing the attribute schema in your user repository for every OIDC client application let CA SSO execute the necessary transformation (the mid-flight adjustment) saving you time, money, and the above-mentioned headache.  Your application team can focus on building their business logic and let you to manage the user attributes using CA SSO OIDC Provider to address their requirement and give your users a smooth access experience!


CA SSO OIDC Provider is ready for your team to onboard applications quickly and cost effectively.


DevOps has become a widespread practice not just to continuously integrate software in a more automated way, but it has evolved towards more continuous delivery in production. REST APIs are key enablers of these workflows in DevOps by helping with the required automations to save cost and drive agility.


In 12.7, We introduced REST APIs for Policy Object administration which allows you to create, read, update, and delete objects including SAML 2.0 federation entities and partnerships, and certificate services in the policy store.

With the support of REST APIs provided in 12.7 onwards, it is possible to automate common administration tasks that are typically done using CA Single Sign-On Administrative UI interactively. You can script the entire operation, completely avoiding manual intervention and saving time.

For example, if you had to edit a partnership manually in the UI today, you would have to navigate to the required screen sequentially and then edit it. But the same with a REST API is very straightforward and simple. Basically, it accelerates the procedure and saves a lot of time.


The REST APIs and the REST API interactive reference documentation are available from any server hosting the CA Single Sign-On Administrative UI. The REST API interactive reference documentation provides an overview of the CA Single Sign-On REST APIs. For detailed information from which you can visualize and interact with the API resources, access the REST API interactive reference documentation in the following location:




You can also open the interactive reference documentation by clicking the REST APIs link at the bottom of the Administrative UI.



CA Single Sign-On provides the following REST APIs:


Administrative Token API (/ca/api/sso/services/login/v1/token)
This API needs to be used to retrieve a JWT token containing a session ticket.

Policy Data API (/ca/api/sso/services/policy/v1/...)
The Policy Data API allows you to create, read, update, and delete CA Single Sign-On objects in your policy store.
Each call to the Policy Data API requires a valid JWT Token obtained from the Administrative Token API as a Bearer

Token in the Authorization header.

Policy Migration API (/ca/api/sso/services/policy/v1/deployment/...)
The Policy Migration API allows you to export and import specified subsets of policy data in the policy store.


Highlighted below is the Policy Data API section for Federation Objects. Under this section, you will find all the APIs, you need to create, delete, update and manage SAML 2.0 federation partnerships. 



For instance, the below API lists operations for managing IDP partnership.



Further, clicking on each of these operations, will reveal the payloads and responses with an example. You can also execute the APIs here by clicking on “Try it out!”.




To reiterate, these Administrative REST APIs allow for tighter integration into existing DevOps processes in your enterprise and help in automation of common administrative operations.


For instance, you could use them in the following scenarios


Scenario 1: - Your enterprise may have internal federations, SaaS federations, 1 to 1 federation with partners. In all these cases, a great idea would be to create payloads which are “standard configurations” for each of these category of federation partnerships and save these payloads as templates.

The next time, you need to create a partnership, you could reuse these templates by changing only the minimum number of parameters and use the modified payloads via REST APIs to create new ones, thus saving a lot of time!


Scenario 2: - Migrating an SP/IDP partnership from a staging dev environment to production

These APIs also can be used when migrating an SP/IDP partnership from a staging dev environment into production, thus simplifying the migration process.  


Scenario 3: - Updating an existing partnership is also very easy with REST APIs.

For details on using all the APIs and payloads, refer to our technical publications or REST API interactive reference documentation.


Also, we will continue to expand these functionalities to cover OpenID Connect federations. I will update this post once the REST APIs for OpenID Connect makes it into validation builds. Stay tuned for more!