Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > 2016 > November


How to configure X.509 cert authentication with CA Access Gateway


  • Policy Server : R12.52 SP1 and above
  • CA Access Gateway : R12.52 SP1 and above
  • User Store : ANY LDAP/ODBC 


You have already obtained following three required certificates:

  • Trusted CA root certificate.
  • Server Certificate from a trusted CA.
  • Client Certificate from a trusted CA.


Changes on the Policy Server


1. Create X.509 certificate authentication scheme as below :

2. Create Domain, Realm, Rule (get/post), Policy . Protect the realm with the X.509 authentication scheme.

3. Click Certificate Mappings under Directory and create mapping as below.

Note :

  • Ensure that the Issuer DN matches exactly as in the user certificate.
  • Choose the mapping attribute as per the Active Directory LDAP User DN lookup configuration



Changes on the CA Access Gateway


A) Configure SSL for Apache

1. Login to Proxy UI and navigate to Proxy Configuration > SSL Config

    Click Request button under Embedded Web Server SSL Configuration


2. Enter the requested details. Ensure that the Requester Name matches the host name as configured in the VirtualHost configuration in Server.conf

3. Click Generate button to create the CSR (certificate signing request file). 

    Save the CSR file. You will need to submit this file to CA for signing it.

4. Now, before importing the signed server certificate file from CA , if the CA is not a Trusted CA , you will need to import the CA along with it's intermediate certificate.

Navigate to Proxy Configuration > SSL Config 

Click Import CA under Embedded Web Server SSL Configuration

5. Click on Browse button and select the CA certificate. Then, continue clicking Next until the CA certificate is imported successfully.

If there are Intermediate CA certificate, repeat the same steps to import them as well.


6. Once CA is imported, you are now ready to import the signed server certificate from CA.

Navigate to Proxy Configuration > SSL Config.

Under Embedded Web Server SSL Configuration , Click Browse  to select the signed server certificate, Choose the CA which signed it from the CA Certificate drop down and Click Apply.

Click Import CA under Embedded Web Server SSL Configuration

7. Upon import , confirmation message is shown. You will need to restart the CA Secure Proxy service to fully enable the SSL configuration.

8. Restart CA Secure Proxy Service and try accessing the Apache on https to confirm that SSL is enabled :



B) Configure SPS Apache for X.509 client certificate authentication

1. To ensure that Apache request certificate from client (browser) , modify the httpd-ssl.conf file under <CA Access Gateway Home>\httpd\conf\extra folder as below :

Change SSLVerifyClient from optional to require

2. Next, un-comment the SSLCACertificateFile parameter. The ca-bundle.cert will already have been configured with the CA certificate which signed the Apache server certificate.

If the CA which signed your client certificate is not the same as the one which signed your Apache server certificate, manually add the CA certificate to the ca-bundle.cert file.

