How to get the SM_USER http header populated when using CERTIFICATE based authentication schemes.

Products

• CA Single Sign On Secure Proxy Server (SiteMinder)
• CA Single Sign On SOA Security Manager (SiteMinder)
• CA Single Sign-On

Issue/Introduction

When a CERTIFICATE based authentication scheme is implemented, instead of the SM_USER http header being populated, the SM_USERDN http header is populated.

This could cause problems where there are applications that have been coded to look for the presence of the SM_USER header for personalization of the look and feel.

Environment

Release:
Component: SMPLC

Resolution

When using certificate authentication, the SM_USER variable does not get set. The reason is that certificate authentication is different from the other authentication schemes.

With forms and basic authentication, the user manually submits his credentials when prompted however if you are using certificates, the webagent sends a hash of the certificate to the Policy server which then decrypts it and decides based on the Certificate Mapping on what credentials to use to authenticate the user. However, the correct value that should be used to identify a user when using certificates is to use the SM_USERDN value. SM_USER If the authentication method associated with a realm accessed by a user requires that the user provide a username, the Web Agent places the username in an SM_USER http header variable.

In cases where the user does not provide a username, such as certificate-based authentication, the value of the SM_USER header variable is not set.
SM_USERDN For an authenticated user, the Web Agent populates this http header variable with the DN as determined by the Policy Server. In the case of certificate-based authentication, this attribute can be used to identify a user.

This is a known and well documented product limitation.

There are possible ways to achieve the required solution.

1. Purchase SmOverrideAuth module from the CA Services, Global Deployment, Components Team (aka GSE). This is an extra cost module that was designed specifically to solve this problem. It performs a secure, automatic re-authentication of the user, resetting the user's loginID and their SMSESSION cookie and in the process, which then allows the web agents to populate SM_USER correctly. This solution executes at login. Thereafter there is no performance impact.
   
   If the customer wants to pursue option number 2 they or their CA Salesperson.
   
   
2. They can use global or local OnAccessAccept rule(s) tied via a policy to a response that populates SM_USER from some attribute in their user store. The customer should check with CA Tech Support to determine if this is a supported solution. If not, then the customer can go ahead and implement it at their own risk. This solution involves firing a response the first time every resource is authorized.