SiteMinder and HTTP : security issues (Legacy_Onyx KB Id: 221888)

Products

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

Issue/Introduction

Description:

We plan to migrate our web application from HTTPS to HTTP, but have some security issues for which we hope you can help us.

Our application is composed by 4 Domino v5.0.12 web servers with SiteMinder v5 web agent installed. A load balancer is responsible for distributing client requests among all servers using HTTP protocol. Clients communicate with the loadbalancer using HTTPS protocol. This can be drawn as shown :

[Client] <-- Internet/HTTPS --> [LB] <- LAN/HTTP -> [Web Server/Web Agent]

The target architecture is to migrate client / LB communication from HTTPS to HTTP. But this leads to some security issues : as the SMSESSION cookie is sent over an unencrypted channel, an unauthorized client could hijack the communication, and use the cookie to gain illegal access to the application, as well as all other applications in the same authentication realm. This is not acceptable by our security officiers.

We believe the IP Checking feature on the web agent would not work, as the web server is not aware of the client IP address, only the load balancer's one. Can you confirm this assumption ? Are there any workarounds applicable to our configuration ?

Do you know other settings or features in the web agent or the policy server to add more security to thisconfiguration ? For exemple, is it possible to have the SMSESSION cookie be renegociated periodically during the user session, or validated by the policy server using other identification means than the client IP address ?

Solution:

regarding your first question on IP checking :
- some load balancers allow to forward the client IP address, in such case, you would be able to perform IP checking but needs to be tested at your load balancer level.

on HTTP to make the session more secure,

- if you set up the session store then all sessions are tracked inside the db. when a user clisks the logoff URL it will invalidate their session and thus presenting a hacked SMSESSION would fail

- you can lower the max session time out which then request for a new user login and then a stolen cookie would be valid for less time.

unfortunately, switching from https to http you will lose some cookie security.

Environment

Release:
Component: SMPLC