(For my testing, both CA are the same so I didn't have to add any extra certificate into this file)

3. Restart CA Secure Proxy Service.


Changes on the client machine

Import the client certificate either using MMC or using Browser itself.





1. From the client machine access the resource protected with X.509 authentication scheme. For this test, I protected the Auth/Az webservice with X.509 certificate authentication scheme so I will try accessing the same on HTTPS port.

2. It will prompt you to select the client/user certificate. Choose the appropriate user certificate and click Ok.


Additional Information


In r12.0 we used to have following registry , the same is not available in r12.52 SP2. Are they still valid or have they been moved elsewhere ?



 "Thread Pool Size"=dword:00000006 

 "Max Tunnel Buffer Size"=dword:07fffe10 

 "Tcp Idle Session Timeout"=dword:0000000a 



 "Thread Pool Size"=dword:00000006 

 "Max Tunnel Buffer Size"=dword:07fffe10 

 "Tcp Idle Session Timeout"=dword:0000000a 



 "Thread Pool Size"=dword:00000006 

 "Max Tunnel Buffer Size"=dword:07fffe10 

 "Tcp Idle Session Timeout"=dword:0000000a 



 "Thread Pool Size"=dword:00000008 

 "Max Tunnel Buffer Size"=dword:07fffe10 

 "Tcp Idle Session Timeout"=dword:0000000a



Policy Server : r12.52 SP2 OS : Any


Yes, all these registry are now obsolete. 

Now, there is just one setting related to this and is moved to HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\PolicyServer


  • What is the purpose of following registry :


  •  Is it recommended setting this registry to 1 ? 


Policy Server Version : R12.0 SP3 and above


When the registry FlushObjCache is set to 1, it enables the flushing of Policy store cache.

Flushing the policy store caches flushes all of the current entries and reloads the cache with all of entries in the policy store. During the flush, the policy store cache is taken offline. The Policy Server either pauses or uses the policy store directly to make policy decisions


To enable flushing of the policy store cache

Open the registry editor.

Navigate to \\HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore.

Create the FlushObjCache registry key with the following values:


Value: 1 or 0

  • 1 Enables the key. When enabled, you can use the Flush All button on the Cache Management dialog to flush all Policy Server and associated SiteMinder Agent caches, including the policy store cache.
  • 0 Disables the key. When disabled, you can use the Flush All button on the Cache Management dialog to flush all Policy Server and associated SiteMinder Agent caches, excluding the policy store cache.

Note: If a value does not exist, the key is disabled.

Then, Use the Cache Management dialog in the Administrative UI to flush all caches.

Important : It is strongly advised NOT to enable this registry key as this could severely impact the policy server performance as it has to rebuild the policy store cache every time the Flush All command is executed.


Customer experience following error when policy server tries to insert data into smobjlog4 table.



[624/2756][Mon Nov 12 2012 17:41:01][CSmDbODBC.cpp:194][ERROR] Data source 'SMAuditLogsDataSource4', State = 22001 Internal Code = 8152 -

[DataDirect][ODBC SQL Server Driver][SQL Server]String or binary data would be truncated., SQLResult=-1 from 'DoExecute'API at '..\..\..\CSmDbODBC.cpp:3559'

[624/2756][Mon Nov 12 2012 17:41:01][CSmDbODBC.cpp:194][ERROR] Data source 'SMAuditLogsDataSource4', State = 01000 Internal Code = 3621 -

[DataDirect][ODBC SQL Server Driver][SQL Server]The statement has been terminated., SQLResult=-1 from 'DoExecute'API at '..\..\..\CSmDbODBC.cpp:3559'

[624/2756][Mon Nov 12 2012 17:41:01][CSmDbODBC.cpp:194][ERROR] Data source 'SMAuditLogsDataSource4', State = Internal Code = 3621 - ,

SQLResult=-1 from 'DoExecute'API at '..\..\..\CSmDbODBC.cpp:3559'

[624/2756][Mon Nov 12 2012 17:41:01][SmReportsODBCLog.cpp:349][ERROR] Failed executing audit log insert: Internal Error: Database error. Code is

-4007 (DBMSG: <>>).Code: -4007. DB Code: 3621 


  • Policy Server : R12.51 and above
  • OS : ANY
  • Audit Database : ANY ODBC Database


The issue is about because of the field size limitation for sm_objid in Audit log table (smobjlog4). Policy server by default inserts the UserDN attribute in sm_objid & UserName attribute in sm_objname column.

The default column size for sm_objid is 64 byte and 512 byte for sm_objname.

The issue occurs when the UserDN value is greater than 64 byte. 


A new registry key has been introduced which will swap the data inserted between sm_objid & sm_objname columns.

So, with the following registry in place, the UserDN will now be inserted into sm_objname column and UserName is inserted into sm_objid  column.


Add "SwapObjidObjName" parameter in registry under following path and set the value to 1:


Windows 64 Bit 



Windows 32 Bit



Non Windows OS

Add the following lines to the sm.registry file:



SwapObjidObjName=0x1; REG_DWORD



  • If you expect the UserName attribute also to be more than 64 byte then , instead of applying this registry fix you can increase the column size for sm_objid  to 512 as well.
  • Policy server service needs to be restarted after applying the registry changes


Policy server encryption key is provided during policy server installation. The value is stored in EncryptionKey.txt

(<Policy_server_install_path>)/bin folder)

