Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > Authors Amin Pashapour

CA Single Sign-On

7 Posts authored by: Amin Pashapour Employee

Continuing the theme of programmatic interaction with CA SSO that we began in my last post, today I’ll talk about another great new feature in CA SSO 12.8: the JWT authentication scheme. The feature enhances programmatic interaction with CA SSO and its protection mechanisms, thus helping to create a modern software environment where APIs, JSON format and ID tokens run the show.


Before I get into how this new feature can be implemented in CA SSO, let me describe what JWT is and how it can be used in the world of SPA (single-page application) and API-based applications.


Some folks think JWT (JSON Web Token) is the hottest topic when it comes to authorization and single sign-on, especially for API-based applications. In its most basic form, JWT does what SMSESSION has done for over 25 years. Where JWT really shines is when it contains additional claims or user attributes. Just as SMSESSION was “tossed around” between applications as a cookie, JWT is tossed around as a header and does not need a domain dependency.


A JWT can be generated when a user is authenticated. For example, CA API Gateway, Google and many other entities can authenticate a user and generate a JWT, with or without additional claims.


A JWT contains three sections:

base64urlencode(header) + "." + base64urlencode(payload) + "." + base64urlencode(digitalsignature(header + payload))


Here’s a sample JWT from


When this JWT is decoded, it shows the three JSON sections:

  • HEADER (JOSE header):


  "alg": "HS256",

  "typ": "JWT"


  • PAYLOAD (Claims):


  "sub": "1234567890",

  "name": "John Doe",

  "iat": 1516239022




  base64UrlEncode(header) + "." +




Essentially, the new authscheme in CA SSO version 12.8 accepts a JWT, authorizes the user to access a protected resource and issues an SMSESSION token so it can be used by other applications protected by CA SSO. Setting it up is pretty straightforward. But before we go through the setup, you should know that this authscheme requires use of CA Access Gateway and public certificates for signature verification, since CA Access Gateway has the main application to capture and decipher the JWT. CA Access Gateway is also used for all other federation types of single sign-on, such as SAML and WS-Fed. This new feature just extends the existing capabilities even further.


Below is my simplified setup with CA SSO 12.8:



You can get your JWT by logging into your Google account or CA API Gateway. (Don’t forget to get the public certificates while you’re there!) Then, add your JWT as a header to access a protected resource, say “/jwt/” on CA Access Gateway (as below, where I use SoapUI).



Now that we know what JWT is and how it is used, let’s look at how we can configure it in CA SSO in a few simple steps:


1. Set up the certificates. Pay attention to the aliases you give your certificates when you import them, as they will come in quite handy later.


2.   Set up the authscheme. Notice the list of certificate aliases. If an alias is in the JOSE header, make sure you click that button. The most important part is the user lookup claim in the JWT; in most cases it is “sub,” but it could be email or whatnot.

The additional configuration items at the bottom reflect how secure you want the communications to be and what you want to do with the information. If you disable SMSession cookie generation, calls to other apps protected by CA SSO will require use of the JWT authscheme, where the apps need to present JWT for every single call. Persisting session variables will help with SSO in other protected realms.


One last thing: Once you have the authscheme, attach it to the realm protected by the CA Access Gateway agent:


There you have it—JWT Authentication Scheme in CA SSO. Questions? Comments? Please post them below or contact me at

As you may know, CA SSO has seen a lot of changes lately—the biggest being the move from a 32-bit to a 64-bit app, improving its performance across the board. Not only that: Many new features have been added to the 64-bit versions of SSO, starting with version 12.6, many of which let users more easily interact with CA SSO programmatically.


In my last blog post, I talked about using REST APIs to do migrations or upgrades programmatically. In this post, I’ll talk about one of the great new features in CA SSO 12.8: OpenID Connect. The feature enhances programmatic interaction with CA SSO, thus helping to create a modern software environment where APIs, JSON format and ID tokens run the show.


Here’s the simple setup for using this feature:

As you may know, the OpenID Connect provider feature was added in version 12.7; version 12.8 enhances this feature even more.


The first thing to do when using this feature is to define CA Access Gateway as your authorization provider, as shown below.



