Custom SMS/Email OTPs messages per brand

Branded SMS and Email OTP messages with IBM Security Verify Access just takes a few steps with IBM Security Verify Access.

First thing you need to do – is determine how you plan to differentiate the inbound request from a different brand. In this example, we’ll do it based on an inbound HTTP header to the AAC runtime.
The easiest thing to do – is either do it based on ISVA Reverse Proxy Server name, or perhaps a host header on the junction to AAC – ie /mga.

If you wanted to do it based on a query string, a particular authsvc policy, you might need to add an infomap for some basic logic before the OTP Mechanism. (I briefly mention how you can store and retrieve data in the formatting code below).

Here I am sending a brand host header on the /mga junction, to tell it which brands to serve up – on our OTP mapping rules. I’ve chosen this method, as it’s fairly easy to get the host header from the request.

They are in the STSUU here:

And I’ve previously talked about pulling headers from requests here:

From there – we now need to work out how we want to format the specific delivered messages. The easiest way to do this – is to modify the message in the otpDeliver mapping rule, where it is formatting the OTP to be put into the template.

In the Mapping rule, look for the following line:

var otpFormatted = otpHint + "-" + otp;

We will now manipulate the ‘otpFormatted’ variable to contain our fully customised message:

//Import some debugging  utilities importClass(Packages.com.tivoli.am.fim.trustserver.sts.utilities.IDMappingExtUtils);
//To see what we have in the STSUU - can use this:
IDMappingExtUtils.traceString("##############################STSUU! " + stsuu.toString());
var hostHeaderValue = stsuuCtxAttrs.getAttributeValueByNameAndType("host","otp.useragent.httpheader.type");
if (!hostHeaderValue)
{
    hostHeaderValue = "default";
}
IDMappingExtUtils.traceString("##### Host Value Acquired: " + hostHeaderValue);
if (deliveryType.equals("sms_delivery")){
    // Set a Default message:
    var StartMessage = "Your OTP is ";
    var EndMessage = " Please complete your OTP in 5 minutes.";
    //Set Message based on host:
    if (hostHeaderValue.equalsIgnoreCase("www.brand1.com")) {
        importMappingRule("SMSTemplate1"); 
    }else if (hostHeaderValue.equalsIgnoreCase("www.brand2.com")) {
        importMappingRule("SMSTemplate2"); 
    }else 
    {
        //Use default...
        /*  Or you could extract the message from a presaved piece of data  
         *  from an earlier infomap. For example you might want to add 
         *  specific context, transaction data from a CBA request
         *  or location data...
         *  In a preceeding Infomap, build your custom message and 
         *  save it to the session: 
         *  IDMappingExtUtils.setSPSSessionData("StartMessage","Enter the OTP to access this super specific resource: ");
         *  And use this to get the value out:
         *  StartMessage = IDMappingExtUtils.getSPSSessionData("StartMessage");
         */

    }
    //Finally - put the customised message together.
    otpFormatted = StartMessage + otpFormatted + EndMessage;
}


From here, you just need to create the messages for each brand, so you can use the importMappingRule statements in the script above.
Here is an example of my mapping rule: SMSTemplate1

StartMessage = "Hi, this is Bobs Bank, your OTP is: ";
EndMessage = " Please enter this OTP in 5 minutes or less.";

Could also put all messages in here in an indexed JSON array, or any other method you want to scale.
Ultimately, these are just variables available in otpDeliver after importing this mapping rule.

messages = {
    "www.brand1.com":
    {
        "startMessage": "Hi, this is Bobs Bank, your OTP is: ",
        "endMessage": " Please enter this OTP in 5 minutes or less."
    }
    ,
    "www.brand2.com":
    {
        "startMessage": "Hi, this is Jims Bank, your OTP is: ",
        "endMessage": " Please enter this OTP in 5 minutes or less."
    }

};

Finally, we need to remove any ‘surplus’ text from the OTP template page, since we’re building it all dynamically:

This pattern should work equally well for the Email OTP, with a little more formatting/character encoding for the email messages since it’s likely HTML.

Comments are closed.

Website Built with WordPress.com.

Up ↑