Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > 2017 > May

Part 2 - Why you Care

In OAuth 2.0, OpenID Connect and JWT – What are they and why do you care? - Pt1  We gave a description of what OAuth and OpenID Connect are and how they work.


So all that is great, but why do we care when we already have SAML 2.0 assertions and existing cookie based session tokens like SMSESSION?

We care because OAuth, OpenID Connect, and JWT provide an enhanced ability to tie the new breed of applications together in a more logical and flexible manner. The rest of this blog post will show those scenarios, describe the current limitations, and how OAuth and OpenID Connect can solve the use case in an easier and more natural manner.


Once again, please note that none of this should be taken as official product commitment. For that please talk to Product Management.


Mobile Applications

Mobile applications fit into two basic categories. The first is a fully native application. This application’s user interface is written solely for the mobile device. It communicates with the outside world via API’s. While it may have an embedded HTTPClient for making REST calls there is no direct user interaction with any web resources.

This presents two issues for mobile applications.


The first is authentication. The mobile application will want to gather user credentials through its own UI. It will either store them for re-use, or will prompt for them each time it needs to authenticate the user with the external system.

Since it is submitting inline credentials it does not want to deal with redirects. While it’s certainly possible to write authentication schemes for WAM that accept inline credentials, OAuth has simplified and standardized this. RFC 7523 defines an OAuth 2.0 profile where a trusted client can POST a JWT token to the Authorization Server and directly receive back an access token.


This profile is similar in many ways to SAML 2.0 in that the client is registered with the Authorization Server and has signed the JWT request token. As such the Authorization Server “trusts” the identity in the JWT token and does not require actual user credentials such as a password.


So our mobile friendly flow looks like:

blog pt 2 pict1.jpg


Single Page Apps / Hybrid mobile Apps

To the Resource Servers and WAM systems protecting them, Single Page Apps and Hybrid mobile applications look very similar from an authentication and authorization standpoint.

Both cases typically mix browser based authentication and web based content access with REST calls. They are both effectively mashups that want to operate with a consistent identity and authorization context.


The external authentication problem is minimized by virtue of being able to leverage a browser. However trying to maintain a consistent session across a multi-domain set of content providers and REST services becomes an enormous problem with cookie based session tokens which are associated to web domains and very difficult for 3rd parties to validate without WAM specific code.


So if the client application wants to present a consistent session token to multiple web based and REST based Resource Servers what is the solution?

The solution is to leverage JWT and make the WAM systems a bit smarter. A legacy security token can be an entry in a JWT based access token. WAM policy enforcement points can first look for a JWT access token in an authorization header. They can then retrieve the legacy security token from the JWT token and using it as always for authorization decisions.

This allows existing WAM products to become much friendlier to SPA’s and Hybrid mobile apps.


The following diagram illustrates the flow:

blog pt 2 pict2.jpg


Consuming External Identities

The beauty of what we have been describing is that all the token exchanges and token formats are standardized. These are really lightweight federated trust relationships. Applications and Resource Servers should be able to be used in multiple environments, getting identities from different OAuth Authorization Servers.

So what happens if a client application wants to be able to use external and internally generated identities to access the same set of Resource Servers?


The first option is for the resources servers to get smarter. If information about the issuer is present in the access token the Resource Server can have a table of signing keys, UserInfo, and Token Validation endpoints associated with each issuer. This is similar to the way SAML SP’s typically accept identities from multiple SAML IDPS’s.

However we want this to be easier for implementers of clients and Resource Servers.


The solution here appears to be in the form of a draft IETF proposal for a REST based OAuth 2.0 token exchange – “OAuth 2.0 Token Exchange: An STS for the REST of Us” -

With this capability a client can obtain an access and ID token from any external identity provider that is supported by the organization and exchange them via REST for token(s) issued by the corporate Authorization Server. This means the Resource Servers only need to trust, and be configured for, a single Authorization Server.


Here is a diagram that shows that exchange:

blog pt 2 pict3.jpg

The protocol is also useful when you have a chain of resource servers. A resource server can also be a client of the Authorization Server, present its access token, and request an access token for the next resource server in the chain. This provides an authorization check at each point in the chain and prevents the issuance of overly broad access tokens.


Here is a diagram that shows that exchange:

blog pt 2 pict4.jpg