CA Access Gateway is the host for “Authorization Server Base URL.” When you create the azprovider, you can map your client’s chosen scopes to specific attributes from your user store.


Your next move is to establish the clients this server will work with. The most important elements in creating a client are the Client ID and Client Secret. These are auto-generated by CA SSO and need to be shared with the client. If you get errors when you try to generate IDs or secrets, make sure you have configured and enabled JCE.


Previous versions of CA SSO could do only Authorization Code Flow; version 12.8 can also do Implicit Flow and Refresh Token grant types. You can see all these features when you create an OpenID Connect client using the admin UI.



Additional scopes like email and givenName are visible, since azprovider defined them. In the above example, the client can ask for Authorization Code Flow with Refresh Token or Implicit Flow. For a good explanation of these flows, look at our documentation.


The main difference between Authorization Code Flows and Implicit Flows is that in Implicit, everything goes through the browser, so everything is visible to the world if you aren’t using HTTPS. That’s why you can’t configure Implicit Flow clients using http for the redirect URI.


When the client is set up with the right authorization provider, you can see all the good stuff for programming at the bottom:




These endpoints are what your applications/clients will use to interact with CA SSO for authorization, validation, revocation, etc.


Now that you have the OpenID Connect client set up with ID and Secret on the CA SSO side, you just need to set up the relying party with that information. The relying party can be any OpenID Connect clients, but since not all clients can handle various flows, great care should be taken when choosing such clients. In my lab, I used Apache OpenID Connect module. For example, my httpd.conf looked like this:



For a great example of how this setup can be extended for other partnerships, take a look at my colleague Mark O’Donohue’s post here.


There you have it—a primer on OpenID Connect. Questions? Comments? Contact me at

There was a time when Java applets were considered the greatest invention in computer science. That was back in the late 1990s, when applets managed SiteMinder (now CA SSO) access control policies. This arrangement was useful, but it had its limitations. Then along came newer versions of CA SSO, complete with the web-based admin UI application.


With the newest version of CA SSO, the environment is now 64-bit—much faster and more capable for agent-based and federation-based access control.


But the best part, for me anyway, is using REST APIs to administer the environment. Let me give you a quick tour.



Clicking on the link to REST APIs at the bottom of the admin UI screen gives us access to the admin UI Swagger interface. Once you authenticate, you have 15 minutes to make REST API calls for all sorts of CA SSO objects.



This interface shows you how to make API calls using CURL, which can be quite handy for many situations, including command line interactions. When you install the CA SSO SDK, you will also find Java-based SDK 64-bit samples. If you’re interested in what intrigues me the most, I've been looking into Policy Migration API and Core Policy Objects.  


Migration APIs have export and import endpoints that easily export domain-level objects such as realms, rules, responses and policies. For example, when using the Swagger interface, code like that below will export the whole webservices.domain and create a file named domain-export.xml.  For brevity, I’ve changed my token to $$:


curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/octet-stream' --header 'Authorization: Bearer $$ -d '{"mainObjectsMethod": "ADD","closureObjectsMethod": "ADD","passPhrase": "SomePassPhrase01","suggestedFileName": "domain-export.xml","objects": [{"path": "/SmDomains/webservices.domain"}]}' 'https://<my admin ui fqdn>:8443/ca/api/sso/services/policy/v1/deployment/export'


If you make the CURL call directly from the command line, the response will be the complete export in XML format. You can then feed the exported XML file as an input to another environment. Don’t forget to add the passphrase from export before the actual xml input.


curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Authorization: Bearer $$ -d 'SomePassPhrase01

