CA SSO: On-Premise or Cloud? Now you can do both!

Image courtesy of CA Technologies

Image courtesy of CA Technologies


The entire CoreBlox team was excited about the announcement that the latest CA Single Sign-On release (R12.6.02) includes integration with CA Identity Service!  I had a chance to see CA Identity Service in action at CA World last November. As impressive as it was as a standalone solution,  I think everyone knew that it would go to another level once it could work hand in hand with CA SSO. This announcement is a major step forward for CA, as companies that are already running CA SSO can now transition to a true hybrid cloud environment by pairing with CA IDaaS. Got Salesforce? Dropbox? Google G Suite? Office 365? No problem.  Your existing CA SSO users can now seamlessly transition from their on-prem apps to their cloud/SaaS apps with a single click.

Step-By-Step: CA SSO WebAgent Request Flow

Photo credit: Dean Hochman, via Flickr

Photo credit: Dean Hochman, via Flickr

When a user opens a new browser session and navigates to a CA SSO protected resource, the Agent intercepts the request at the webserver end where the protected resource resides. At the Agent end there are different Managers that each perform different actions. The following describes the flow:

1.     To start, the HighLevelAgent (HLA) passes the request to the Resource Manager. It is the responsibility of the Resource Manager to extract information about the requested resource such as HTTP_Host, Client IP address, Agent Name, URL, Method (Get, Post etc), Cookie Domain. Furthermore, it does some checks such as CSSChecking, BadURLChars, AutoAUthorize URL etc.

2.     Next comes the Session Manager. Since there is no session established yet, the Session Manager will return no action.

3.     At this point the Protection Manager is called. Now the agent, via the Low Level Agent (LLA), makes a TCP/IP connection to the Policy Server. The Policy Server, based on the Agent name and resource URL (already captured by Resource Manager above), is able to identify if the resource is Protected by CA SSO.  This information is captured by the Realm\Rule objects at Policy Server. Once the Policy Server identifies this information, it sends the response back to the Agent via TCP/IP. If the resource is protected, Agent pass on to the next manager.

4.     The Agent calls the Credential Manager.  Since there are no credentials present, the Credential Manager calls the Challenge Manager.

5.     The Challenge Manager, based on the Authentication Scheme selected (this information is captured at the Protection Manager step from the Realm), processes the credential collection mechanism via HTML Form credentials, NTC etc.

6.     At this time the user is presented with a credential collection page (based on the authentication scheme defined).

7.     On supplying the credentials, the Webagent calls the Authentication Manager. The agent again makes a TCP/IP connection to the Policy server via LLA as it cannot make this decision on its own. The Policy Server at this point tries to disambiguate/Authenticate the user based on the User Directories selected for that Domain Object. Once it authenticates the user, it generates a SessionSpec and encrypts it with SessionTicket Key and sends it along with SessionID and other Authentication responses to the Webagent.

8.     The Webagent at this point declares that the user is Authenticated and passes the request on to the Session Manager.

9.     The Session Manager at this point generates the user session, creates a SMSESSION cookie and writes to the user’s browser.

10.  Finally, the Agent calls the Authorization Manager. Since the agent again does not have the capability to make this decision it calls the Policy Server via TCP/IP. The Policy server, based on the ‘Policy’ object definition for that domain, makes the Authorization decision. It then sends the Authorization responses to the Webagent.

11.  At this point,  the Webagent has all the information it needs to make the decision. Now the Webagent passes on the control to the webserver to show the target page to the end user.


If the user tries to browse another protected resource using the same browser session, it will have the same flow but a few things will be different such as, the Session Manager at step 2 decodes the SMSESSION cookie already present in the browser and checks if it is a valid cookie (session timeouts etc). Furthermore, the Credential Manager at step 4 uses session information and by-passes the challenge Manager step to perform the authentication. This way single-sign-on is achieved without challenging the user while Authentication/Authorization occurs in the background.

Hopefully you will find the information above useful as you troubleshoot Webagent-related issues.