This key is used by the Policy server to encrypt and decrypt "sensitive" information that is entered in the

CA SSO (Siteminder) via policy server management console (SMConsole) as well as the 

CA SSO Policy Server User Interface.

This includes data such as LDAP bind-credentials, ODBC passwords, key-store keys,

agent shared secrets etc.



No way for policy servers that use different Encryption key to share same policy store.

In order for policy servers to decrypt the sensitive information within policy store,

they need to use the same encryption key.

We can change it via smreg -key <encryption_key>



CA SSO R12.5x



1. Shut down PS. Backup policy store, key store, Encryptionkey.txt. This will ensure if something went wrong during the process, we can revert back to initial state.


2. Export all policies.


xpsexport policy.xml -xb -npass


3. Export keys from key store.

smkeyexport -o<output_file> -d<AdminName> -w<AdminPW> -c

smkeyexport -oC:\keys_24112016 -dsiteminder -wpassword -c


Snippet of output file that shown 1 persistent key and 4 agent keys.
This should be the expected number of keys exist in key store.
If you have more than that (4 agent keys, 1 persistent key), the key store need to be clean by delete from key store database (SMKEYMANAGEMENT4, SMAGENTKEY4) OR LDAP (under ou=PolicySvr4,ou=Siteminder,ou=Netegrity,o=policystore)
objectclass: KeyManagement
Oid: 1a-fa347804-9d33-11d3-8025-006008aaae5b
IsEnabled: false
ChangeFrequency: 0
ChangeValue: 0
NewKeyTime: 0
OldKeyTime: 0
FireHour: 0
PersistentKey: {RC2}dXy1BLg1cCxHOCTeMQVTPGdc9yuIZWifw56FolkCe5xgKnd22yyD04Ieym2MXApW

objectclass: AgentKey
Oid: 1b-ac33e28a-5d5b-4b4d-a058-a1cc81dfb060
KeyMarker: 4
Key: {RC2}O1pxVqlA6H4dWjNMUb+yuKiToj+JUhh236U+uxQyB2UDxBtNGUhzK5iN/MaRiGTs

objectclass: AgentKey
Oid: 1b-d1d8b57a-c5f4-40b4-ac28-2e59fa9e7826
KeyMarker: 1
Key: {RC2}h9ROaVGqNsg8kqlWf+cgfhzD0zcdvFyXD8bx0VhMPwXEmxsjq5vRm6AWus9mrtyr

objectclass: AgentKey
Oid: 1b-15ec7f7a-f6ff-4e3a-a9aa-7c5063bdf82c
KeyMarker: 2
Key: {RC2}iqT8BIdlWocHk93EQkk/6KydvXmZvBlksez5kU0uaO+H1SUkD80pmvMb6EJw5n9d

objectclass: AgentKey
Oid: 1b-af19bf4f-3792-42ae-b73b-dd2c70fac37d
KeyMarker: 3
Key: {RC2}dPb5P+wNcUCfE7HnPfv+HXpaE8r8wPix52KdQJO2K1tCAHnm/VcSfDYxQ6CvMY+k

4. Change encryption key via smreg -key command


smreg -key <encryption_key>


5. Import policies after encryption key changed.


xpsimport policy.xml -npass -fo


6. Import keys via smkeyimport


C:\>smkeyimport -iC:\keys_24112016 -dsiteminder -wpassword -c


7. Startup policy server


8. Rollover agent keys and persistent key via WAMUI. (Optional)


Additional Information:


In this guide, we will see how to invoke REST Auth/AZ web service and pass the required client certificate when it is protected with X.509 certificate authentication scheme.


  • Web Agent/Policy Server: 12.52 and above
  • OS : ANY

Pre-requisites :

  • The root resource (/authazws/) for Auth/AZ web service is protected with X.509 Authentication scheme.
  • The web server (Apache) component of Apache is configured for SSL connectivity.
  • Client (user) certificate for the Authorised users are created.



TEST 1: REST Client (e.g SOAPUI)

This needs configuring SOAPUI with the X.509 certificate authentication.

This has been detailed quite well here : How to configure SoapUI with client certificate authentication 



TEST 2: REST Client ( e.g Java)

1. Add the CA cert which signed the SPS Apache server certificate to the java key store as trusted CA:

e.g. keytool -importcert -trustcacerts -alias ad2k8-01 -file RootCA-ad2k8-01.cer -keystore cacerts -storepass changeit -v


2. Modify the following properties in as per your environment

3. Modify the JDK home in the java-build.bat and java-run.bat (windows)

4. Compile the Test class by running java-build.bat (windows)

5. Execute the class by running java-run.bat (windows)

  Sample output :


Additional Information


FSS UI stopped loading up recently. It was working before.

No change on the Policy server or OS has been made recently.

Following error message is displayed in IE.


Policy Server : Affected upto 12.52 SP1 CR6 and 12.52 SP2 CR1
Web Server : ANY
Java : 1.7 or 1.8


The FSS UI certificate that is shipped with the above version of Policy server has expired effectively from October 16, 2016.

So, post this date, the Java security wouldn't allow FSS UI to load due to expired certificate.


How to validate the certificate expiry date 

  1. Open Java control panel
  2. Click Security--> Manage Certificates
  3. Double Click the certificate issued to "CA Inc"
  4. Note the Validity date as "October 16 , 2016"

 Alternatively, if you enable the Java tracing from Java control panel,  then you will see the certificate expiry related error as below :


Add the FSS UI site URL as exception in the Java control panel.

  • Open Java control panel.
  • Click Security --> Edit Site List


1. Delete browser history and launch FSSUI

2. Click the check box below to accept the security warning and click Run

3. You will then be shown the FSS UI login page 


CA is working on renewing the expired certificate. If you can't utilise the workaround provided , please open a support case so we can provide you the renewed certificate as a development fix.


In this guide, we will see how to protect Auth/AZ SPS web service with Basic Authentication and also how to configure web service client to pass the credential while invoking the Auth/AZ web service.


For this use case , we will test with REST web service but the procedure is exactly the same for SOAP web service call as well.


  • Web Agent : 12.52 and above
  • OS : ANY



Protect CA Access Gateway Auth/AZ web service


Create Domain/Realm/Rule/Policy to protect the root URL /authazws/. For this demo, only the user "shruj01" is authorised to access Auth/AZ web service resource.



TEST 1 : REST Client ( e.g SOAPUI)


1. Base64 encode the Web service user credential in the format "username:password". This can be done using online tool Base64 Decode and Encode - Online 

Copy the encoded output , this will be needed in next step while configuring the REST client.


2. Configure the REST Post request as below.

The important thing to note is , as the web service is protected, we now need to send following headers along with the   actual REST request.

a. Authorization: Basic <Based64 encoded value of username:password> 