<XPS><XPSVersion>1</XPSVersion><HostInformation></HostInformation><XPSAdmin>siteminder [SM://0004690d-ee9c-1851-ae9c-7a01c0a8487f/siteminder]</XPSAdmin>

     <PolicyData IsDumpExport="false">

                 <Object Class="CA.SM::AgentType" Xid="CA.SM::AgentType%4010-8d78bb96-ae15-11d1-9cdd-006008aac24b" CreatedDateTime="2016-12-15T01:31:12" ModifiedDateTime="2017-07-06T16:47:31" UpdatedBy="XPSDictionary::Import" UpdateMethod="Internal" ExportType="Add">


         <Object Class="CA.SM::Agent" Xid="CA.SM::Agent%4001-000cdc32-1a83-1a0b-a3de-b182c0a8cd7f" CreatedDateTime="2017-11-14T16:32:15" ModifiedDateTime="2017-11-14T16:32:15" UpdatedBy="My Admin" UpdateMethod="GUI" ExportType="Add"><Property Name="CA.SM::Agent.RealmHintAttrId"> <NumberValue>0</NumberValue></Property><Property Name="CA.SM::Agent.AgentTypeLink"><LinkValue> <XID>CA.SM::AgentType%4010-8d78bb96-ae15-11d1-9cdd-006008aac24b</XID> </LinkValue></Property><Property


Name="CA.SM::Agent.Name"><StringValue>throwaway.agent</StringValue></Property></Object></PolicyData> </XPS>' 'https:// <my admin ui fqdn>::8443/ca/api/sso/services/policy/v1/deployment/import'


As I said earlier, the SDK installation includes sample Java codes for export/import. In my Linux environment, I have it installed at /opt/CA/sdk127/samples64/restapi/basic


To build and run it, just

  • ./ [export, import, manage] -i for interactive admin username/password or use the file


For example:


./ export -ap https://localhost:8443/ca/api/sso/services/login/v1/token -ep https://localhost:8443/ca/api/sso/services/policy/v1/deployment/export -pphrase SomePassPhrase01 -file myoutput.xml –i


./ import -ap https://localhost:8443/ca/api/sso/services/login/v1/token -ep https:// localhost:8443/ca/api/sso/services/policy/v1/deployment/import -pphrase SomePassPhrase01 -file myoutput.xml –i


./ manage -ap https://localhost:8443/ca/api/sso/services/login/v1/token -ep https://localhost:8443/ca/api/sso/services/policy/v1 -i


The last call has some great examples of how to create, update and delete core objects like domains and policies.


As you can see above, these REST API calls can easily be used for migrating from one environment to another—for example, from Dev to QA and production environments. You can even version the files to keep track of objects being added/deleted/updated.


For one of my most recent CA SSO upgrade customers, I used APIs to make sure only selected objects were recreated and updated in the new environment, to prevent moving everything from distant years.


There you have it—a primer on using REST APIs to administer the CA SSO environment. Questions? Comments? Contact me at

In our final post on migrating to a CA SSO solution, we will present six things you need to keep in mind if you want to accelerate the project. There is no standard timeframe for implementation of CA SSO; the speed of implementation is dependent upon a wide range of factors. These factors especially impact implementation timelines:


  • Existing authentication(s): The number and type of authentication and session management mechanisms currently in place to protect web applications affects implementation complexity.
  • User stores: The number and type of existing user stores and migration and synchronization requirements affect project progress. 
  • Custom code requirements: Requirements related to custom authentication schemes, active responses and policies or advanced functionality not supported by the current product can have a negative impact on production timelines.
  • Availability of hardware: Long hardware lead times often have a negative impact on rapidly moving the implementation beyond the development phase.
  • Resource availability: If an organization cannot dedicate the enough resources to provide the necessary info for requirements gathering and help generate designs, the process will be prolonged.
  • Modifications to legacy applications: A company must have developers familiar with the applications being integrated into the architecture and be able to modify applications as necessary. Modifications to legacy applications are sometimes a large undertaking; if the applications aren’t ready when the solution infrastructure is available, the timeline will be affected negatively.


If you are interested in exploring CA SSO implementation options contact

Migrating applications is actually an onboarding exercise. You’ll need to define the resources that are protected for an application, assign agents or CA Access Gateway proxy rules, determine a login method for the applications and access rules, and map those rules to user roles and/or groups. Sometimes interim policies or login methods are employed during the parallel phase and disabled or discarded once the end state has been achieved.


Bill of Materials

For each application to be migrated, a bill of materials needs to be created to onboard the application to the new security infrastructure; for example:


  • Use cases to be covered for each application
  • Inventory of protected resources (URLs)
  • Inventory of current web agents involved
  • Authentication methods needed
  • Step-up flows
  • Authorization policies by URL grouping rule groups (for large number of applications, it can reach into 100s per group)
  • Response header requirements by rule grouping - response groups (some applications may get more headers than needed, but it makes operations a lot faster)
  • Admin users and roles/use cases
  • Federation requirements
  • Session timeout requirements
  • Session store and session customizations; e.g., storage and retrieval of session-specific data outside of standard supported ones/user store schema elements for a session
  • Session assurance feature, if needed, and which URLs will need it

Once the bill of materials is created, mapping to configurations needs to occur to accomplish migration of functionality specific to the target application(s).


Prioritization of applications to be migrated can be based on a number of factors. To mitigate risk, migration can begin with simpler low-profile applications and graduate to more complex higher-profile applications.


In all strategies, URL schemes are critical criteria for isolating change scope. Common approaches include:

Migrating application by application:

  • Select application(s) protected by a set/cluster of related web servers.
  • Limit scope further by migrating one set of URL schemes.
  • Partitioning by domain name might be possible based on URL/domain hosting strategies used in current applications.

The fallback strategy becomes easier if web server/CA SSO agents are deployed in parallel and Layer 4 load balancer is used to graduate applications into production.


Migrating by business unit:

  • All applications servicing a business unit may be migrated in one phase.
  • Business units with smaller footprints could be targeted first.


Migrating by user-specific communities (e.g., new net benefits users, technical users or accounting users):

  • Migrating smaller audiences at one time contains the change impact to a smaller portion of the user population.


For all strategies, change management plans that cover business processes, technology, communications, operations and training of involved constituencies are required for optimal adoption.


Identifying Pilot Applications

Identifying the pilot applications to be on-boarded is crucial to ensuring a quick win and laying the foundation for successful long-term expansion of the solution.


The two most common approaches for a pilot are:

  • User communities: Build a solid single sign-on infrastructure and slowly expose the infrastructure to a single user community. Historically, the most common starting point has been internal users, then expanding to partners and finally customers/Internet users. 
  • Key web application/site: A key revenue-generating or cost-saving initiative, such as an e-commerce application, partner extranet, or employee intranet, often drives the need for a web single sign-on solution. Starting here can be effective, as it accomplishes a key business initiative while establishing technical requirements and a central security framework for the larger implementation. 


If you are interested in exploring CA SSO implementation options contact

And watch for my next post, where Six Considerations for Accelerating a CA SSO Implementation.

Now that we have evaluated the existing solution, mapped requirements and performed a gap analysis as described in my first post, Factors to Consider When Pondering a New Single Sign-On Solution, you’ll want to make sure that the solution has the best possible chance of adoption—and success. This post shares some of leading practices for SSO migrations.

Here’s a simplified reference architecture to build out the new solution:



With the latest version of CA SSO, administration tasks can be done using REST API calls. Also, new capabilities of CA SSO include REST API-based Authentication and Authorization as well as being an OpenID Provider.


Develop Co-Existence Strategy


Almost all enterprises have some form of Single Sign-On services. Will you need to support single sign-on in the interim between the “legacy” solution and CA SSO? The answer to this question will determine how the two worlds will co-exist during the parallel migration period.


If there is no need for session sharing between the two solutions, users can log in to each environment independently and use applications protected by each solution; however, users will need to authenticate multiple times—a less than optimum experience. It’s not surprising that this option is rarely chosen.


The more likely scenario is some form of single sign-on while applications are being migrated to CA SSO.  This could take one of a few forms: federation using SAML, dual protection, or single protection. 


Co-Existence Method


Federation with SAML

One of the environments acts as the identity provider while the other is the service provider. To minimize changes to the legacy environment, it typically acts as the identity provider.


·         Applications are protected by only one solution—legacy or CA SSO.

·         Apps protected by CA SSO use a SAML authentication method to leverage the legacy session or login methods.

·         If a user spends a long time in one legacy session, the other session may expire due to inactivity, forcing a login.

·         Once all applications are migrated to CA SSO, login methods can be changed to non-SAML.

Dual Protection

Both the legacy and CA SSO environments protect all applications. This usually means the legacy agent/web gate and the CA SSO agent/CA Access Gateway are configured to protect each application. Initially, the CA SSO policies are very basic and enforce SMSESSION (CA SSO session management cookie) validation and refreshes. The legacy policies enforce access control.


·         Login processes are customized to generate legacy and CA SSO sessions, such as use of login servers with redirects.

·         Policies equivalent to legacy policies are migrated to CA SSO.

·         Once all policies exist in CA SSO, legacy agents can be removed. Login can switch over to CA SSO login methods.

·         Both sessions are maintained during application access.

Single Protection

The legacy and CA SSO environments protect different sets of applications. This usually means that an application is protected by the legacy agent/WebGate or the CA SSO agent/CA Access Gateway, not both. 

·         Login is customized to generate both legacy and CA SSO sessions.

·         Session timeouts create challenges if a user spends a long time in one session. The other session may expire due to inactivity and force a login.


The method(s) you choose will depend on the capabilities of the legacy environment.  If there is no federation support, SAML or OpenID methods are not an option. Understanding the requirements will help make some of these decisions easier.


If you are interested in exploring CA SSO implementation options contact

And watch for my next post, where I will discuss optimizing your CA SSO migration.

Is your organization considering a new single sign-on solution? Before you do anything, you may want to read this guide to successful migrations. The first topic we’ll handle are the preliminary steps you should take to determine if the migration is the right move for your organization.


A well thought-out strategy for migrating to CA Single Sign On (CA SSO) from another access management solution reaps several benefits:

  • A seamless user experience
  • Minimal to no disruption to user activity
  • Low risk
  • An accelerated pace of migration that delivers quick wins.


Of course, a well thought-out strategy requires effective planning. What considerations do we need to take into account? We’ve been involved in countless CA SSO migrations over the years, and we’ll share our leading practices with you here. One caveat, though, before you use this as the guide to end all guides: Your organization’s environment has unique variables that must be factored in before performing this migration.


Here’s a general view of the process:

  • Evaluate the existing solution
  • Map requirements and perform gap analysis
  • Build out the new solution
  • Develop co-existence strategy
  • Develop and execute application migration strategy


Step #1: Evaluate the Existing Solution

You can glean a lot of information from the current solution: existing requirements, login methods, authentication and authorization load, and audit reporting.  Discovery elements include:

  • Evaluate the solution design documentation
  • Interview stakeholders, application owners and users, and security administrators
  • Understand average and peak transaction volumes for logins and authorizations for sizing the new solution
  • Analyze existing application protection needs:
    • Login methods
    • Coarse- or fine-grained authorization
    • Roles, group memberships, or user attribute values needed for valid access
    • Data needed by application in cookies, headers, etc.
  • Current processes for on boarding applications


Step #2: Map Requirements and Perform Gap Analysis

This phase maps solution requirements and use cases to out-of-the-box (OOTB) features of CA SSO. (A few use cases will be beyond the scope of CA SSO’s OOTB capabilities.)


Here’s a sample mapping table:

Use Case Number





User login


Uses uid attribute from LDAP directory


User logout


Specified in Agent Configuration Object


Cross-session validation


Java SDK and CA SDK needed


Multi-factor authentication using mobile OTP


Requires integration with CA Advanced Authentication

Existing policies or protection schemes can also be analyzed to generate requirements for protecting each application when using CA SSO. These requirements can be used to create policy definitions:

  • Application resources to be protected (path, URI, etc.)
  • Web server(s) hosting application
  • Authentication method required for user identification (login form, multi-factor, certificate, token, windows session, etc.)
  • Authorization method for validating user entitlements, group membership, user attribute values, etc.
  • Special considerations in determining user access—network location, time of day or week, etc.
  • Policy server
  • Data stores: policy store, user store(s)
  • CA Access Gateway and/or web agents
  • Administrative UI server


All this information is mapped into equivalent configurations on the CA SSO side.


If these first two steps tell you that your organization will benefit from a new single sign-on solution, I hope you’ll read my next post highlighting co-existence and build out of the new environment, which will be available next week.