I am using SiteMinder SSO 12.5 SP01 CR05 with SPS (not WebAgent) to protect my application deployed on Jboss back-end server. I am already done with the setting up SiteMinder to protected Application URL.
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? Or Do we have any dynamic variable to verify user which should be known to only SM and back-end server.
I found the perfect answer for “How to stop bypassing SiteMinder to access any SM protected application deployed on Jboss / Apache backend server”
<param-value>127.0.0.1,127.0.0.2</param-value> (Put SiteMinder SPS server IP)
With the help of mod_authz_hosts module in Apache we can restrict access to specific source IP inside virtual host. You can make changes in conf/httpd.conf and conf.d/ssl.conf under your VirtualHost entry like below example:
Deny from all
Allow from 127.0.0.1,127.0.0.2 (Put SiteMinder SPS server IP) </Location>
Refer :- http://stackoverflow.com/questions/19711716/apache-restrict-access-to-specific-source-ip-inside-virtual-host
Now only way to access your application is SiteMinder, and we are confident that SM request cannot be tampered. Enjoy Security!!!
What I don't get is -- what prevents anyone from adding this header themselves and bypassing SM entirely?
SM has feature to prevent cross site scripting from happen. If the resource is protected by SM, SM will set the header once user get access the resource (not sure during auth or az that the header set).
However, in order to answer above question, if you can share how it by pass SM then we can dig in on how SM prevents it.
What do I have to put in my server-side code to verify that the SM_USER really came from SM?
The SM_USER is a header. As per my understanding, don't have server-side code to verify the SM_USER header on where it comes from.
Hope this helps.
What is "LegacyVariables" set to? if that controls SMUSER v SM_USER
also, when do you set headers?
if you use onAuth, it is only reset on the way in during Authentication
if you use onAccess then it should be on Authorization calls
if you use a get/post/etc rule, it should be every call
obviously each impacts performance and security differently.
hope that helps.
It means I have an application hosted on Jboss for example https://servername:port/appname which is currently protected by SiteMinder. So whenever I hit https://servername:port/appname I get error because my HTTP request doesn't contain require Header parameter SM_USER. But I can hack it by using Chrome Extension "ModHeader" by passing request header and value pair "SM_USER=UserID" while accessing https://servername:port/appname
I know that this hack can be done by only internal user of organization but I want to prevent my application from unauthorized user.
Couple of ways to address this :
Another option would be to use CA SiteMinder Agent for JBoss instead of just front ending it with CA SiteMinder web agent.
This will have a tighter integration directly with the JBoss security layer avoiding the need to rely just on HTTP headers.
More here :
We are not using SiteMinder Web Agent, we have install SM Secure Proxy Server (SPS) centrally to manage all incoming request.
My comment on your suggested option below:
I will avoid installing CA SiteMinder Agent for JBoss as we have so many Jboss instances to protect.
Do we have any other dynamic variable to verify user which should be known to only SM and back-end server.
I'm also interested in the option below:
"Build a custom active response to send an encrypted value for SM_USER , App server to do the decryption on receiving."
This option seems like an interesting option and would provide the extra level security that a lot of clients are looking for. I'm actually surprised that it is not an out of the box option for CA SSO.
I have not yet evaluated the pros and cons but I see more positives than negatives here. Have you or anyone else reading this post developed or configured any encrypted active responses? I would be interested to see how you are handling that.
Hi Jean-Baptiste Jean-Jacques,
I haven't tried an encrypted active response yet but can give this a try in the near future and share it with the community.
As always it would be greatly appreciated Ujwol!