How can I trust that the SiteMinder HTTP headers haven't been tampered with?

Question

I am completely new to SiteMinder and SSO in general. I poked around on SO and CA's web site all afternoon for a basic example and can't find one. I don't care about setting up or programming SM or anything like that. All of that is already done by someone else. I just want to adapt my JS web app to use SM for authentication.

I get that SM will add a HTTP header with a key such as SM_USER that will tell me who the user is. What I don't get is -- what prevents anyone from adding this header themselves and bypassing SM entirely? What do I have to put in my server-side code to verify that the SM_USER really came from SM? I suppose secure cookies are involved...

Answer 1

The SM Web Agent installed on the Web Server is designed to intercept all traffic and checks to see if the resource request is...

1. Protected by SiteMinder

2. If the User has a valid SMSESSION (i.e. is Authenticated)

3. If 1 and 2 are true, then the WA checks the Siteminder Policy Server to see if the user is Authorized to access the requested resource.

To ensure that you don't have HTTP Header injections of user info, the SiteMinder WebAgent will rewrite all the SiteMinder specific HTTP Header information. Essentially, this means you can "trust" the SM_ info the WebAgent is presenting about the user since it is created by the Web Agent on the server and not part of the incoming request.

Answer 2

Because all traffic should pass through Siteminder Web Agent so even if the user sets this header it will be overwritten/removed

Answer 3

SiteMinder r12.52 contains a new functionality named Enhanced Session Assurance with DeviceDNA™. DeviceDNA can be used to ensure that the SiteMinder Session Cookie has not been tampered with. If the Session is replayed on a different machine, or from another brower instance on the same machine, DeviceDNA will catch this and block the request.

Click here to view a webcast discussing new features in CA SiteMinder r12.52

Answer 4

All Siteminder architectures do indeed make the assumption that the application just has to trust the "SM_" headers.

In practice, this may not be sufficient depending on the architecture of your application. Basically, you have 3 cases:

• The Web Agent is installed on the web server where your application runs (typical case for Apache/PHP applications): as stated above, you can trust the headers as no requests can reach your application without being filtered by the web agent.
• The Web Agent is installed on a different web server than the one where your application runs, but on the same machine (typical case: SM Agent installed on an Apache front-end serving a JEE Application Server): you must ensure that no requests can directly reach your application server. Either you bind your application server to the loopback interface or you filter the ports on the server.
• The Web Agent runs on a reverse proxy in front of your application. Same remark. The only solution here is to implement an IP filter on your application to only allow requests that come from your reverse proxy.

Answer 5

Typical enterprise architecture will be Webserver (Siteminder Agent) + AppServer (Applications)

Say IP filtering is not enabled, and webs requests are allowed directly to AppServer, bypassing webserver and the sso-agent.

If applications have to implement a solution to assert the request headers / cookies are not tampered / injected, do we have any solution simillar to the following?

• Send the SM_USERID encrypted in a seperate cookie or encrypted (Sym/Asym) along with SMSESSION id
• Application will use the key to decrypt the SMSESSION or SM_USERID to retrive the user id, session expiry status and any other addtional details and authorization details if applicable.
• Application now trusts the user_id and do authentication