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


Key Store comprise of following :

  • One KeyManagement object ( This also contains the persistent Key)
  • Four Agent Keys (One set)

The four Agent Keys are :

  • (Key Marker 1) An Old Key is a Dynamic key that contains the last value used for the Agent key before the current value.
  • (Key Marker 2) A Current Key is a Dynamic key that contains the value of the current Agent key.
  • (Key Marker 3) A Future Key is a Dynamic key that contains the next value that will be used as the Current key in an Agent key rollover.
  • (Key Marker 4) Static Key

Note: While using static agent keys , the underlying value for all the 4 Agent Keys will be same , all though the encrypted value will be different in the key store.

At any point in time, key store should have only 4 agent keys (one set) as described above. 

Because, if there are more than 4 agent keys, there will be no guarantee which set of keys an Agent will utilize if more than one set is delivered from the Key Store on Agent start up. 

Consider a scenario , that there are two set of agent keys - set 1 & set 2. Now, if Web Agent 1 utilizes set 1 and Web Agent utilizes set 2, the SMSESSION cookie encrypted by one agent will not be decoded by another agent eventually breaking the SSO.

So it is very important that care should be taken not to duplicate Agent Keys.





In this guide, we will discuss one particular scenario during the key import which should be considered to avoid duplicate agent keys.

The OID of KeyManagement object is always "1a-fa347804-9d33-11d3-8025-006008aaae5b". However, the OID of an Agent Key object could be any random value.

Let's consider as sample key export from source Key Store :



and lets check the existing OID of keys in the destination Key Store :



As you can see above, even though the OID for KeyManagement object is same between source and target Key store, the OIDs of Agent Keys are different.

Now, if you import this key store export file in the target key store the final key store after the successful import looks like this :



As you can see above, during the import , the smkeyimport tool updated the existing KeyManagement object as the OID was the same.

However, as the OIDs for the Agent Keys were different, it created the new Agent Keys object resulting in the duplicate set of Agent Keys. 


Policy server : Any Key store : Any


To fix this , you will need to delete the old set of Agent Keys manually from the key store.

You can identify the OIDs of old set of Agent Keys by doing a smkeyexport from the target key store before doing the smkeyimport.


How to delete specific agent keys:


1) For RDBMS use the SQL commands to delete the keys that did not change between the two files.

Example command:

DELETE FROM smagentkey4 WHERE agentkeyoid '1b-4a79595f-9a40-1000-a34a-830cefdf0cb3'

Note: The commands are for example only and will need to be modified to match the OIDs for your environment.


2) For LDAP use the LDAPModify command to delete the keys that did not change between the two files.

Example command:

# ldapmodify -D "cn=directory manager" -w dirmanagerpassword -h localhost

dn: smAgentKeyOID4=1b-4a79595f-9a40-1000-a34a-830cefdf0cb3, ou=PolicySvr4,ou=SiteMinder,ou=Netegrity,o=ghost

changetype: delete


Additional Information


Smkeyimport fails to import the KeyManagement object even on the same policy server where the export was taken from.

Total Number of Objects read from input file: 5

Objects Successfully Created: 4

Objects Successfully Updated: 0

Objects Not Saved - Errors: 1

Objects Not Saved - Duplicates: 0

Objects Not Saved - Wrong Parent: 0

Objects Not Saved - Wrong Type: 0

Objects created and renamed - Name conflict with another object: 0


Diagnostic Messages

ERROR: Failed updating KeyManagement object 1a-fa347804-9d33-11d3-8025-006008aaae5b. Status: 'Unknown Failure'


Policy server : r12.0 and above Policy server OS : Any Policy store : Any


This happens when the "Enable Agent Key Generation" check box is disabled on the Policy server.

If the policy server is not configured to generate agent keys, smkeyimport will always fail to import the "KeyManagement" object.




Check "Enable Agent Key Generation" check box on the Policy server management console of the Policy Server before performing smkeyimport.

You can disable this back once the smkeyimport is complete.



Prior to r12.52SP1CR5, there was a provision to specify any text to filter out the desired Member Group and Member Organizations. in Administrative UI

For e.g 

If there are following Member Groups :


You could use search filter as : "Manager" to filter the DN : CN= Manager,CN=Users,DC=ad,DC=lab


However, starting with r12.52SP1CR5, this feature is removed.

Now, the only filter that works is : CN=Manager


Anything else does not work:




  • Policy Server : 12.52 SP1 CR5 and above.
  • Admin UI : 12.52 Sp1 CR5 and above


This is working as per the new design. Now , the search filter is expected to be in the format CN=*** (LDAP syntax).

The base for the search filter is picked up from the User Directory configuration (LDAP Search root)



There is no workaround/resolution for this issue.

Additional Information

