Idea Details

Identity mapping for Federation

Last activity 12-27-2019 03:04 AM
Chris Bertagnolli's profile image
09-10-2014 09:29 AM

The bulk of our SAML applications require the capability to map an identity from one user store to another for attribute returns. Currently, the federation does not support identity mapping for Federation partnerships (like it does for Web Agents). This appears to be a very large gap in the product which is holding up moving over many applications to SiteMinder.


We request that the Identity Mapping can be applied to Federation partnerships as well for returning user attributes to Service Providers.


For example:

- Partnership is configured with:
    (1) Oracle DSEE - attributes needed to be returned: mail, cn

    (2) Active Directory - attributes needed to be returned: uid, telephoneNumber, ou

- An identity mapping is configured for mapping uid between the two directories


I want to have the partnership return the full set of attributes between the two directories (mail, cn, uid, telephoneNumber, ou), no matter which one the user logs in with.


- User accesses the SP and is redirected to the IdP

- User selects to log in at IdP with their Oracle DSEE account

- Authentication passes, SiteMinder maps the user based on uid to Active Directory

- SiteMinder generates the assertion including all the user information (mail, cn, uid, telephoneNumber, ou)

- User POSTs the data back to the SP

- SP processes response which includes all the attributes required

- User successfully accesses application at SP



Note: Using a virtual directory or custom assertion plug-in is not an option, this functionality needs to be built into SiteMinder.


06-19-2018 09:41 AM

Unfortunately, for us at least, not sure this will ever be used. Since CA takes too long delivering enhancements, we almost always end up with another solution by the time it get delivered (like this one) ....4+ years is too long waiting on a partial delivery when there's free licensed products that already do this (such as ADFS which we are using more and more instead of CA SSO due to lacking key functionality).


If CA is to stay competitive and keep current customers on the products, enhancements have to be implemented in a timely fashion.

06-19-2018 06:12 AM

Hi Ravi Kumar,



In which version of CA Single Sign on it is available? will it work on R12.52 SP1 with some CR to upgrade?

06-19-2018 04:25 AM

We are considering "Authentication with one user store and authorization with other user Store (generate attributes from second user store" as part of current planned development.  More details will be posted to CA Single Sign-On validation project (  Please access the content in the validation project and provide your feedback 

06-19-2018 04:22 AM

Thank you for your contribution of an enhancement ideas to the CA Community. CA is continually working to improve its software and services to best meet the needs of its customers. Your input is vital to that effort. The CA Single Sign-On Product Management team has reviewed your suggested enhancement and is pleased to inform you we have decided to incorporate your some elements of your idea.  We are projecting the GA of this idea in 14.0. Thank you for your contribution to the progress of CA Single Sign-On

04-27-2018 03:47 PM

Just an added note for the community........


There is an OOB feature in CA SSO called "IDENTITY_MAP". This feature is not a replacement for IDENTITYMAPPING or DIRECTORYMAPPING.


"IDENTITY_MAP" is a reserve word which can be used in an expression to trigger an IDENTITYMAPPING Object without having to select a mapping. 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.


I'll add some screenshot of basic configuration as time permits, until documentation is updated.


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 have recommended you 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. If you are willing to do through the entire process, then Yes it is something I'd recommend to look at OOB.


Additionally as I mentioned we (I / along with KB) 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.


Thought I share this so as to make it helpful to the community that there is way out from not having to write custom AGP to read from a Second Directory (Check CA Support Matrix for Directory compatibility).


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


Lastly the Ideation is still valid for the use case it serves. But there is another way to do it using IDENTITY_MAP reserve word in Expression.



CA SSO : IDENTITY_MAP expression reserve word usage / configuration 

03-27-2018 06:27 PM

Aaron AaronBerman


Thank You!


VERY INTERESTING IF THIS WORKS, stay tuned..........

KB 'Kaladhar' and me are trying to decipher the puzzle you suggested. Hopefully we are deciphering this in the right direction.



Directory Mapping Examples - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation 

Identity Mapping by Complex User Search Criterion

Identity Mapping locates a user by relying on the session ticket information and the construction of the identity mapping entries.

The XPS function IDENTITY_MAP finds the Identity Mapping object by name. On finding a user in the target user directory by resolving its entries, returns the value of the attribute specified by the second parameter.


To get the last name of the user in the target user directory defined by the Identity Mapping named “target”, provide the following:

IDENTITY_MAP ("target", last_name);

We created an IdentityMapping called "target". Within IdentityMapping we selected Authentication-Authorization mapping and created an IdentityMappingEntry called "target-az" with UD1 as Auth and UD2 as Az with UniversalID.


Then we go to UD1. Create an Expression using User Attribute called "test-expression". In the Expression add "IDENTITY_MAP ("target", AttributeNameUD2"). Because we want to read AttributeNameUD2 from UD2.


In the Partnership we associated UD1 and we used simply Assertion Attribute as User Attribute and used "test-expression".


To our surprise this kind of worked to some extent. It atleast invoked the identity mapping using the expression, whereas in partnership there was no IdentityMapping configured, but not fully working yet. We are still investigating. Would keep the forum posted.


So it may seem we made a head way without making a public statement of how Identity Mapping in Federation Partnership is supposed to work. We haven't got it to work E2E, But if this work, this is amazing because we don't have to associate a Mapping to a realm factor and just use Expression. What makes it more lucrative and spectacular would be the ability to Pass Attributes from AuthDir and AzDir at the same time in Assertion Attributes.

