Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > Authors Ravi Kumar Kanukollu

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:   firstname.lastname.DoJ@department.org.com’.  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 ‘lastname_firstname@dept.region.org.com

 

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.

 

@Override
 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.

 

Hi All,

 

Your input is valuable to us. I want to introduce the Customer validation program for our upcoming feature enhancement Office 365 IWA (Integrated Windows Authentication) feature within the upcoming CA SSO 12.52 SP1 CR04 release. We are adding support for IWA  which allows the end user a seamless login experience while using Office rich clients.  If you are interested to participate in the validation program, please register using the CA SSO - Office 365: Validation Opportunity.  Please check attachment for pre-requisites and more details about the feature.

 

 

We are running this program for limited time period which ends by 15-Nov-2015.  Acceptance mail will come to your registered mail based on the available slots in the validation program

 

 

Thanks & Regards

CA SSO - Product Management Team