An enhancement request is created to bring back this feature :


  • What is the purpose of ExecutionTimeThreshold registry ?
  • How can this be configured?
  • What is the default value?
  • Can this be configured for Web Agent ?
  • How to interpret the info message related to this ? 
  • What is the best value for this ?


  • Policy Server : r12.52 SP1 CR5 and above.
  • Policy Server OS : Any


What is the purpose of ExecutionTimeThreshold registry ?

The purpose of this registry is to identify functions that take an excessive amount of time to execute without enabling tracing (which can negatively affect performance).

How can this be configured ?

This can be configured by setting the value for following registry entry :


The value should be hexadecimal equivalent of the number of milliseconds.

For e.g to set this as 5 seconds = 5000 ms , you need to set this value as 0x1388

What is the default value?

The default value is 5 seconds ( 0x1388)

Can this be configured for Web Agent ?

No, this is Policy server only feature.

How to interpret the info message related to this ? 

To illustrate this , lets consider following example :

Execution time exceeded threshold. (CServer::Tunnel, 7396, 5000, agent=agentX client= resource=/index.jsf action=POST user=user1).


  • The first parameter = Name of the function
  • Second Parameter =  Actual Execution time of the function
  • Third Parameter =  ExecutionTimeThreshold as configured in the policy server registry (in millisecond)
  • Fourther parameter = Resource context

So the above info message can be interpreted as below:

The CServer:Tunnel function execution exceeded the configured threshold of 5000ms and took 7396ms to execute.

This happened for POST request for user1 from client IP and agent agentX

What is the best value for this ?

There is no best/optimum value for this setting. It depends on what application demands.

For some application , it is critical to be very responsive while for other it may be ok to be sligthly less resoponsive.

For most cases, this can be left to the default value of 5 seconds. 

Additional Information


Web Service Variable is created as below :


SOAP Response :

<soapenv:Envelope xmlns:soapenv="" xmlns:xsd="" xmlns:xsi="">


