Worked previously on HTTP Headers Redirect Mode, however recently encountered a special use-case and spend an awful lot of time debugging. Hence saving the trouble for others.
Use case : When SP Side uses CA SSO and needs to set SM_USER Header (e.g. SM_USER is sent as an Assertion Attribute by IdP within SAML Assertion).
This situation typically arises when
We would not go into details of configuring HTTP Headers Redirect Mode and SMSAMLData Plugin configuration. As they are well explained in blogs.
Step by Step: Facebook partnership
Step by Step: Facebook partnership 2
SMSAMLDATA cookie
For people who know siteminder, we’d know that WebAgent use HTTPPlugin to process every request. Therefore in WebAgent.conf by default LoadPlugin for HTTPPlugin is enabled. Now for WebAgent to decrypt SMSAMLDATA cookie and set the contents of SMSAMLDATA cookie as HTTP Header, we have to enable an additional Plugin called SAMLDataPlugin in WebAgent.conf.
Now both these plugins are loaded within the WebAgents process memory and both these plugins set headers. Therefore if both plugin try to set the same header, one would override the other. The crux of the matter is if SMSAMLDATA cookie contained any SM_ Header, it would be reset by HTTPPlugin. This mainly due to the way CA SSO controls its default headers at WebAgent layer.
I have attached a log from a Single Txn Thread in the attachment below. As you can see the following sequence occurs.
Line-1 : CA WebAgent on SP's TARGET gets a new request with both Cookies in the Browser i.e SMSAMLDATA and SMSESSION.
Line-3 to Line-13 : We see that HTTPPlugin handle the requests as it does OOB.
Line-14 to Line-44 : We see that SAMLDataPlugin kicks in. It finds a SMSAMLDATA Cookie in the Request Stream. Decrypts it. Picks all the values from Cookie and sets them as headers. At this stage we all headers being passed from Federation to Target Application e.g. see test_header=helloWorld and SM_USER=joeblogg etc.
Line-45 to Line-47 : SAMLDataPlugin delete the contents of SMSAMLDATA cookie and issues a new blank cookie.
Line-48 onwards : We see that HTTPPlugin takes over. Does validation of SMSession Cookie. Authenticates. Resets SMSession Cookie. Authorizes. This process resets the value of SM_USER=joeblogg to SM_USER=user1.
Is there a Workaround / Solution : If Service Provider Application Team still needs SM_USER as set by the Identity Provider - YES!
The Solution is to adopt Session Store and using “Configured Responses” on Policy Server to read and set SM_USER from the Policy Server. A configured Response on Policy Server ensures the fact that WebAgent honors what the Policy Server tells it to do, because WebAgent is a Policy Enforcement Point (PEP) the fulfiller and Policy Server is a Policy Decision Point (PDP) the decision maker. Therefore when we configured a Response (read from Session Store) as SM_USER on Policy Server, on successful Authorization Policy Server tells the WebAgent to set a HTTP Header called SM_USER with the value from Session Store i.e. SM_USER=joeblogg. Thus now the WebAgent’s default SM_USER=user1 from SMSession was getting overwritten by SM_USER=joeblogg from SAML Assertion / Session Store.
Is there a alternative Solution to adopting Session Store : YES!
Change application code to read from a different header e.g. LOGGEDIN_SMUSER and request Identity Provider to send LOGGEDIN_SMUSER as an Assertion Attribute.
Hope this help understand the implications, interworking of different modules loaded within same process space, saves someone troubleshooting and jump directly to designing a robust SSO Solution using CA SSO.
Regards
Hubert