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.
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
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?
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:
Hope this helps