0

I have to give my recommendations for an architecture for SSO using Site Minder. We have few J2EE applications. These J2EE applications are designed to work when http headers have information after authentication by SSO provider. We have kept our applications SSO provider agnostic. This means we only rely on headers from SSO provider. This worked well with RSA as the SSO provider.

enter image description here

Now there is another architecture proposed with SiteMinder. The way request will flow is

SiteMinder with IIS -> Apache Reverse Proxy -> Tomcat Application -> Backend Applications.

To break down we will have

a) SiteMinder with IIS (public facing site)

b) Apache Reverse Proxy ( For routing)

c) Tomcat Application (For routing and a logic for site access based on time)

d) Backend applications

enter image description here

The reason for bringing the new architecture is that all back end applications have code for site access. The site can be down for some time, which is controlled by a property file.

I find this architecture wrong. I do not understand why Apache Reverse Proxy is requried. I would still go with simple architecture with flow as a) SiteMinder with IIS doing the routing -> Backend Applications(accessing a common service to check whether site can be accessed or not)

Am I missing something?

Vishal Singh
  • 101
  • 1
  • 7

2 Answers2

2

The Apache reverse proxy would make it easier to load balance between multiple IIS instances. As far as I know to do something similar on IIS you would need to use the ARR (application request routing) module which won't be optimised to work with Tomcat etc.

However, the SiteMinder with IIS does seem an added overhead in your architecture. The Apache reverse proxy also supports SiteMinder agents. Why don't you push for setting up the SiteMinder agent on the Apache proxy and remove IIS completely from the picture. I can think of the following benefits:

  1. Remove one extra layer from the architecture
  2. Remove an extra network hop
  3. Clean up the stack. Apache + Tomcat is very standard in enterprises while IIS + Apache + Tomcat definitely isn't.

Hope this helps

Avi
  • 406
  • 2
  • 8
  • Thanks AvijitAjay. IIS with SiteMinder will have to remain as this is the standard for the organization. I think my question did not make it clear that the bank already uses IIS with SiteMinder for many other applications. The SiteMinder with IIS allows them to implement security policies across the organization. My take was given that as we cannot remove IIS and Siteminder best would be to to eliminate Apache Reverse Proxy and Tomcat Application. – Vishal Singh Nov 27 '14 at 14:32
  • I am assuming from the "public facing site" comment in the diagram that IIS is directly connected to the Internet and does not have any load balancer in front of it. If that is the case, it will be good to have the IIS in place to act as the layer where all validation needs to be passed before the user can enter the next network zone. As I mentioned earlier, Apache + TomCat is a very good combination for load balancing and failover and if IIS is being used as the endpoint for the public IP, then this architecture looks ok to me. Just my two cents. – Avi Nov 27 '14 at 15:35
1

I don't see either the rationale behind the second architecture. The first scenario is a much more common deployment of Siteminder.

Be aware that this kind of architecture potentially opens vulnerabilities (logon bypass notably). See my answer on this question. Those remarks are true for both architectures.

Community
  • 1
  • 1
sk_
  • 2,105
  • 17
  • 31