03-27-2018 05:25 PM

Hi Aaron,

    please elaborate on how this can be used for partnership scenario and without enabling the identiy mapping at realm level for redirectjsp/redirect.jsp URI.

03-26-2018 02:07 PM

In most cases you can use an ID Mapping tied to an expression to achieve the results to "pull in" user data from a second directory to place into your assertion.

02-19-2018 09:47 PM

Is there a date on when this feature be released ?. its been in review stage for a while and highest voted one in ideas section. why  is this idea not implemented whereas others which have less votes have been implemented ?

01-15-2018 09:29 PM

For now, the standard guidance for this is with custom Assertion Generator Plugin. There's general documentation provided for this in docops.

Regards. - Vijay

01-12-2018 06:27 PM

Thank You dcer for circling back and suggesting. Such a sweet little tweak to make this work.

01-12-2018 04:54 PM

Hi Dennis. Within the partnership's backing Domain's Realm object, the CA.SM::IdentityMapping's XID is an XID LinkValue within the property CA.SM::Realm.AuthorizationMappingLink. Hope this helps!

10-23-2017 11:58 AM

Josh - That kind of detailed assertion helps! The initial comment felt like a possibility, hence my thought on it may not work even if the link is established. But the latest comment asserts that this has been vetted out in the field (and it works minus the supportability clause!). Hence it adds weightage that this is a quick fix to formally support it.


For the benefit of understanding, whenever there's a moment, May I put in a request to list where did we add the mapping to the realm using XPSExplorer? I can think where, but just want to be on the same page.


Thanks again Josh!

10-23-2017 11:56 AM

I know that this is what CA is obligated to say, and there are definitely risks accepted with implementing a custom, non-supported solution like this.


That being said, we implemented this several years ago, because we could not wait for the official functionality. (Which may or may not come)


I am not advocating that anyone else do it, I am just saying that if you are comfortable with XPS, it is technically possible.


It is not always possible to wait for years for needed functionality to be put in place. Our organization has had SSO deployed for 15+ years. We have learned that it is sometimes not feasible to wait for several years for an idea to be upvoted and implemented. This is a good idea, and a valid use case, and it has been sitting for 3 years now collecting votes.

10-23-2017 11:29 AM

The partnership model creates many underlying objects which is hidden, beyond just the partnership object. Tinkering the hidden objects may potentially render the partnership code logic that runs on the WAMUI front-end unstable. Further more doing an unsupported configuration the risk is two fold. If one is very comfortable with the underlying XPS schema / Data definition linkage, using XPSExplorer, then we could give it a shot (but it would still be unsupported as, sometime a link may work, but the code may not exist to cover the functionality).


I'd attempt this only on a Sandbox ENV to assist engineering with a path to investigation. Not in a DEV / TEST / PROD.

10-23-2017 11:01 AM



I think you can do this, albeit in an unsupported way, by adding the mapping to the realm that is created by the partnership in XPS.

11-21-2016 10:42 PM

If you are just looking to pass data from other directory as SAML attributes, you can write custom SAML assertion generator where in you can fetch uid from the original saml assertion and then make a LDAP/ODBC call to other Dir to fetch other data elements (like telephone number in your case) and create new saml attributes for additional data elements.




09-06-2016 02:45 PM

We have moved this into the under review category as we start looking at potential candidates for a future release.

01-31-2016 11:54 PM

I am unable to view the above cases getting the below error, I have full access to CA support.

please help me


Please complete the required fields highlighted below:

You do not have access to view case 00050144.

12-09-2015 09:58 PM

I've implemented the Radiant Logic Virtual Directory product now, but I

may reach out to you for some guidance, should this still be necessary.



Thank you!


Eric Anderson

Technical Security Services

Information Security Risk Management

Health Care Service Corporation


Phone:312-653-1050 (Single Number Reach)


12-09-2015 09:43 PM

You can resolve this issue by writing custom assertion generator plug-in. I have implemented for this kind of scenario using custom plugin. Check more detail in Customizing a SAML Assertion section of documentation and samples in case if you need help or guidance let me know.

11-06-2015 02:40 PM

It was confirmed for me that FedMgr doesn't support identity mapping. So,

until I present the aggregate view via my VDS, I won't be able to make

that work.

11-06-2015 02:35 PM

Thank you for your contribution of an enhancement idea to the CA Community. CA is continually working to improve its software and services to best meet the needs of its customers. Your input is vital to that effort. The CA Single Sign-On Product Management team has reviewed your enhancement suggestion and decided to maintain the idea for possible consideration in a future release. The Community will continue to be able to vote on this enhancement idea.

03-20-2015 07:37 PM

Chris CBertagnolli


Am not sure what version you folks are on. However since you've mentioned IdentityMapping, there are currently 2 issues which I've logged with CA support. You may need to take care of these if you are using Identity Mapping else where in the solution. These are being fixed, so it should be available in upcoming releases.


00046619: Identity Mapping UI Display

00050144: IdentityMapping and XPSExport

01-05-2015 10:51 AM

I have the same issue. Our Authentication schemes typically come from Active Directory, but most of our authorization data is not in AD. I requested this feature via our account team earlier in December. Hope it helps!