So I have a weird situation. We are passing a base64-encoded string to a partner as a part of the SAML assertion. The process is to make an https web service call to obtain this data (in the Mapping Rules). For various, rare instances there can be errors encountered. The behavior I've encountered is the call results in a non-200 return code (no required data passed back to Mapping Rules), but the assertion is created and the user is sent anyway, resulting in an error on the service provider's side. It appears that once the user is authenticated and authorized, the mapping rules happen during the building of the response. The question then, is there a way to either stop the process at that point and return an error to the user, or is there a place earlier in the process where I can make this call and deal with this error?

It's a rare occurrence, but has to be accounted for in this implementation. I did figure out a way to stop it, but it's hardly elegant.
I throw an STSModuleException as below. This blows up the process, but there must be a more graceful way of doing this. Here's the snippet:

if ( response != null ) {
    var body = response.getBody();
    var code = response.getCode();
    if ( code == 200) {
       frm1228 = body;
    } else throw STSModuleException("Non 200 return code from 1228 call. This is an application error, NOT an ISAM one. Check java logs.");
}

So,has anyone else encountered this issue? What have others done to prevent the process from continuing?

------------------------------
David Gianetti
------------------------------

We've ran into the same issue in the past, and the direction that we've gotten was the same.. throw the STSModuleException... actually we use 

------------------------------
Kurt Green
------------------------------

Original Message:
Sent: Wed August 12, 2020 01:47 PM
From: David Gianetti
Subject: Halting SAML when error occurs during Mapping Rules processing.

So I have a weird situation. We are passing a base64-encoded string to a partner as a part of the SAML assertion. The process is to make an https web service call to obtain this data (in the Mapping Rules). For various, rare instances there can be errors encountered. The behavior I've encountered is the call results in a non-200 return code (no required data passed back to Mapping Rules), but the assertion is created and the user is sent anyway, resulting in an error on the service provider's side. It appears that once the user is authenticated and authorized, the mapping rules happen during the building of the response. The question then, is there a way to either stop the process at that point and return an error to the user, or is there a place earlier in the process where I can make this call and deal with this error?

It's a rare occurrence, but has to be accounted for in this implementation. I did figure out a way to stop it, but it's hardly elegant.
I throw an STSModuleException as below. This blows up the process, but there must be a more graceful way of doing this. Here's the snippet:

if ( response != null ) {
    var body = response.getBody();
    var code = response.getCode();
    if ( code == 200) {
       frm1228 = body;
    } else throw STSModuleException("Non 200 return code from 1228 call. This is an application error, NOT an ISAM one. Check java logs.");
}

So,has anyone else encountered this issue? What have others done to prevent the process from continuing?

------------------------------
David Gianetti
------------------------------

Thanks, Kurt. It's good to hear we're not alone and that I didn't do anything crazy. It is inelegant but I understand, due to the flow of things, there are few options to stop the response process. I appreciate your feedback!

------------------------------
David Gianetti
------------------------------

Original Message:
Sent: Mon August 17, 2020 04:15 PM
From: Kurt Green
Subject: Halting SAML when error occurs during Mapping Rules processing.

We've ran into the same issue in the past, and the direction that we've gotten was the same.. throw the STSModuleException... actually we use 

IDMappingExtUtils.throwSTSUserMessageException(error_message);

But this error runs thru the authn_failed.html template, which we've modified to handle various error messages and then redirect the user to a more user friendly location.  It's not exactly elegant, lol but it has improved the error handling experience.

There is another way to pass an error in the assertion to the SP, but that is poor option, and really means your SP has to be on ISAM as well.

------------------------------
Kurt Green

Original Message:
Sent: Wed August 12, 2020 01:47 PM
From: David Gianetti
Subject: Halting SAML when error occurs during Mapping Rules processing.

So I have a weird situation. We are passing a base64-encoded string to a partner as a part of the SAML assertion. The process is to make an https web service call to obtain this data (in the Mapping Rules). For various, rare instances there can be errors encountered. The behavior I've encountered is the call results in a non-200 return code (no required data passed back to Mapping Rules), but the assertion is created and the user is sent anyway, resulting in an error on the service provider's side. It appears that once the user is authenticated and authorized, the mapping rules happen during the building of the response. The question then, is there a way to either stop the process at that point and return an error to the user, or is there a place earlier in the process where I can make this call and deal with this error?

It's a rare occurrence, but has to be accounted for in this implementation. I did figure out a way to stop it, but it's hardly elegant.
I throw an STSModuleException as below. This blows up the process, but there must be a more graceful way of doing this. Here's the snippet:

if ( response != null ) {
    var body = response.getBody();
    var code = response.getCode();
    if ( code == 200) {
       frm1228 = body;
    } else throw STSModuleException("Non 200 return code from 1228 call. This is an application error, NOT an ISAM one. Check java logs.");
}

So,has anyone else encountered this issue? What have others done to prevent the process from continuing?

------------------------------
David Gianetti
------------------------------