Wrap up and Emerging Directions

So what you have seen is how OAuth and OpenID Connect provide a flexible way for mobile and Single Page Applications to easily authenticate a user and get standards based access and identity tokens.

These tokens can then be used to access both traditional web resources as well as REST services.  The standardized nature of the tokens, including their issuance and validation means that applications and systems are not required to use proprietary API’s. This open approach is compelling to both new and existing customers.


So with all of these improvements, what’s left? Well a couple of things.

More closely tying the Resource Server and the Authorization Server together. Different API’s and different resources logically require different sets of claims to access. Currently there is no prescribed mechanism for this linkage, except via the client’s knowledge of the needs of each Resource Server.


User Managed Access or UMA is addressing this need. UMA is a profile on top of OAuth that introduces new endpoints that allow a Resource Server to register resource sets and associated scopes with the Authorization Server. The Authorization Server can then use those scopes to make authorization decisions before granting an access token. The Resource Server may also dynamically request additional scopes from the Authorization Server in order to perform a step-up authentication, or privilege escalation.


The last items to cover are impersonation and delegation. Bearer tokens are useful, but many people want better control over delegated tokens, including who can request them, where they can be used, time of use restrictions, etc.

The draft OAuth token exchange spec mentioned above - adds additional grant types to the OAuth token endpoint for requesters to request a token with a 3rd party subject for impersonation. For delegation what is known as a composite token can be requested. A composite token includes information about both the subject delegating authority, as well as the subject requesting the delegation token. This will feel familiar to people who have been around long enough to remember WS-Trust ActAs and OnBehalfOf request elements.


I hope this overview has been helpful showing the promise of these technologies.  We still feel we have lots to learn and want to hear from customer. If you have thoughts or comments please feel free to leave them here.


Web Agent configuration wizard fails to detect all the OHS instances


Web Agent Version : r12.51 until CR8, r12.52SP1 until CR4
OS : Windows


This issue happens when the OHS instances are customized and installed outside of the default <ORACLE_HOME>\instances directory.

Here is how web agent currently determines the location of the instances.

  1. Read the path of the ORACLE_HOME by looking at all the keys under "HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE" registry.
  2. Then look for instances under <ORACLE_HOME>\instances folder ( for 11g release). (To identify correct ORACLE_HOME it also checks for couple of other files/folders)




"inst_loc"="C:\\Program Files\\Oracle\\Inventory"





"ORACLE_GROUP_NAME"="Oracle - OH582528179"







Now, this is all good if the OHS instances are installed using default installation. However, if the instances are customized and installed outside of this default location web agent configuration wizard fails to detect it.



Option 1 : Configure Web Agent Manually :


Option 2 : Reconfigure OHS and install the instances in the default location and re-run Web Agent configuration wizard.


Resolution : 


This issue has been fixed in following version : r12.52SP1C5 and above.

Each OHS instances contains a service and each service contains a direct path to the instance directory.


So, now instead of looking up the <ORACLE_HOME>\instances folder web agent configuration wizard directly get the instance path from it's service description.




Additional Information



In this guide we will see how to configure CA SSO to overcome the challenges associated with Web 2.0 websites.


Web 2.0 websites allows users to do more than just retrieve static content from the server.

It does this by running script engine in the context of the browser.



Examples of Web 2.0 technologies :

  • Ajax
  • Silverlight
  • Adobe Flex
  • Java Web Start


Challenges with CA SSO for the Web 2.0 support :

  • It expects response in the certain format. It doesn't understand CA SSO challenges and authentication redirects.
  • The regular polling can prevent idle timeout expiration.
  • It may support HTTP methods other than the usual Get/POST



  • Policy Server : R12.52+
  • Web Server : Apache 
  • Web Server OS : Linux 
  • Web Agent : 12.51 CR3


Instructions (summary):


1) Configure any of the following ACO parameter (as applicable) to identify Web 2.0 resources and as such prevent their access from creating/updating session cookies.

  • OverlookSessionForMethods
  • OverlookSessionForUrls
  • OverlookSessionAsPattern


2) Configure WebAppClientResponse ACO parameter to identify Web 2.0 resources and configure customized response to integrate CA Single Sign-On generated behavior (e.g. challenge/idle time out /maximum time out etc) , with the functionality of the web application client.


