I'm trying to authenticate on my web application deployed on a jboss working in cluster mode with 2 nodes.
After a succesful authentication I get redirected to an admin page where a Filter checks if I am logged in.
On standalone mode it works just fine but when I deployed into production, which uses cluster mode, the filter rejects my request because it can't access the session parameters I have established on authentication.
Using the developer tools I see there are 3 JSESSIONID cookies set: one for /, one for /myapplication path and another one called JSESSIONID-34234 also for /myapplication path (I've cleared all them before starting the process).
Browsing the jboss docs I can't see no explanation for this although it seems the source of my problem.
How can I get to work authentication (I am using spring security http form based authentication) in my JBoss cluster?
Solved by enabling sticky session by adding the following to the virtualhost configuration file:
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/myapplication" env=BALANCER_ROUTE_CHANGED
<Proxy balancer://jboss6-hc-001-8109>
BalancerMember ajp://jboss2.imatiasl.lan:8109 route=jboss2-hc-001-server-02
BalancerMember ajp://jboss3.imatiasl.lan:8109 route=jboss3-hc-001-server-02
ProxySet lbmethod=byrequests stickysession=ROUTEID
</Proxy>
Web session clustering should work if:
You enabled <distributed/> in web.xml.
Your app's server group is using ha or full-ha profile
If you want your clustered app perform better, consider implementing a good load-balancing policy. For most webapps load-balancing with sticky sessions is OK.
In some webapps, it is enough not to ask for re-authentication in case of failover or session is very easy to rebuild if authentication info is available. In such cases you even don't need web session clustering. Clustered SSO is enough, the caveat is you'll have to use container level security for authentication (most probably supported by spring-security). This way only authentication info is replicated, so you'll have to design session data management to be resilient to situations, when session suddenly becomes empty.
Related
I have a JavaEE application deployed in Payara application cluster with more than two nodes. Application uses Keycloak servlet adapter to enable integration with Keycloak. I have Keycloak 11.0 deployed in production with domain clustered mode. I have manually registered application cluster nodes under application clustering section of client configuration. I used ${application.session.host} in admin URL to enable keycloak to send back-channel logout call to appropriate cluster node. Load balancer with sticky session is used in front of application cluster to provide single node view and distribute requests. Everything works fine.
Now, I need to upgrade Keycloak to newer version, I am trying to upgrade to 18.0.2 (legacy version). However, newer version complies to OIDC Back-channel logout standard, and have separate config parameter under client configuration for back channel logout, separate then admin URL.
The problem is my clustered system doesn't work with this, back-channel logout param doesn't support ${application.session.host} in URL. Consequently, back-channel functionality breaks.
Moreover, Servlet Filter adapter implementation from Keycloak doesn't support handling back-channel logout as per my knowledge. I have implemented my own library to handle back-channel call: validating things as per standard and logging out appropriate session. For this sake, library stores sessions in an application scoped bean. In single node deployment of application, everything works but I don't have solution for multiple node application deployment from Keycloak regarding this, because Keycloak wouldn't know which node back-channel logout request would go, considering the fact that application deployment on each node is independent and client request distribution is configured with sticky sessions.
One solution is to use the Payara inbuilt Hazelcast datagrid to store the web sessions, and then any node should be able to handle the back-channel logout call across cluster.
But I am interested to know If keycloak has any solution on this.
In our project we are using weblogic server.
If I try to login into our application i.e on machine A, a JsessionId is generated after I logged in.
Now, if I use this same JsessionId on another machine i.e machine B the application will prompt me to home page instead of login page.
Please provide a solution for my problem.
Unless otherwise configured, most servers will destroy any JSessionID it does not recognize and issue a new one. This is to prevent Session Fixation attacks. Java Servlet Engines like Tomcat and Jetty do so as will various j2EE Application Servers such as WildFly(UnderTow) and WebLogic.
If you want to have a session migration between servers nodes you will need to configure your server to do so. Servlet Engines and Application Servers will not do so automatically. You will need to look at your Weblogic docs for your version of your Application Server to determine how to do it.
I will tell you that Wildfly and Tomcat definitely require multicast-ip to make this work. Depending upon your environment it is possible that multicast-ip is blocked by firewalls. Additionally I know, as of this writing, that docker containers do not support multicast-ip out of the box so you will need some sort of work-around if you are using docker containers.
The important thing is that you understand why the session is not automatically migrated and that you need to configure your server to do so. If Weblogic uses multicast-ip that might be another hurdle to overcome.
I hope this helps. This is as specific as I can be as I am not a Weblogic developer.
What you have stated is called session hijacking. There are many good answers on how to prevent it.
Prevent session from being replicated when JSESSIONID cookie copied
What is the best way to prevent session hijacking?
HTTP being an stateless protocol uses a session identifier (mostly a cookie) which is sent with every request which to identify the client. The most common way is to use HTTPS to encrypt your request and prevent anyone in the middle from seeing that session identifier.
One important point to consider is that if the attacker has physical access to your machine, then he/she can easily see your session identifier and there is nothing you can do about it. That's the reason why websites like facebook warn you when you open the browser console and run some scripts.
Our IT staff refuses to install the SiteMinder agent on our application's IIS 6.0 web server, citing security concerns as it is a third-party software, as well as the possibility of high resource utilization impacting application performance.
They suggest that we set up an independent, segregated web server containing only a bare-bones IIS, the SiteMinder Agent, and a "shim" to authenticate login attempts.
This shim would be a single ASPX page marked to be protected by the agent. It would use the SiteMinder agent to authenticate the user ID, look up the user ID in the application's database, and return the user ID and password to the user's browser. A JavaScript function would then POST the user ID and password to the application's existing login page as if they typed it in themselves.
Are their concerns warranted? Why or why not?
Have you ever heard of anyone implementing a similar architecture?
Is their proposed solution good, bad, or ugly?
It does not look like it would work, because the agent manages not only the initial login, but subsequent calls to the application, i.e. authenticated session. The agent examines the cookie, validates it, etc. Your scenario does not describe how that would happen.
In our environment, all internet traffic goes through an Apache reverse proxy before hitting IIS. IIS is behind firewall. The Apache reverse proxy has the SM agent all it does is redirect the traffic to IIS. I suppose it would be feasible to do a similar setup with IIS acting as a reverse proxy.
BTW, tell your IT guy that his proposed shoestring and bubblegum login solution is a much bigger security concern than installing SiteMinder on IIS.
The apache reverse proxy solution will definitely work, but with SiteMinder r12.51, Secure Proxy Server is included, which is basically SiteMinder's version of a reverse proxy (plus a lot more).
SPS will let you configure a single server as a "gateway" for all of your applications that can't or won't install a SiteMinder agent. The web agent is embedded in SPS and a proprietary Java app does the heavy lifting. SPS also has a GUI which follows the look and feel of the r12 WAMUI, which makes configuring it very simple.
Secure Proxy Server also has a Federation Gateway feature, so you don't need to install the web agent option pack if you are doing SAML Federation. All of your fcc pages can also be served by the SPS, so you can reduce the number of webservers needed to support your SSO environment.
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...
The SM Web Agent installed on the Web Server is designed to intercept all traffic and checks to see if the resource request is...
Protected by SiteMinder
If the User has a valid SMSESSION (i.e. is Authenticated)
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.
Because all traffic should pass through Siteminder Web Agent so even if the user sets this header it will be overwritten/removed
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.
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
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
I've looked the web through and through in the search of answer to my problem but with no result so I reckon that's the ultimate place when anybody can have a clue what the solution might be.
Long story short: we have a jsf web application running on JBoss 4.2.0 GA server. We are in the process of replicating the application to several servers which is generally a smooth ride with just one single exception: JAAS. We use Jaas as our security mechanism but can't get the Jaas session replicated. When load balancer switches user to different server, the user has to log on again (however the jsf session state is not lost, it's gets replicated with no problem). How can we get Jaas to replicate its session over several servers? Is it possible in a stright way?
Or do we have to tinker with programmatic authorisation, which in case of Tomcat, seems to be possible only by reflection?
You need to look in cookies. Better to use some HTTP protocol sniffer.