IBM Verify

 View Only

 ISVA Partial Authentication

Supun Munasinghe's profile image
Supun Munasinghe posted Sat November 02, 2024 09:21 AM

Hi Folks,

We have a setup with first level authentication will happen on the core (AD federated) and then user will be navigated to SMS/EMAIL OTP screen which configured in AAC. if the OTP mechanism fails or locked out due to passed invalid attempts, subsequent retries directly landing the user back to OTP since first level ( AD auth) authentication was already completed. the requirement here is if the user getting locked with OTP mechanism due to invalid attempts, the first level AUTH session also to be cancelled out. so the subsequent requires should redirect users into first level login page again.

How to get this done?

Animesh Sangal's profile image
Animesh Sangal

Dear Supun, 

You have to manage this in you mapping rules where you are initiating the OTP operation for 2FA. Remove the first level of auth once the attempts exhausted.  

Supun Munasinghe's profile image
Supun Munasinghe

Hi Animesh

Is there any specific way to removing the first factor auth from the mapping rules?

Laurent LA Asselborn's profile image
Laurent LA Asselborn

Hi Supun,

Has the user already an active ISVA session after the first step? You can just kill the session by embedding a call to /pkmslogout. One method of doing this is via a 0x0 px img tag.

There are several other ways to kill the session (by setting the right attributes) or alter the auth level of the credential but this solution should be very easy to implement

Shane Weeden's profile image
Shane Weeden

As others have said, you can do this several ways, including with a single-pixel img pointing back at the ../../../../pkmslogout URL from the macotp login.html page after MFA attempts are exhausted. That's somewhat non-deterministic though, because it does rely on the browser actually resolving that URL for the session to be terminated. I think what I'd try first instead is server-side template page scripting in the macotp login.html page that performed a programmatic server-side logout when the error condition is detected. Update the C/authsvc/authenticator/macotp/login.html page to have code like this inserted at the start of it:

<%

// figure out if the user has performed too many attempts by checking if error message contains specific error code
// (see https://www.ibm.com/docs/en/samfm/8.0.1?topic=messages-fbtotp338e)
if (templateContext.macros["@ERROR_MESSAGE@"] != null && templateContext.macros["@ERROR_MESSAGE@"].indexOf("FBTOTP338E") >= 0) {
    /*
    * user is out of attempts - force a full logout and redirect to webseal root page using the eai-server-task response HTTP header
    */

    // figure out the user session id, from request headers that are sent to AAC. If its present then perform an EAI logout
    if (templateContext.request.headers["user_session_id"] != null) {
        let userSessionIDHeader = templateContext.request.headers["user_session_id"][0];
        // eai headers to force logout and redirect back to the root of the webseal. Only the part of the header after the underscore is used
        templateContext.response.setHeader("am-eai-server-task", "terminate session " + userSessionIDHeader.split("_")[1]);
        templateContext.response.setHeader("am-eai-flags", "stream");
        templateContext.response.sendRedirect("../../../../../");
    }
}
%>

<!-- rest of normal C/authsvc/authenticator/macotp/login.html appears here -->

Of course the action doesn't have to be a redirect back to the WebSEAL root - you could write a different error response page, or something like that, but the authenticated session should be completely terminated, server-side.

The solution presented here leans on some things I wrote about in my blog article: Creative use of Infomap as an EAI