Hacking CA SSO (SiteMinder) Password Services Redirects

Password Services Logo

CA SSO Password Service redirects work great if you want to use the default forms that ship with the Web Agent. While modifying the "fcc's" is a potential option, how do you take advantage of your existing password change forms? What about ignoring those pesky Active Directory password redirects?  Let's get hacking. There are a couple of settings you can use with Password Services beyond configuring a Password Policy within the Admin UI. The settings must be obvious, right? Well... Keep reading for the scoop.

Hack 1: Changing the Password Services Redirect When no Password Policy is defined, CA SSO redirects to the default Password Services FCC URL. You can override this behavior by setting the NETE_PWSERVICES_REDIRECT environment variable to the relative URL where you want to redirect the user. While the documentation says the path must be relative, I have successfully set it to a fully qualified redirect URL. Give that a shot, but the official means of setting a full qualified URL is in the Password Policy itself.

Password Policy Image
Password Policy Image

Keep in mind that the environment variable is set on the Policy Server(s) and not the Web Agent server(s).

Bonus: Take a look at the path in the Password Policy. If you ever wanted to exclude users based upon a LDAP attribute, you can use a search expression instead of a specific branch.

Hack 2: Disabling Password Services Redirects By default, CA SSO redirects natively disabled Active Directory users to Password Services, even if Password Services is not enabled for the authentication scheme protecting the resource or a Password Policy is not defined. To disable this behavior, set the IgnoreDefaultRedirectOnADnativeDisabled registry entry on the Policy Server(s). Configure the following registry entry:


: IgnoreDefaultRedirectOnADnativeDisabled


: HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Netegrity/Siteminder/CurrentVersion/Ds/LDAPProvider


: DWORD (32-bit) Value


: 0 (disabled) or 1 (enabled).


: 0. If the registry key is disabled, the default behavior is in effect.

Registry Entry Image
Registry Entry Image

Have Fun Storming the Castle and let us know if you have any other Password Services tricks.

WorkPoint Designer breaks after upgrading to IDM 12.6sp6 on Oracle WebLogic

broken-link On the server that was upgraded, perform the following changes:

Step 1. Navigate to the following file and open it for editing: ~Program Files (x86)\CA\Identity Manager\IAM Suite\Identity Manager\tools\Workpoint\conf\ Confirm the following section exists, update the entry for the server you are on. # ************************************ # ******* ORACLE WEBLOGIC SETTINGS ****** # ************************************ # These properties should be uncommented when using the ORACLE WebLogic server. # The default Provider URL is local machine - change from localhost # to access an EJB server on a remote machine # java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory java.naming.provider.url=t3://

Step 2. Navigate to the following file and open it for editing: ~Oracle\Middleware\user_projects\domains\Domain\applications\iam_im.ear\config\ Confirm the following section exists, update the entry for the server you are on. # ************************************ # ******* BEA WEBLOGIC SETTINGS ****** # ************************************ # These properties should be uncommented when using the BEA WebLogic server. # The default Provider URL is local machine - change from localhost # to access an EJB server on a remote machine # java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory # ******* END SETTINGS ***************

Step 3. Copy the following files From ~Oracle\Middleware\wlserver_10.3\server\lib

wlthint3client.jar wlclient.jar

To ~Program Files (x86)\CA\Identity Manager\IAM Suite\Identity Manager\tools\Workpoint\lib

Step 4. Navigate to the following file and open it for editing: ~Program Files (x86)\CA\Identity Manager\IAM Suite\Identity Manager\tools\Workpoint\bin\init.bat Add the following


To the end of the SET WP_JARS = line

Step 5. Restart the WL server instance.

Step 6. After the server is running, open CMD prompt as Administrator and navigate to the following path: ~Program Files (x86)\CA\Identity Manager\IAM Suite\Identity Manager\tools\Workpoint\bin>Designer.bat

Stuck Installer Woes!!!

