locked
IAG and WebSeal? RRS feed

  • General discussion

  • I am working on a project trying to integrate IAG and WebSeal. WebSeal (as far as I can understand) is essentially a web SSO type product. You login, you get a cookie, you're authenticated, etc. 

    It's my understanding that the WinHTTP repository type was created for just such an occasion, right? You give it a URL that generates an HTML 401 response and IAG forwards the creds and gets the cookie. Isn't that how it's supposed to work? Well... suprisingly, it does not. 

    Right now, I have a work around in place by which I am authenticating with the TAM (tivoli access manager) server via LDAP, then dropping the user into a site that is secured with WebSeal. That IAG successfully forwards the credentials there, but this customer wants no LDAP involved, just webseal. 

    Does anyone have any experience in integrating WebSeal with IAG? If so, how did YOU do it? 
    Wednesday, June 10, 2009 1:00 AM

All replies

  • Hi Amigo. I haven´t really integrated IAG with WebSeal but in the past I evaluated an scenario for a customer owning TAM and WebSeal. Our conclusion was to eliminate WebSeal. If I remember correctly, WebSeal plays the role that IAG can play instead. That is, WebSeal is a web site that can authenticate and authorize users and publishes web applications acting as a reverse proxy and performing single-sign-on. IAG can do that and can also publish client/server applications (WebSeal cannot). Your work here could be to develop some code that lets IAG connect to TAM and retrieve existing username/password pairs to be used for the web applicactions to publish, store that credentials in auxiliar repositories in IAG and use them to delegate credentials for any of the published web apps. Your code should be included as a hook in the postvalidate phase.

    Hope it helps

    // Raúl

    I love this game
    Wednesday, June 10, 2009 8:20 AM
  • Thanks again, Raul. You are absolutely right about WebSeal and likewise, that was actually our recommendation to this particular customer. Still though, they are highly insistent on using it despite the overwhlemingly better implementation without it. Oh well... what can you do =) 


    Wednesday, June 10, 2009 1:38 PM
  • Hi Bryan,

    As mentioned before, this is not a good idea. Either use the IAG or use WebSEAL. They are basically doing the same job, but the IAG is far more configurable. WebSEAL is protecting all applications as a reverse proxy, but secures sites with ACLs that authenticated users may access of they exist in the ACLs.

    In case of Intranet WebSEAL SSO for accessing protected sites you should conside SPNEGO authentication with WebSEAL. I have had issues to have this work on web browsers above IE6. Basically is WebSEAL authenticating the user and sets the IV_USER http header to the user name. Then (in IIS) an ISAPI impersonation filter captures the IV_USER header and impersonate the user based on this value.

    For external authentication you can set another http header that WebSEAL intercepts. This http heaader, am-eai-user-id, will be captured by WebSEAL and transferred to the IV_USER header. More information about this can (briefly) be found on http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itame.doc/am61_webseal_admin319.htm#chap-eai

    I would however encourage you to make another try convincing your customer only using IAG. In my current engagement we're currently moving from WebSEAL to IAG.

    Cheers,
    D
    Tuesday, June 16, 2009 9:47 PM