Articles

IBM Verify : MMFA Mapping Rules to Determine Device Registration

Share this post:

This article demonstrates how to configure a pre-token mapping rule for MMFA in ISAM which can prevent authenticator registration when certain undesirable conditions are detected.  For example:

  • Unsupported app or OS version
  • The device is jailbroken
  • Enforce users to register with a customer authenticator app

Below are the registration attributes included in the request payload by IBM Verify SDK:

  • device_id
    An alphanumeric string that uniquely identifies a device to the app’s vendor.
  • device_name
    The name of the device.
  • device_type
    The type of the device.  I.e iPhone, iPad
  • device_jailbroken
    The flag to indicate if the device contains known jailbroken criteria.
  • os_version
    The version number of the operating system.
  • platform_type
    The name of the operating system running on the device.
  • fingerprint_support
    The flag to indicate if the device supports TouchId.
  • face_support
    The flag to indicate if the device supports FaceId.
  • front_camera_support
    The flag to indicate if the device has a front facing camera.
  • push_token
    The unique token identifier of the device for receiving push notifications.
  • application_id
    The bundler identifier of the application.

Getting Started

Open the ISAM administration web console in the browser

  1. Click Secure Access Control > Mapping Rules
  2. Select the AuthenticatorPreTokenGeneration mapping rule, click Edit

This example mapping rule is checking to see if the application_id attribute is equal to “com.test.app”. If not, the device is not registered with an exception being returned.  The mapping rule is shown below:

importPackage(Packages.com.tivoli.am.fim.trustserver.sts);
importPackage(Packages.com.tivoli.am.fim.trustserver.sts.oauth20);
importPackage(Packages.com.tivoli.am.fim.trustserver.sts.uuser);
importPackage(Packages.com.tivoli.am.rba.extensions);
importClass(Packages.com.tivoli.am.fim.trustserver.sts.utilities.IDMappingExtUtils);
importClass(Packages.com.tivoli.am.fim.trustserver.sts.utilities.OAuthMappingExtUtils);
importClass(Packages.com.ibm.security.access.httpclient.HttpClient);
importClass(Packages.com.ibm.security.access.httpclient.HttpResponse);
importClass(Packages.com.ibm.security.access.httpclient.Headers);
importClass(Packages.com.ibm.security.access.httpclient.Parameters);
importClass(Packages.java.util.ArrayList);
importClass(Packages.java.util.HashMap);

/**
 * This mapping rule uses device attributes to determine if the OAuth token should be issued for MMFA.
 *
 * To disable this example, change the "device_attribute_validation" variable 
 * to "false".
 */

var device_attribute_validation = true;

if (device_attribute_validation) {
   var grant_type = null;
   var attribute = null;
   var temp_attr = null;

   // The grant_type
   temp_attr = stsuu.getContextAttributes().getAttributeValuesByNameAndType("grant_type", "urn:ibm:names:ITFIM:oauth:body:param");
   if (temp_attr != null && temp_attr.length > 0) {
      grant_type = temp_attr[0];
   }

   // The app identifier
   temp_attr = stsuu.getContextAttributes().getAttributeValuesByNameAndType("application_id", "urn:ibm:names:ITFIM:oauth:body:param");
   if (temp_attr != null && temp_attr.length > 0) {
      attribute = temp_attr[0];
   }

   // Check the grant type and application id.
   if (grant_type == "authorization_code" || grant_type == "refresh_token") && (attribute != "com.test.app") {
      // use throwSTSUserMessageException to return the exception message in request's response
      OAuthMappingExtUtils.throwSTSUserMessageException("Can not use " + attribute + " to register.");
   }
}

IBM Verify Output

Shown below is IBM Verify being used to register, when the mapping rule is expecting com.test.app as the application identifier.

IBM Verify Output

 

Click here to rate this article

Rate this article :

More Articles stories
By Jeroen Tiggelman on August 4, 2019

IBM Security zSecure Suite 2.4 announced

IBM Security zSecure suite V2.4 was announced on July 23, 2019 with a planned availability date of September 30, 2019. You can read the US announcement letter here. RACF has made new JSON Web Token functionality in support of Multi-Factor Authentication also available for z/OS V2.2 and V2.3. Details about zSecure compatibility fixes can be […]

Continue reading

By Martin Schmidt on July 11, 2019

Modernizing your B2C Portal Security – LDAP Proxy Deep Dive

In this part of our series we are taking a deeper look on how the LDAP reverse proxy works and what is needed to be done to make it work. Enable CI In this part we look at what needs to be done on the CI side and what information needs to be collected. We […]

Continue reading

By Martin Schmidt on May 4, 2019

Modernizing your B2C Portal Security – Desired End State

Proposition: As we have seen in part one of this series, managing customer identities for a portal can be a challenge and distraction for the business.  In this part of the series we will outline how a modernized solution for a portal security can simplify operations and free your team up to focus on the […]

Continue reading