Installation woes….So have you ever been trying to install a CA product via the installer program only to watch it just sit there and hang to eternity, wondering what on earth is the installer doing? Well wonder no longer. CA products utilize the Install Anywhere application installer and because of this, you have a tool at your disposal to observe just what the installer is doing and possibly where it might be hanging on the install process. Personally, I just had to use this process to help resolve an installer issue with IDM 12.6sp6 installing to a WebLogic backend where the installer would just hang with no errors. After walking through this process I was able to determine that the installer was hanging after evaluating the JCE version and the installer determined the JCE was not correct, but the UI is not coded to return an error.

stuck installer

To observe the installer process, execute the installer file from the CMD line in windows. You will see a popup for the install anywhere process bar as it loads the installer application. When the installer gets near 100% complete, hold down the CTRL key on the keyboard and this will place the Install Anywhere application in debug mode and produce a popup that will show exactly what the installer is doing. I hope this process helps you along the road as you install CA products…

Add MS ActiveDirectory Authentication to PingFederate

A common scenario for many companies that are deploying PingFederate is the desire to authenticate user's against an existing LDAP-based user store (most commonly Active Directory). While this is something that PingFederate can easily handle, it does have several steps that might not be obvious to a novice PingFederate Administrator. In this post I'll walk everyone through a quick and *very* basic configuration. Specifically, there are three different pieces that need to be created/configured in PingFederate (preferably in this order):

  1. A new Data Store
  2. A new Password Credential Validator
  3. A new IDP Adapter

Step 1 - Create a new Data Store object

  1. Navigate to "Server Configuration | System Settings | Data Stores"
  2. Click on "Add New Data Store"
  3. Select Type "LDAP" and click "Next"
  4. Enter the hostname or IP of your existing LDAP server
  5. Choose "Active Directory" as the LDAP Type
  6. Enter the Bind Credentials (you can get these from your AD Administrator) and click "Next"
  7. PingFederate will test the connection with the information you have provided. If PF reports any errors, correct them and try again.
  8. If there are no errors, on the Summary screen chose, "Done" then "Save".

Step 2 - Create a new PCV object

  1. Navigate to "Server Configuration | Authentication | Password Credential Validators"
  2. Click on "Create New Instance"
  3. Assign your PCV an Instance Name and Instance Id
  4. Choose "LDAP Username Password Credential Validator" as the Type and click "Next"
  5. From the LDAP Datastore dropdown, select your Data Store created in the previous section
  6. Enter the Search Base (ie, "ou=users,dc=company,dc=com") for where PingFederate should start search for your user's
  7. Enter the Search Filter for how PF should identity unique users. For AD, this is typically "sAMAccountName=${username}" Note: For Sun/Oracle Directory Server the value is typically "uid=${username}" (where ${username} is the value the end user provides.
  8. Click "Next"
  9. On the Summary screen chose, "Done" then "Save".

Step 3- Create a new IDP Adapter

  1. Navigate to "IdP Configuration | Adapters"
  2. Click on "Create New Instance"
  3. Assign your PCV an Instance Name and Instance Id
  4. In the "Type" dropdown, for simplicity, choose "HTML Form IdP Adapter" and click "Next"
  5. On the following screen, you'll need to select "Add a new row to 'Credential Validators'". You can choose the PCV you created in the previous step and click "Update".
  6. Ping has already populated most of the options on this screen. For this example, you can use the defaults. If needed, you can come back and change these options at anytime.
  7. Click "Next"
  8. On the "Extended Contract" screen, choose "Next"
  9. On the "Adapter Attributes" screen, place a checkmark in the "Pseudonym" column for "username" and click "Next"
  10. On the Summary Screen click "Done" and then "Save"

That's it. Now you have an IdP Adapter that can perform a simple authentication against Active Directory. In order to use this Adapter, you'll need to add it to one of the Web SSO use cases that PingFederate supports (OpenID Connect, SAML 2.0, WS-Federation, SAML 1.1 or Adapter-2-Adapter Mapping) or use it for authentication to PingAccess resources.

Good luck! Ian Barnett Ping Identity Practice Director