b. SMCHALLENGE=YES cookie header ( This is required if RequireCookies= YES in the ACO of the agent protecting the AuthAZ web service resource.


TEST 2: REST Client ( e.g Java)

1. Modify the following properties in as per your environment

2. Modify the JDK home in the java-build.bat and java-run.bat (windows)

3. Compile the Test class by running java-build.bat (windows)/ (unix)

4. Execute the class by running java-run.bat (windows)/ (unix)

  Sample output :

Sample class :



1. Sample Java program 


Additional Information:

Configuring the Authentication and Authorization Web Services - CA Single Sign-On - 12.52 SP1 - CA Technologies Document… 


How to configure redirect response (OnAuthAccept/OnAccessAccept) with CA Access Gateway Auth/Az Web Services.



  • Web Agent : 12.52 and above
  • OS : ANY


1. Configure Redirect Response normally as you would for normal web agent.


2. Test AZ web service using Soap UI (or any other SOAP client)

As this is a web service request (SOAP, REST), CA Access Gateway can NOT do normal agent redirect (302 redirect) .So, instead what it does is it it preserves the configured redirect response in a custom HTTP header SM_REDIRECTURL (if LegacyVariables = YES) / SMREDIRECTURL (if LegacyVariables = No) and returns it as a SOAP response. From there it will be up  to the web service client to decide what to do with it.




Additional Information:

Configuring the Authentication and Authorization Web Services - CA Single Sign-On - 12.52 SP1 - CA Technologies Document… 


In this guide we will see how to configure OAuth 2.0 Partnership Federation between CA SSO (OAuth Client) and Google (OAuth server)



  • CA SSO 12.52 and above
  • CA SSO Federation web services with HTTPS access. The X.509 Certificate MUST have been signed  by a trusted Certificate Authority such as VeriSign, Entrust etc. This is a requirement from the OAuth providers like Google, Facebook etc. ( I got it for free for my domain from which comes with 1 year validity)
  • Access to Google Cloud Platform account (




Configure OAuth Authorization in Google IDP


1. Login to Google cloud platform (

2. Create New Project --> "Google Oauth SSO"

3. From the top left drown menu , choose the new project that you just created

4. Double Click --> "Use Google APIs"



5. Click "Create Credentials" drop down menu and select "OAuth Client ID" 


6. Before creating "OAuth Client ID" it is a requirement to set a Product Name to identify your Google App in the consent screen, so click "Configure Consent Screen" 


7. Specify Product Name (as shown to users) , e.g "CA SSO" and click Save.

8. Now, choose the Application Type = "Web Application" and specify the value as below and click Create:

  • Authorized Javascript Origins = <Your SP home page>
  • Authorized Redirect URIs = <SP Base URL>/affwebservices/public/oauthtokenconsumer/google<OAuth ClientID>

Note :

  • As we don't know the OAuth ClientID yet , give any placeholder character like XXXX
  • The Authorized Redirect URI is same as the "Redirect Url" that will be configured for OAuth 2.0 Local Entity later

9. Once the OAuth ClientID is created it will be displayed along with the Client Secret.

These will be required while configuring entities and partnership in CA SSO so make a note of it.

10 .  As we haven't provided the actual ClientID in the "Authorized Redirect URI" in step 8 above, so we need to go back and edit the newly created ClientID by clicking the edit button (pencil icon).







Configure OAuth client in CA SSO:


1. Login to Admin UI and Create Entities under Federation > Partnership Federation as below :   



Note : 

  • Entity ID : Google-<OAuth Client ID> (note the hyphen - )
  • Disambiguation ID : google<OAuth Client ID>
  • Redirect URL : <SP Base URL>/affwebservices/public/oauthtokenconsumer/google<OAuth ClientID> (same value as Authorized Redirect URI  in OAuth Client ID creation setup in Google Cloud )


2. Note, it is not needed to create OAuth 2.0 remote entity for Facebook as it is created OOTB

3. Next , proceed to create Partnership > OAuth Client -> OAuthz Server as below :

Configure User Identification Attribute:

  • User ID Attribute Name – User identifying claim from the OAuth user (e.g. email)
  • User Information Service URL – User information URLs that the system must use to retrieve user claims  For Google it is :
  • Scope – Pre-filled as configured in the Remote Entity
  • Federated Users– Select users that should be allowed to authorize (e.g. All Users in lcoal SP Directory)



  • Client Authentication ID : <OAuth Client ID>
  • Client Secret : <Client Secret corresponding to the OAuth Client ID>

Leave the remaining fields to default.


  • Redirect Mode : HTTP Headers (or any other preferred mode)
  • Target : Target SP URL after authorization.

Configure Domain/User Directory/Policy etc for SP Target URL:

  • This step is not detailed here as its basic CA SSO configuration.
  • You also need to ensure that your Federation User Directory have the User with the same attribute (email as per our current configuration ) 


Federated Social Login Testing (OAuth Client initiated):

1. Access URL to imitate Oauth 2.0 federation : 




FWS_FQDN is the fully-qualified domain name for the host serving SiteMinder Federation Web Services





2. If not already logged into Google account , prompted for login. Proceed to login.

3. Allow the Google App to access profile information from Google (these info will be returned to SP )

4. Redirect to the Target URL in SP



Additional Information:

CA SiteMinder Social Sign-On Runbook for Google IDP 


In this guide we will see how to pre-fill the username field during second challenge in step up authentication.



  • Both low level and high level authentication scheme is using HTML Form Authentication scheme.
  • UseHTTPOnlyCookies ACO parameter is set to YES
  • Can not use server side technology like  ASP/JSP/ASPX etc. Can only use login.fcc for login form.



  • Web Agent : 12.0 and above
  • OS : ANY



1. Let's create two copies of the OOTB login.fcc and rename them as login5.fcc & login10.fcc.


2. Create two HTML FORM authentication scheme one using login5.fcc with Protection Level 5 and other using login10.fcc with Protection Level 10.


3. Protect two resource say /html/ with login5.fcc auth scheme and /html10/ with login10.fcc to simulate step up authentication scenario.


5. Now , the trick is to add following line in the login5.fcc to instruct Web Agent to save the value in the "USER" form field as cookie 



(Note : If you need to save multiple form fields, you can specify name of the form field as colon separated list like @save=USER:TARGET )


So, after adding this line the login5.fcc looks like this at top 

<!-- SiteMinder Encoding=UTF-8; -->



6. Next, modify the login10.fcc to pre-fill the USER form field by reading the cookie set earlier like this :


<td ALIGN="LEFT" >
<b><font size=-1 face="arial,helvetica" > Username: </font></b>
<td ALIGN="LEFT" >
  <input type="text" name="USER" size="30" style="margin-left: 1px" value="$$USER$$">
<td WIDTH=20 > </td>


Now, the most important thing to note here is , this works even when using HTTPOnly cookies as the FCC processing happens on both the server side as well client side. All the variable with the format $$VariableName$$ are replaced on the server side by reading the value from various sources like :

  • The headers named in the SMHEADERS variable.
  • The directives.
  • The cookies.
  • The posted form data.


As you can see above the variable replacement happens on the server side,so it doesn't matter even if the HTTPOnly flag is set on cookies.



  • Sample login fcc
  • Sample fiddler


Travelport is redefining how companies search, share, buy and sell travel with its Travel Commerce Platform, which connects the world’s leading travel providers with online and offline travel buyers in a proprietary business-to-business marketplace.




Travelport must be able to protect critical systems, applications and information from unauthorized access and provide all users with secure, but simplified, access to digital assets.




CA Identity Manager provides an end-to-end view of the access rights of more than 7,000 Travelport employees and contractors, along with the travel agency staff. CA Identity Governance enables the company to easily govern and correct these users’ entitlements. CA Single Sign-On provides secure access to a multitude of diverse business systems, which are integrated with directory systems such as Active Directory, LDAP and Exchange.




With the CA solutions, Travelport has been able to eliminate multiple legacy identity solutions, enabling a more consistent user experience and reducing costs. With fewer identities to manage, Travelport can provision new users in minutes rather than days, and ensure their access entitlements remain aligned to their role. The solutions have also accelerated time-to-market for new systems and freed up resources.


Read the full story here:…