Hubert Dennis

CA SSO : IDENTITY_MAP expression reserve word usage / configuration

Blog Post created by Hubert Dennis Employee on May 14, 2018

There is an OOB feature in CA SSO called "IDENTITY_MAP" which many of us are unware and the documentation only does a feature touch revelation about this feature.


Before we begin, it is very important to understand the difference between these terms.

  • Identity Mapping and/or Directory Mapping.

IDENTITY_MAP feature is not a replacement for Identity Mapping or Directory Mapping.


Identity Mapping and Directory Mapping serves a different use case wherein we'd like the authorization to be restricted to Authorization Directory and pass responses only from authorization directory. Thereby we associate or link the Identity Mapping or Directory Mapping object within the realm of a Policy Domain. Which enables the authorization directory to be visible in the policy.

"IDENTITY_MAP" on the other hand is a reserve word which can be ONLY used within an expression to trigger an Identity Mapping Object without having to associate a Identity Mapping or Directory Mapping within a realm (Policy Domain) or within Partnership (Federation). We recently unit tested the functionality using Federation Partnership which does not support Identity Mapping or directory mapping as of date. We also unit tested using a Policy Domain without having to associate a mapping within a realm in the Policy Domain. All we needed to do was trigger the MAGIC WORD using an Assertion Attribute in Partnership and Responses in Policy Domain.





Step-1 : Create the Authentication Directory and Secondary Directory.


Step-2 : Populate UniversalID attribute for Authentication Directory and Secondary Directory.



Step-3 : Create Identity Mapping Object.


Step-4 : Create an Attribute Mapping Object within ONLY Authentication Directory.



Expression :

IDENTITY_MAP ("TargetIdentityMappingRootObject", businessCategory)


Syntax :

IDENTITY_MAP ("Name of Identity Mapping Root Object", Attribute to be read from Secondary Store)



Step-5 (a) : For use within Partnership.



Step-5 (b) : For use within Policy Domain.






Word of Caution at this moment in time.


The feature exists since R12.5. The feature is broken in R12.51 / R12.52 / R12.6 / R12.7 / R12.8, with 0.1% documentation. We received a fix in R12.52 SP1 CR04 / 05 as a DevFix for our Customer and functional / unit test for Federation Partnership worked. We have requested a fix in R12.8. As of back porting the fix, we have requested it be back ported into R12.7.


I'd recommended to use and test this feature, but currently there is some level of overhead to get the feature working. Raise a support case, get the devfix, do functional test, do Load and performance test (because it has been unused and broken for a long time) and then PoC your usecase. The feature does negate the need to write Custom AGP to read attributes from a different directory other than the Authentication Store. Check CA Support Matrix for Directory compatibility when adding User Directory.


Additionally as I mentioned we only tested a few basic unit tests i.e.

  • Using Assertion Attribute in Partnership and Response in Policy Domain.
  • Using Auth-Az entry in IdentityMapping Object.
  • Using an Expression AttributeMapping in UD.
  • Using only AuthDir in Partnership and Policy Domain (no where in Partnership nor Policy Domain we had to link AzDir).
  • We haven't tested the full length and breadth of the feature e.g. we can multiple Identity Mapping entries (Auth-Az / Auth-Validate) within an IdentityMapping object.


As mentioned the feature exists, but we have to evaluate each end user use case, as to if it can be solved by IDENTITY_MAP reserve word in Expression.