Hi,

We've some questioning regarding how infomap is working and we're encountering a very particular use case.

We understood that when we create a session object and return this back to Webseal (after a setSuccess(true) statement), Webseal is creating the session properly with all provided attributes. However, we'd need some of these session attributes (or headers) to be propagated until the front-end application which is a fat client.

So far, we've only found ways to do it in case of errors (=setSuccess(false)), using MACRO's and template pages but have been unfortunate to find a solution for successfull login.

Do you guys have the same use case somewhere ? How did you solve it ?

Regards,

------------------------------
Cedric Servais
------------------------------

Hello Cedric,

When an InfoMap completes with success=false, this indicates that further client interaction is required.  The Authentication Service generates a page which is intended for the client.  Whatever headers and content you put on this page is returned to the client with WebSEAL forwarding it in its role as Reverse Proxy.

When an InfoMap completes with success=true, this indicates that authentication is complete.  You don't get to return a page to the client. The Authentication Service generates a response (with EAI headers) which is intended for WebSEAL.  The EAI headers are consumed by WebSEAL to generate an authenticated session.   WebSEAL will then build its own response for the client.  For a browser client this will likely be a 302 redirect to the target resource.  For a REST client, this will likely be a JSON object indicating successful authentication.

One trick I have seen to get more control over the final EAI response is to NOT end your authentication policy with success=true but, instead, to return success=false and then to build the required EAI response using a template page.  If you have your own EAI response page you can set headers to tell WebSEAL to stream the response back to the client rather than invoking its own redirect/response function.

The header you need is:

am-eai-flags: stream​

(header name needs to match what is configured in WebSEAL configuration).

Some more information on this here:
https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/

Regards... Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Hello John,

Thank you for the swift answer. It did indeed made the trick. Shouldn't this be a candidate for RFE to get a more robust and sustainable design ? Sounds like a 'hack' to me :)

Regards,

------------------------------
Cedric Servais
------------------------------

Original Message:
Sent: Wed February 05, 2020 03:58 AM
From: Jon Harry
Subject: [INFOMAP] Returning headers to a fat web client

Hello Cedric,

When an InfoMap completes with success=false, this indicates that further client interaction is required.  The Authentication Service generates a page which is intended for the client.  Whatever headers and content you put on this page is returned to the client with WebSEAL forwarding it in its role as Reverse Proxy.

When an InfoMap completes with success=true, this indicates that authentication is complete.  You don't get to return a page to the client. The Authentication Service generates a response (with EAI headers) which is intended for WebSEAL.  The EAI headers are consumed by WebSEAL to generate an authenticated session.   WebSEAL will then build its own response for the client.  For a browser client this will likely be a 302 redirect to the target resource.  For a REST client, this will likely be a JSON object indicating successful authentication.

One trick I have seen to get more control over the final EAI response is to NOT end your authentication policy with success=true but, instead, to return success=false and then to build the required EAI response using a template page.  If you have your own EAI response page you can set headers to tell WebSEAL to stream the response back to the client rather than invoking its own redirect/response function.

The header you need is:

am-eai-flags: stream​

(header name needs to match what is configured in WebSEAL configuration).

Some more information on this here:
https://philipnye.com/2014/12/18/isam-for-web-webseal-stream-eai-authentication-response-to-browser/

Regards... Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------