When we use Integrated Windows Authentication (IWA), the user name returned by SiteMinder is in the format <domain>\<user name. We have some applications expecting the user name to be returned without <domain>\. In this instance using a custom header does not resolve the issue since the application uses the SMSESSION for authorization. Therefore the user name is being read from within the SMSESSION cookie.
Please suggest possible ways we can prevent <domain>\ from being a part of the user name when we use IWA.
Please refer : http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec456586.aspx
Thanks for the response. However our application is not reading an HTTP Header but rather the user name from within the SMSESSION cookie. Therefore creating a custom header does not resolve this issue.
this and an OOTB IWA with Forms Fall back are very common. i wonder how many votes we need for visibility
see also: SiteMinder Integrated Windows Authentication Improvement
There is another option. If you really need the value stored in the SiteMinder SMSESSION cookie modifed to be just the loginID, without the domain prefix, there is a CA Services, Global Deployment Pre-built PWP (aka module) called SmOverrideAuth that will meet this requirement. It actually allows you to set SM_USER to the value of any attribute in the user's record, although normally the loginID is used. Note however that this is a separately priced item, it is not part of core SiteMinder. You can contact Sid Mautte (Sid.MautteIII@ca.com) if you would like to find out more about this module, or you can contact your CA Sales Representative and ask them to open a Service Request for SmOverrideAuth.
Just to clarify one point, when I said that "It actually allows you to set SM_USER to the value of any attribute in the user's record", what actually happens is that an active response fires on an OnAuthAccept event, causing a redirect to an FCC that triggers a new authentication via the SmOverrideAuth auth scheme. When the FCC is accessed, another active response fires setting the "username" field of the FCC to the user's loginID or the value of any user store parameter and puts an encrypted token into the password field. The auth scheme will only signal success if it gets an encrypted token it can decrypt, and if the user identity in the encrypted token matches the username set in the FCC. The net effect is that a new SMSESSION is created with a new loginID in the cookie which doesn't have the domain prefix in it.