3) Configure the web application to handle a custom response returned by CA SSO.


Instructions (Detailed):


Configure Web Server

To demonstrate CA SSO support to  Web 2.0 application , we will deploy the sample Ajax application (attached) on our web server and make necessary changes to protect it.


  1. Deploy the application as below (either jQuery or XmlHttpRequest sample) :
  2. Configure /var/www/cgi-bin/ as ScriptAlias (refer to attached httpd.conf)
  3. Configure /var/www/html as DocumentRoot (refer to attached httpd.conf)
  4. Test the sample perl script ( and ensure it's working
  5. Access the Ajax web site directly and ensure it's workinghttp://<fqdn>/home/ajax.html


Configure CA SSO Policy Server

  1. Protect resources /cgi-bin/ & /ajax/. Leave /home/ unprotected.
  2. Configure OverlookSessionForUrls ACO parameter to identify /cgi-bin/ as Ajax resource. This will prevent Session cookie creation/update while accessing this resource, effectively allowing the user session to idle time out.    
  3. Configure WebAppClientResponse ACO parameter to identify Ajax resources and configure customized response                             


    Note : Ensure that the Body points the absolute location of the customized response XML file on the web server. This custom response file can be customized to include any other additional details, but at minimum it must include:
  4. Configure MaxTimeOutURL & IdleTimeoutURL ACO parameters
  5. Configure Session Idle/Max Timeout as required.For this demonstration we will keep it as following :IdleTimeout = 1 Minute, MaximumTimeout =2 Minutes
  6. Configure Web 2.0 application to handle all CA SSO custom responses. For e.g as you can see below, in the sample application (ajax.html) , if CA SSO returns the reason as MaximumTimeout or IdleTimeout, it reads the redirectURL returned and redirects to it if it's not empty otherwise , it redirects to the home page. In case of Challenge , as CA SSO doesn't return any redirectURL , it then redirects directly to the home page.
  7. else if ((reason == "MaximumTimeout") || (reason == "IdleTimeout")) {
    var alertMessage;
    alertMessage = "reason(from policy server): " + reason;
    alertMessage += "\nredirectURL(from policy server): ";
    alertMessage += redirectURL;
    if (redirectURL == "") {
    redirectURL = "/home/home.html";
    alertMessage += "\nyou will now be redirected to: ";
    alertMessage += redirectURL;
    redirectURL += "?reason=" + reason;
    document.location = redirectURL;
    else if (reason == "Challenge")
    redirectURL = "/home/home.html";
    document.location = redirectURL;




Use Case 1 : Challenge

In this use case we will access the ajax resource which is protected by CA SSO but without having SMSESSION already in the browser.

So access : http://<FQDN>/home/ajax.html

As you can see, as the browser currently doesn't contain the SMSESSION, it receives the customized response from Web Agent with :

  • Reason: Challenge
  • RedirectUrl : <empty>

Now, as the Ajax application is configured to redirect to home page under this condition, it redirects accordingly.


Use Case 2 : Idle Timeout

In this use case, we first login to the application by accessing protected resource.

Then, keep running the Ajax application until the idle time out (1 minute or as configured)

After the idle time out, CA SSO send the response as :

  • Reason: IdleTimeout
  • RedirectUrl : IdleTimeoutURL if configured otherwise blank

Ajax application then redirects as directed.





Use Case 3 : Maximum Timeout

In this use case, we first login to the application by accessing protected resource.

Then, pause the Ajax application (by not clicking OK on the popup window) , until the maximum time out is expired.

After the maximum time out, CA SSO send the response as :

  • Reason: MaximumTimeout
  • RedirectUrl : MaximumTimeOutURL if configured otherwise blank

Ajax application then redirects as directed.




It's very common for web server/browser to cache the html/ajax resources. Caching can lead to many unexpected results. So you will need ensure that the Ajax container page (ajax.html) and the ajax response itself are never cached.

In the sample application we have achieved this by appending the random query parameter based on the system time to the Ajax request ( as well as for the page containing the ajax script (ajax.html)


// Fire a GET request to using the xmlhttp object. This
// would fetch the system time and would return it back to this application
// as an HTML'GET', "/cgi-bin/"+new Date().getTime(), false);


<center><B>I am protected Resource. SMSESSION is now created.</B></center>
<center><a href="/home/ajax.html" onClick="this.href=this.href.split('?')[0]+'?'+new Date().getTime()">Please click to open Ajax Page.</a></center>



Update 22/5/2017 : The XmlHttpRequest sample does work only in Internet Explorer. Firefox and Chrome browser doesn't seem to support it anymore. So, rewrote the Web 2.0 sample app using jQuery which has been verified to be working in IE/FF/Chrome. Depending on what browser you intend to test with, choose appropriate sample.



In this guide we will discuss about the steps required to integrate CA Single Sign-On with CA Advanced Authentication (CA Arcot WebFort Strong authentication & CA Arcot RiskFort ).


We use CA Arcot Adapter™ (Adapter) to integrate CA Single Sign-On with an on–premise implementation of the CA Arcot WebFort strong authentication solution and the CA Arcot RiskFort adaptive authentication solution.


The following diagram illustrates how the Adapter and its components, CA Arcot RiskFort, and CA Arcot WebFort integrate in a CA Single Sign-On environment. 


Graphic showing the CA SiteMinder and CA Arcot integration architecture



  • Policy Server : R12.52 SP1, R12.52SP2
  • OS : Windows
  • CA Advanced Authentication : 8.2.1
  • User Store : CA Directory (LDAP)



  • CA Strong Authentication and CA Risk Authentication servers are installed and configured.
  • CA Arcot Adapter and all related components (AFM, State Manager etc. ) are all installed and configured.
  • CA SSO Policy server and Web Agents are installed and configured.
  • All CA Single Sign-On users to which the integration applies must be made available to the CA Strong Authentication database


Configuration Steps - (summary)

Here are the high level overview of the steps required to configure this integration :


CA Adapter

  • Create a CA Adapter profile of integration type - SiteMinder. 

CA Single Sign-on Web Agent 

  • Configure virtual directory and deploy FCC pages

CA Single Sign-on Policy Server

  • Deploy Authentication Shim Libraries
  • Copy Adapter configuration file (adaptershim.ini) from CA Adapter host
  • Create Arcot Authentication scheme utilising Authentication Shim Libraries
  • Ensure the ACO used by web agent has the required parameter set


Configuration Steps - (detail)


CA Adapter

Create a CA Adapter profile of integration type - SiteMinder.


Open CA Adapter configuration wizard ( http://<hostname>:<port>/ArcotAFMWizard/afm_profile_wizard.jsp )

Click Create New Profile

Specify following : 

Profile Name = casso (this field is case sensitive),

Integration Type = SiteMinder (mandatory)

Primary Integration Type = LDAP

Strong Authentcation Organization Name = Pre-configured Organization which is mapped to an enterprise LDAP directory.

Note:  This must be the same LDAP directory as configured in CA SSO Policy server.

Click Next.

Select option to invoke Second Factor Authentication "Without Risk" and leave the remaining configuration as default and click Next



Select Security Questions options for Second Factor Authentication and leave everything as default and Click Update


This will redirect to the home screen as below :

Now, Click Next to configure the Strong Authentication server details and also to save the new Adapter profile.

Click Next and update the CA UDS Configuration

Click Next and update the CA State Manager configuration 

Click Next and update the SiteMinder Web Agent & CA Adapter Applicaiton server details 

Note :

Please make a note of the FCC Virtual Directory name configured here, as this needs to match the name of the virtual directory which will be configured in the Web Agent later in the subsequent step.


Click Next and leave the default setting for SAML Request Verification


Click Next

Verify the configuration and finally click Save to save the configuration.

The configurations is saved into a file adaptershim.ini located at <AFM_HOME>/conf/afm folder.


CA Single Sign-on Web Agent 


Copy the complete FCC folder available at <ARCOT_HOME>/adapterSiteminder/fcc to the Web Agent host.

Create a virtual directory in the Web Server that points to the FCC directory that you copied.

Note : The virtual directory alias need to match the virtual directory name configured during Adapter configruation wizard.


CA Single Sign-on Policy Server

  • Deploy Authentication Shim Libraries

The files to deploy for Authentication Shim are available at the following location:

<CA Strong Authentication Install Image>/GEN02175329E/CA-Adapter/CA-Adapter-8.2.1-Windows/32bit-adapterSiteMinder

Copy the ArcotSiteMinderAdapter.dll and ArcotLog2FileSC.dll files to <Policy Server Install>/bin folder




File with the same names are also deployed under following location :


However, these are 64 bit version of libraries , so are NOT compatible with the 32 bit Policy server for 12.52SP1 & 12.52 SP2 release. CA SSO Policy server is 64 bit process only from 12.6 onwards.

  • Copy Adapter configuration file (adaptershim.ini) from CA Adapter 

Copy adaptershim.ini from AFM_HOME/conf/afm folder to the following location on the system where CA Single Sign-On Policy Server is hosted: <ARCOT_HOME>/conf


Note :

In CA SSO 12.52 SP1 and 12.52 SP2 , <ARCOT_HOME> environment variable points to <PS_Install>/aas folder by default.

  • Create Arcot Authentication scheme utilising Authentication Shim Libraries

Create a Custom Template authentication scheme and enter following details and click submit:

Library = ArcotSiteMinderAdapter

Parameter = Name of the Adapter profile you created using Adapter configuration wizard (this field is case-sensitive)


  • Ensure that ACO used by the web agent has following set :

FCCCompatMode Yes

RequireCookies Yes

CssChecking Yes

  • Configure Realm to be protected with the Arcot Authentication scheme created above

  • Restart Policy server (This is needed for the policy server to load the new Authentication shim libraries)



  • Access the resource protected by Arcot authentication scheme. 
  • The user shall be prompted for authentication by CA Strong Authentication

  • For the first time , if the user is not already enrolled with CA Strong Authentication it will be prompted for enrolment and register the Question and Answers

  • User is then prompted to select the security option as below.


  • Finally the user is granted the access to the protected resource.


Now, if the same user tries to authenticate the second time here is the sample flow :


  • Access the resource protected by Arcot authentication scheme. 


  • Sample adapthershim.ini file
  • Sample fiddler trace (for second use case)





So far, my posts have covered various aspects of non-policy-based SSO. Today, I’ll share a real-world example of non-policy-based SSO in action at a CA Technologies customer, one I consider a visionary pioneer in digital transformation. One proof point for my opinion is that the company embarked on its digital transformation journey more than eight years ago, well ahead of most other organizations.


While the user experience was the cornerstone of this digital transformation, security and release management were also top of mind for the company. It all started with an idea to provide SSO for an IApp while simultaneously decoupling the IApp from SSO policy. As you know, SSO policy requires a policy enforcement point (PEP), which is typically an SSO agent. The question became how to ensure session security without a policy-based SSO and its attendant PEP.


As we developed non-policy-based SSO, we came to see that it was a blessing in disguise—and that it can be the same for other organizations. It forced everyone to think differently and beyond just user experience. Energized by cross-pollination of teams and collaboration, we knew we were onto something bigger than just SSO. We were building and living what the industry now calls digital transformation, essentially DevOps and Agile. In this case, business was the driver, and non-policy-based SSO was the transformer.


Like the pioneers of old, we transformed the company’s landscape. We set up camp by building a completely new, modern user registration and sign-on process that simplified the user experience. We accomplished this by integrating CA SSO and CA Identity Manager with the company’s IApps. SSO allows seamless, secure navigation across the company’s web applications for its consumers, partners and employees. Even minor interface design elements, such as validating authentication codes, were held to the highest user experience standards and provide the right balance to the underlying development and operations effort. To improve business availability, we eliminated dependencies between release sprints and operations for runtime deployments, with no change in security posture.


Because SSO without session security is worthless—even dangerous—the customer, CA and IBM collaborated on building a strategy to ensure session security at all integration layers. CA and IBM enhanced their products to help our customer achieve success in its business initiative. The customer’s IApp developers worked closely with CA Services to:

  • Build an in-line web session filter to validate SSO tokens.
  • Update IApp login modules that call SSO to obtain SSO tokens.
  • Ensure that an IApp server session is generated and updated based on an SSO token and the user’s type of access.


If your organization needs assistance with its digital transformation, non-policy-based SSO may be the transformer you’re seeking. With CA SSO, an enterprise infrastructure product, you can enable centralized, secure web access management, user authentication, single sign-on, policy-based authorization and identity federation. Please comment on this post if your organization is undergoing a digital transformation—or if you have any observations you’d like to make.