IBM Verify

Hi,

I configured ISVA to allow step-up authentication using client-cert auth on port 444 using the "prompt_as_needed" (https://www.ibm.com/docs/en/sva/10.0.6?topic=authentication-enabling-certificate) and it works nicely on a single server setup. The user will end up on ISVA on port 443 and can choose from different auth methods, client-cert being one method. When the user chooses cert auth, he will be redirected to port 444 to perform the cert handshake and after successful authentication the user will be forwarded back to whatever url he was trying to access.

The same will run into problems if we scale up to two Webseal instances. Roughly 50% of the time the user will get stuck after cert authentication on port 444 on a page sayin "Your login was successful". I assume this is because the user may end up on a different Webseal on port 444 and it will not have any information on what the user accessed before and will not redirect to the back to the expected flow (be it OpenID Connect, SAML or something else) using the automatic redirection. 

I guess the above would not happen if the loadbalancer could ensure the user ends up on the same Webseal on both ports but that is more difficult since we use multiple ports. 

Has anyone else successfully implemented something like this?

Is there any way to make Webseal reverse proxies share the original target url used for automatic redirection or is the only option to solve this on the loadbalancer level to make sure the user always ends up on the same Webseal proxy?

Hello Peter,

Please consider using the 'HTML Redirection' feature which uses a cookie and HTML code to redirect the user instead of relying on the session cache.
https://www.ibm.com/docs/en/sva/10.0.8?topic=configuration-html-redirection

You'll need to both enable the configuration file entry as well as make sure the management HTML pages are updated to allow the pages.

This is a global change.

Hi,

I configured ISVA to allow step-up authentication using client-cert auth on port 444 using the "prompt_as_needed" (https://www.ibm.com/docs/en/sva/10.0.6?topic=authentication-enabling-certificate) and it works nicely on a single server setup. The user will end up on ISVA on port 443 and can choose from different auth methods, client-cert being one method. When the user chooses cert auth, he will be redirected to port 444 to perform the cert handshake and after successful authentication the user will be forwarded back to whatever url he was trying to access.

The same will run into problems if we scale up to two Webseal instances. Roughly 50% of the time the user will get stuck after cert authentication on port 444 on a page sayin "Your login was successful". I assume this is because the user may end up on a different Webseal on port 444 and it will not have any information on what the user accessed before and will not redirect to the back to the expected flow (be it OpenID Connect, SAML or something else) using the automatic redirection. 

I guess the above would not happen if the loadbalancer could ensure the user ends up on the same Webseal on both ports but that is more difficult since we use multiple ports. 

Has anyone else successfully implemented something like this?

Is there any way to make Webseal reverse proxies share the original target url used for automatic redirection or is the only option to solve this on the loadbalancer level to make sure the user always ends up on the same Webseal proxy?

Hi Jack,

Using HTML Redirection using javascript and keeping the targeturl in the browser seems to solve it for us.

Combining HTML Redirection with step-up authentication and the EAI flow we use for alternative authentication methods requires a few more changes, but works nicely when setup correctly.

A heads up for anyone else implementing:
the sample code in the documentation
https://www.ibm.com/docs/en/sva/10.0.8?topic=redirection-preserving-html-fragments
uses a different cookie name than in redirect.js that will read the cookie and handle the redirect. The cookie names need to match.

Big thanks to you Jack for the quick help!

Hello Peter,

Please consider using the 'HTML Redirection' feature which uses a cookie and HTML code to redirect the user instead of relying on the session cache.
https://www.ibm.com/docs/en/sva/10.0.8?topic=configuration-html-redirection

You'll need to both enable the configuration file entry as well as make sure the management HTML pages are updated to allow the pages.

This is a global change.

Hi,

I configured ISVA to allow step-up authentication using client-cert auth on port 444 using the "prompt_as_needed" (https://www.ibm.com/docs/en/sva/10.0.6?topic=authentication-enabling-certificate) and it works nicely on a single server setup. The user will end up on ISVA on port 443 and can choose from different auth methods, client-cert being one method. When the user chooses cert auth, he will be redirected to port 444 to perform the cert handshake and after successful authentication the user will be forwarded back to whatever url he was trying to access.

The same will run into problems if we scale up to two Webseal instances. Roughly 50% of the time the user will get stuck after cert authentication on port 444 on a page sayin "Your login was successful". I assume this is because the user may end up on a different Webseal on port 444 and it will not have any information on what the user accessed before and will not redirect to the back to the expected flow (be it OpenID Connect, SAML or something else) using the automatic redirection. 

I guess the above would not happen if the loadbalancer could ensure the user ends up on the same Webseal on both ports but that is more difficult since we use multiple ports. 

Has anyone else successfully implemented something like this?

Is there any way to make Webseal reverse proxies share the original target url used for automatic redirection or is the only option to solve this on the loadbalancer level to make sure the user always ends up on the same Webseal proxy?

Hi Jack,

An update to the previous finding. I did get the login flow to work nicely on the using client certificates step-up at first.

However, when using OpenID Connect, the browser will first try to access the /authorize endpoint that seems to automatically forward the user to the /mga/sps/auth endpoint for authentication. The script on the login page will then only be aware of the  /mga/sps/auth and that is where the user is redirected back to after successful login.

I am in need of good ideas on how to handle the login flow described here:
https://www.ibm.com/docs/en/sva/10.0.8?topic=redirection-preserving-html-fragments
together with OpenID Connect, as the suggested way seems to break the flow.

Hi Jack,

Using HTML Redirection using javascript and keeping the targeturl in the browser seems to solve it for us.

Combining HTML Redirection with step-up authentication and the EAI flow we use for alternative authentication methods requires a few more changes, but works nicely when setup correctly.

A heads up for anyone else implementing:
the sample code in the documentation
https://www.ibm.com/docs/en/sva/10.0.8?topic=redirection-preserving-html-fragments
uses a different cookie name than in redirect.js that will read the cookie and handle the redirect. The cookie names need to match.

Big thanks to you Jack for the quick help!

Hello Peter,

Please consider using the 'HTML Redirection' feature which uses a cookie and HTML code to redirect the user instead of relying on the session cache.
https://www.ibm.com/docs/en/sva/10.0.8?topic=configuration-html-redirection

You'll need to both enable the configuration file entry as well as make sure the management HTML pages are updated to allow the pages.

This is a global change.

Hi,

I configured ISVA to allow step-up authentication using client-cert auth on port 444 using the "prompt_as_needed" (https://www.ibm.com/docs/en/sva/10.0.6?topic=authentication-enabling-certificate) and it works nicely on a single server setup. The user will end up on ISVA on port 443 and can choose from different auth methods, client-cert being one method. When the user chooses cert auth, he will be redirected to port 444 to perform the cert handshake and after successful authentication the user will be forwarded back to whatever url he was trying to access.

The same will run into problems if we scale up to two Webseal instances. Roughly 50% of the time the user will get stuck after cert authentication on port 444 on a page sayin "Your login was successful". I assume this is because the user may end up on a different Webseal on port 444 and it will not have any information on what the user accessed before and will not redirect to the back to the expected flow (be it OpenID Connect, SAML or something else) using the automatic redirection. 

I guess the above would not happen if the loadbalancer could ensure the user ends up on the same Webseal on both ports but that is more difficult since we use multiple ports. 

Has anyone else successfully implemented something like this?

Is there any way to make Webseal reverse proxies share the original target url used for automatic redirection or is the only option to solve this on the loadbalancer level to make sure the user always ends up on the same Webseal proxy?

Hello Peter,

There shouldn't be a problem here as the AAC component associates all the '/authorize' query parameters in its memory and provides a cookie to reference that information while authentication is taking place.

The flow is working as designed redirecting back to '/mga/sps/auth' and as long as you still have that cookie, the JSESSIONID cookie, in your request you'll resume the OIDC flow as expected.

Hi Jack,

An update to the previous finding. I did get the login flow to work nicely on the using client certificates step-up at first.

However, when using OpenID Connect, the browser will first try to access the /authorize endpoint that seems to automatically forward the user to the /mga/sps/auth endpoint for authentication. The script on the login page will then only be aware of the  /mga/sps/auth and that is where the user is redirected back to after successful login.

I am in need of good ideas on how to handle the login flow described here:
https://www.ibm.com/docs/en/sva/10.0.8?topic=redirection-preserving-html-fragments
together with OpenID Connect, as the suggested way seems to break the flow.

Hi Jack,

Using HTML Redirection using javascript and keeping the targeturl in the browser seems to solve it for us.

Combining HTML Redirection with step-up authentication and the EAI flow we use for alternative authentication methods requires a few more changes, but works nicely when setup correctly.

A heads up for anyone else implementing:
the sample code in the documentation
https://www.ibm.com/docs/en/sva/10.0.8?topic=redirection-preserving-html-fragments
uses a different cookie name than in redirect.js that will read the cookie and handle the redirect. The cookie names need to match.

Big thanks to you Jack for the quick help!

Hello Peter,

Please consider using the 'HTML Redirection' feature which uses a cookie and HTML code to redirect the user instead of relying on the session cache.
https://www.ibm.com/docs/en/sva/10.0.8?topic=configuration-html-redirection

You'll need to both enable the configuration file entry as well as make sure the management HTML pages are updated to allow the pages.

This is a global change.

Hi,

I configured ISVA to allow step-up authentication using client-cert auth on port 444 using the "prompt_as_needed" (https://www.ibm.com/docs/en/sva/10.0.6?topic=authentication-enabling-certificate) and it works nicely on a single server setup. The user will end up on ISVA on port 443 and can choose from different auth methods, client-cert being one method. When the user chooses cert auth, he will be redirected to port 444 to perform the cert handshake and after successful authentication the user will be forwarded back to whatever url he was trying to access.

The same will run into problems if we scale up to two Webseal instances. Roughly 50% of the time the user will get stuck after cert authentication on port 444 on a page sayin "Your login was successful". I assume this is because the user may end up on a different Webseal on port 444 and it will not have any information on what the user accessed before and will not redirect to the back to the expected flow (be it OpenID Connect, SAML or something else) using the automatic redirection. 

I guess the above would not happen if the loadbalancer could ensure the user ends up on the same Webseal on both ports but that is more difficult since we use multiple ports. 

Has anyone else successfully implemented something like this?

Is there any way to make Webseal reverse proxies share the original target url used for automatic redirection or is the only option to solve this on the loadbalancer level to make sure the user always ends up on the same Webseal proxy?