XPath Expression : /*/*/*/*[local-name()='Permission']/text()

If using standard XPATH 1.0/2.0 API, the above XPath Expression parses the result as :



Reference :

However, for the same SOAP response and XPath combination, Policy server fetches only the first result and hence resolves this Web Service variable to value (only) "SUPERUSER"

Policy server Java Util.log

October 16, 2016 9:04:30.76 PM[17008593:AEC Variable Resolution] After resolution resolved variables: <RVARS><Var name="EmptyString" rtype="3"><![CDATA[""]]></Var><Var name="BBHWSVariable" rtype="3"><![CDATA[SUPERUSER]]></Var></RVARS>  


Policy Server : 12.52 SP1 and above Policy Server OS : ANY


This is as per the policy server design and is currently the limitation. Policy server is designed to evaluate to only the first node from the list. The other nodes are ignored.


There is no workaround/resolution for this functionality at the moment.

Customer might implement their own web service client and XML parser using the custom Active Expression. 

Additional Information




Use Case

Customer upgraded Web Agent Option Pack from r12.0 to r12.52 SP1CR5.
User logon to centralized web agent resource first and then initiate Unsolicited(IDP Initiated) federation.
After that, when navigating back to the normal web agent resources, the user session is being rejected with following error at the webagent trace log.
Client IP and SMSESSION IP do not match




  • Customer has Transient IP check enabled on the centralized Login Web Agent. (different from IDP Web agent)
  • Customer has Transient IP check disabled on the IDP Web Agent as well as IDP WAOP
  • All Web Agent and Web Agent Option Pack are behind the Load Balancer
  • CustomIPheader is configured for Login Web Agent, IDP Web Agent and WAOP ACO 



  • Policy Server : R12.52 and above 
  • Policy Server OS : Any
  • Web Agent : 12.52 and above (Both login and IDP)
  • Web Agent Option Pack : 12.51 and above


Root Cause:

In r12.0 version of Web Agent Option Pack, it did NOT generate SMSESSION cookie on successful validation of existing SMSESSION cookie.

However, r12.51 onwards, Web Agent Option Pack does generate SMSESSION cookie.

But unlike normal web agent it doesn't support the CustomIPHeader ACO parameter.

So, when it creates the SMSESSION cookie it resolves client IP as follows :

  • It first reads the SM_CLIENT_IP header, if it has the value, it uses this.
  • If SM_CLIENT_IP header is empty it uses the Proxy IP as the client IP. The Proxy IP is usually the Load Balancer IP.

Now, the normal Web Agent sets this SM_CLIENT_IP header to the actual browser IP address only if either TransientIPCheck or PersistentIPCheck is enabled.

As, in this case neither TransientIPCheck nor PersistentIPCheck was enabled on the IDP Web agent, it wasn't setting this SM_CLIENT_IP header as a result the WAOP was using the Proxy IP while creating SMSESSION cookie.

Now, when this SMSESSION cookie created by WAOP is submitted to normal agent the IP validation fails as the resolved client IP (resolved from CustomIPHeader) and the one in the SMSESSION cookie does not match.


Enable either Transient IP check or Persistent IP check on the IDP Web Agent as well.



CA might support CustomIPHeader for Web Agent Option Pack in the future release. At this time of writing it doesn't support it.



Policy server throws following error while evaluating the Webservice Variable: (Java util logging)

October 13, 2016 4:08:01.865 PM[1977511:E] Parse error caught parsing definition for variable: "Calculator_WS_IIS01" message: The prefix "soapenv" for element "soapenv:Body" is not bound.
October 13, 2016 4:08:01.865 PM[1977511:E] Exception Stack Trace: java.lang.NullPointerException  


 Also, On trying to modify the variable it shows following error in the Admin UI server.log:


2016-10-13 16:16:20,852 ERROR [STDERR] (http- [Fatal Error] :1:496: The prefix "soapenv" for element "soapenv:Body" is not bound.
2016-10-13 16:16:20,852 ERROR [ims.ui] (http- java.lang.reflect.InvocationTargetException





  • Policy Server : R12.5 and above 
  • Policy Server OS : Any



This was a mis-configuration of SOAP Body paramater in the Variable definition in the Administrative UI.

It was configured like this :


The <soapenv:Body> element is automatically added by Policy server. So it NOT necessary to include this element while defining the SOAP Body during variable definition.

Also, if there is any namespace used inside the SOAP Body element it needs to be defined within the Body itself.

For e.g in the above sample, the namespace "tem" is used but is not defined.




Unfortunately, Administrative UI doesn't allow you to modify the Variable when there is this particular mis-configuraiton.

So, to fix this issue, you will need to delete the problematic variable and create new variable with proper configuration as below :



Additional Information:

Tech Tip : CA Single Sign-On :Policy Server:How to enable log for Variable Processing 


In this guide we will discuss how to configure logging for variable processing by Policy server.


  • Policy Server : R12.52+,
  • OS : ANY


  • Specify the file as the logging config file in  JVMOptions.txt located at <policyserver_home>config directory as follows :

      -Djava.util.logging.config.file=C:/Program Files (x86)/CA/siteminder/config/properties/

  • Modify as below :

   The log file is created by default in the <policyserver_home>/bin directory.


Testing :


Additional Information : 


In this guide we will discuss how to set custom error messages while using custom authentications scheme (java)


  • Policy Server : R12.0+
  • OS : ANY



To set a custom error message, from custom authentication scheme you will need use SmAuthenticationContext.setUserText() API.


At the client end, then the error message is set as a SMUSRMSG cookie response.


Example : In the following sample, if the user logs in with invalid credential , a custom error message is set.


Modify custom authentication scheme to set custom error message

authUserText = theUserContext.authenticateUser(thePassword);
catch (Throwable exc)
// insure subsequent code knows the authentication attempt failed
authUserText = null;

if (null == authUserText)
context.setUserText("Custom Error : Authentication Failed..");


new SmAuthenticationResult(SmAuthStatus.SMAUTH_REJECT, SmAuthenticationResult.REASON_NONE);


Modify login page (login.asp for e.g) to read the SMUSRMSG cookie and display if the value is not empty 

if Request.Cookies("SMUSRMSG") <> "" then
response.write "<h2>"+ Request.Cookies("SMUSRMSG")+ "</h2>"
END if






  • Sample - Sample Custom Authentication scheme
  • login.asp - Sample custom login page
  • Fiddler.saz - sample http header capture from the testing

Additional Information:


In this guide we will discuss how to consume (decrypt) Federation OFC cookie generated by Policy server


  • Policy Server : R12.52+,
  • OS : ANY


Policy Server is already configured to generate OFC cookie for partnership federation 




1. Compile attached

2. Put the jars from the attached in the classpath.


The primary decryption logic at the relying party is following:


  1. The Java Application creates an implementation class of the IFederationOpenIdentity interface 

    IFederationOpenIdentity fedOpenIdentity = new FederationOpenIdentityImpl(cookieZone,encryptionPassword.toCharArray(),cookieDomain, encryptionTransformation, false);
  2. The Java application can also call the processCookie() method to extract all the attributes from a cookie object and set them in the Storage Map.

    //Decrypt OFC cookie
  3. The Java application can get values for all the attributes that are put in the Storage Map using the getAttributes(), getAttribute(), getAuthnContext(), getSessionID(), getNameID(), getNameIDFormat(), and getUserConsent() methods.


    //Read Attributes
    Map map = fedOpenIdentity.getAttributes();




  • (Test class to decrypt Federation OFC cookie)
  • (required jars from CA SiteMinder Federation SDK)



Additional Information: