I'm stepping into a well established environment to help manage the upgrade of a backend application that has, until now, been fielding all the step up requests directly.  Currently, the authenticated user attempts to submit a request to a protected action, protected by an Access Control Policy.  The policy checks a handful of items to determine if the user needs to do step-up, and if so, runs an InfoMap to generate the OTP details, submit the success of the InfoMap as false, and sends that JSON error detail to the application to handle facilitating the OTP process in-app, running against ISAM authsvc policies, until it gets to a point where the Access Control policy will allow the request through.

In the new version of the application, the backend application can no longer field those responses.  Instead of submitting the JSON details back to the application, I need to redirect the user to a different auth application we're building to handle all the login/stepup. I have two questions.

1. I replaced the Permit with Authentication (OTP) with a Permit with Authentication (HTTP Redirect) to get the user out to that external (external to the backend app, but still through WebSEAL) auth application to let that app facilitate the OTP process, but the response to the browser is still a JSON response.  It appears the response is what would be valid (I see my configured redirect url, state, etc), but it's not sending an HTTP 302.
- I'm reasonably confident there is not an http transformation rule modifying the accept/repsonse types to application/json on the protected endpoint.

2. Is this even the best way to begin this new flow? I'm trying to leverage as much existing infrastructure and policy development as I can and it seems to make sense to me to replace the in-app functionality with letting the login/auth application handle it, but I'm not sure if there's a better way to interrupt that request and get the user to the new application to perform the action.

Thanks!

Hi Brian, 

Haven't touched the HTTP redirect Obligation in a long time, but you might have this setting enabled in your reverse proxy?

#--------------------------
# HTML REDIRECTION
#--------------------------
# Enable this option to use the redirect template response file to handle
# redirections.
#
# WebSEAL typically provides a 302 redirection in cases such as when a user
# successfully authenticates. Many AJAX applications do not behave correctly
# when this happens as any HTTP fragments are lost.
#
# Enabling this configuration item will cause WebSEAL to send the redirect
# template response file instead of a 302.  The redirect template response file
# is defined by the html-redirect configuration entry within this stanza.
#
# This configuration item cannot be used in conjunction with
# login-redirect-page.
enable-html-redirect = no

You can also set different templates depending on the Accept Header - in your Reverse Proxy - which could be affecting things also. 

Thanks for the response Philip!  We actually had to redesign the policy based on the applications limitations so we aren't headed down this path anymore (the application is going to continue to field those requests as is). We did not have the enable-html-redirect set, but further in my research I believe it was related to calling /mga/sps/apiauthsvc vs. /mga/sps/authsvc, so if anyone else runs into this maybe start there.

Ah, that will do it, I assume you worked out you can actually switch between those endpoints interchangeably throughout a flow. 

We've had designs where we implement a final "You're about to be complete" response via an infomap from an apiauthsvc flow, and have it make the final request to the authsvc endpoint to perform a traditional redirect where that is the desired behaviour.