Siteminder Agent for IHS / Websphere

[Deactivated User]

Hi everyone, I am working for the first time with Siteminder. We have an application running IHS and Websphere 8.5.5. The IT guys from the client installed, as they said, the agent for "IHS" only and not for Websphere.

 

My question is simple, the ASA for IHS is the same for Websphere as well (the install is unique for both or there is one agent for each (one for IHS and one for Websphere)? 

 

I am asking because as soon as I created the Trusted Association Interceptor on the Websphere, the app broke and was always stating internal error 500.

 

Thanks!

[Vijay Masurkar]

Yuri, No. For, IHS web server based app, you need a standard Apache web agent. But if you're protecting IBM WebSphere based apps / resources, then you need ASA (Application Server Agent).

- Rgds. Vijay

[Ashok kumar Muthu]

If your IHS is front ending all of your applications which are deployed in Websphere, then you just need regular webagent on IHS server which will take care of your application security/SSO. No need of ASA here.

 

 

ASA is needed when you don't have IHS server and access the apps directly from Websphere or-else you have special requirements.

[Deactivated User]

Thank you very much for the answer Ashok. Today I found as well that the client usually uses as you said, web agent only for front end of all apps deployed on websphere. They say that they use it as a reverse proxy. My question what is exactly that I need to configure on the websphere side, because when following this document here ( https://support.ca.com/cadocs/0/CA%20SiteMinder%20Agent%20for%20WebSphere%20r12%20SP2-ENU/Bookshelf_Files/PDF/SMWebSpher…  ), right after configuring the Login modules (pages 85 onwards), all servers didn't start anymore because it didn't find the classes for it.

 

Do I need the TAI only? Could you please help me?

 

Tyvm!

[kenpe02]

The ASA for WebSphere gives you tier 2 authentication from SiteMinder.

If you don't have it and just use the web agent on the IHS reverse proxy, then you are relying on network and other controls to prevent users bypassing the reverse proxy and spoofing whatever http header the proxy passes back to WebSphere to provide the authenticated user's context.

 

By using the ASA, it will validate the SiteMinder cookie with the Policy Server, thus preventing bypassing of the reverse proxy and header spoofing. Pages 14-15 of the doc you linked to explain which components you need. It's a long time since I've done this, but in previous projects where I did it, we only deployed the TAI component for http authentication. We didn't need the login module as we had no use cases for it and we didn't need the JACC provider as we let WebSphere handle the authorization natively