We have 12.52 SP1 here. We also have some applications that use Kerberos and others that use NTLM for authentication... What we have noticed is that when a user initially "logs into a Kerberos application" in Siteminder, the sm_user value is in a userPrincipalName format. When a user initially "logs into a NTLM" application", the sm_user value is that of "<Domain>\<UserID>".
The problem we are seeing is that if a user logs into a Kerberos app, then tries to switch over to an NTLM app (both protected by Siteminder), the NTLM app sees the userPrincipalName value when it's expecting the "<Domain>\<UserID> format and that causes problems for the NTLM application.
Is there anyway to force a re-authentication to reset the SM_USER value when a user switches between a Kerberos application and a NTLM application? Or is there a better way to handle the situation? I believe a couple Kerberos apps are configured to set a persistent cookie which also may add a complication.
How would be the best way to handle this sort of issue?
Thanks in advance!
One added piece... I was recently informed that this could be resolved by purchasing the SmOverrideAuth module. Is there really no other way to handle other than purchasing a module?
CA Services has an offering in this area entitled "Override Authentication Login for CA Single Sign-On". I have listed an overview of its functionality below. If you have interest please reach out to your CA Account representative to setup a proof of concept or to obtain a quotation for the packaged work product.
Many times, customers first implement CA Single Sign-On using simple, user name and password-based authentication schemes. In their initial implementations, it is also common for customers to make use of the SM_USER header variable to identify users to their web applications.
As they expand their site, customers may identify new requirements for authentication, such as the need for NTLM authentication or more secure authentication schemes like Certificate Based Authentication. Implementing these schemes poses a problem because the CA Single Sign-On Certificate Authentication scheme does not provide a value for SM_USER, and NTLM changes the format of SM_USER to domain\loginID. This causes web applications or other backend applications to fail because they are not getting the type of user loginID expected.
Override Authentication for CA Single Sign-On solves this problem by providing a mechanism to automatically and securely re-authenticate users with a configurable loginID value which gets set as the value of SM_USER.
Override Authentication for CA Single Sign-On allows customer to make use of new authentication mechanisms that don’t populate SM_USER in the standard way without having to modify applications that rely on the SM_USER value.
A sample use case would be:
A list of technical prerequisites for this packaged work product can be found at CA Support online. This is a central repository that will help you identify CA Technologies product compatibility with operating systems, other third-party software products, as well as with certification standards and regulations. Contact your CA Services representative for further assistance with purchasing this component.
If you want to permanently change the value of the login ID that is stored in the SiteMinder SMSESSION cookie, then SmOverrideAuth ("Override Authentication Login for CA Single Sign-On" ) is the way to go. If you are OK with setting up responses for every app that needs the user's loginID then you can override SM_USER with a response, or better yet create a response with a different header variable name and modify your apps to use your custom header variable name. With any of these three approaches you get to choose any user attribute value as the "LoginID" value.