Stronger security for your business data at risk

Understanding simple Risk-based authentication scenarios and how to implement them easily using sample JavaScript.

By Dimitar Mihaylov and Donka Dimitrova

In this blog we would like to offer several simple scenarios for risk-based authentication using 2FA (OTP) and risk-based authorizations for protecting corporate resources. We offer also several scripts that you can use as examples in order to implement and test these sample scenarios in your corporate environment.

Prerequisites: SAP NetWeaver AS Java Server; SAP Single Sign-On 2.0 (SP05) with SSO AUTHENTICATION LIBRARY 2.0 deployed on the AS Java Server; SAP Authenticator running on the mobile devices (for the respective scenarios).

Scenario 1: “Employee working inside corporate network”:  This is our basic scenario – we have an employee (an Accountant for example), who authenticates internally via his corporate PC using single sign-on (Kerberos, SAML, X.509 etc.) or form authentication and gets access to all business resources granted to him/her according to his/her business role.

Risk indicators	Context value	Risk	2FA Enforcement
Access	Internal only	No	No
User power	Employee	No	No
Device type	Corporate PC	No	No

We assume that the risk is not significant and strong authentication is not necessary.

Scenario 2: “Power users”: We extend the first scenario with one more employee – an IT admin, who also authenticates from inside corporate network to the same systems using single sign-on or form authentication but because of his/her corporate role, he/she has “maximum permissions” – access to all technical and business resources of these systems for support purposes.

Risk indicators	Context value	Risk	2FA Enforcement
Access	Internal only	No	No
User power	IT Admin (Power user)	Yes	Yes
Device type	Corporate PC	No	No

We assume that strong authentication is necessary when the user belongs to the group of IT Administrators. The user has to be requested to provide 2-factor authentication in addition to single sign-on (Kerberos, SAML, X.509 etc.) or form authentication.

In our example we provide a JavaScript that enforces two-factor authentication (2FA) based on one-time passwords (OTP). These OTP passcodes are generated on a mobile device, using for example SAP Authenticator (or other RFC6238 compliant passcode generator). It is also possible to configure 2FA to use passcodes sent using out-of-band methods (SMS, e-mail) but this is not demonstrated in our example. You can find more details in documentation about these out-of-band methods here: Develop a Script for Risk-Based Authentication (Script 3).

Sample JavaScript – 2FA (OTP enabled by default) is required only for users assigned to the UME role “Administrators” and will not be required for all other users. The info about the authentication is also recorded in the log (for all JavaScript examples in the blog):

function onFirstStageLogin(config, context, result) {

  var logger = context.getLogger();

  var loginInfo = context.getLoginInfo();

  var user = loginInfo.getUser();

  var logonId = user.getUniqueName();

  if (user.isMemberOfGroup(‘GRUP.PRIVATE_DATASOURCE.un:Administrators’, true)) {

    // By default second factor will be required

logger.logInfo(‘Two-factor authentication required for user: ‘ + logonId);

  } else {

    // Do not require second factor for non-administrator users

result.doNotRequireSecondFactor();

    logger.logInfo(‘Single-factor authentication of user: ‘ + logonId);

  }

}

Scenario 3: “Employee on a business trip”: We extend the first scenario with offering access from outside corporate network.

Risk indicators	Context value	Risk	2FA Enforcement
Access	Internal & External	Yes	Yes
User power	Employee	No	No
Device type	Corporate PC	No	No

We assume that strong authentication is necessary when the user authenticates from outside corporate network and he/she has to be requested to provide 2FA in addition to single sign-on (X.509, SAML, etc.) or form authentication.

Sample JavaScript – 2FA (OTP enabled by default) is required only when the user authenticates from outside corporate network and will not be required for the sessions, where the user authenticates from inside corporate network:

function isExternalAccess(context) {

  var accessType = context.getHttpClientContext().getHeader(“x-access-type”);

  var result = (accessType == “external”);

  return result;

}

function onFirstStageLogin(config, context, result) {

  var logger = context.getLogger();

  var loginInfo = context.getLoginInfo();

  var user = loginInfo.getUser();

  var logonId = user.getUniqueName();

  if (isExternalAccess(context)) {

    // By default second factor will be required

logger.logInfo(‘[EXTERNAL ACCESS] Two-factor authentication required for user: ‘ + logonId);

  } else {

    // Do not require second factor for internal access

result.doNotRequireSecondFactor();

logger.logInfo(‘[INTERNAL ACCESS] Single-factor authentication of user: ‘ + logonId);

}

}

Scenario 4: “Power user on a business trip”:  We extend the second scenario with offering access from outside corporate network for an IT Admin on a business trip.

Risk indicators	Context value	Risk	2FA	Limited Permissions
Access	Internal & External	Yes	No	Limited External Access
User power	IT Admin (Power user)	Yes	Yes	No
Device type	Corporate PC	No	No	No

We assume that strong authentication is necessary when the user is a “Power users” (IT Admin in our example) and we have to request 2FA similar to Scenario 2 but this scenario also allows external access that brings additional risk. To mitigate the risk, when the authentication is coming from outside corporate network, we need more control over it and here we can use another prevention mechanism – the capability to limit the user permissions for accessing concrete resources during a session. This way the authorizations, granted to the user, will not be changed and the user will have still all of his granted permissions when accessing the system from inside corporate network, but for a session established from outside corporate network, he/she will be able to use only some of the already granted permissions.

Limiting authorizations based on the risk is a new capability and it is possible using “Scopes” parameter (a string array of scopes) of the UME roles (SAP NetWeaver User Management Engine). For more details see the SAP Note: 2151025 – User Management Engine Support for Dynamic Authorizations .

Example role settings for permissions that will be available only internally:

Example role settings for permissions that will be available internally and externally:

Limitation of the user authorizations is enforced via the OTP policy script method setAuthorizationScopes(scopes,roleWithoutScopes) – the user receives only his/her UME roles that contain specific scopes, listed via the first parameter of the method. If no scopes are defined then the second parameter is considered. More details about the method and it’s parameters are available here: OTP – Policy Script Functions and Methods

Sample JavaScript – 2FA (OTP enabled by default) is required only for users assigned to the UME role “Administrators” and will not be required for the other users. Users will be able to use all business resources granted to them, when accessing the system from inside corporate network and will have limited authorizations for their external access (only the roles with “scope” values “EXTERNAL_ACCESS” and any other roles assigned to them without a specific “scope”):

function isExternalAccess(context) {

  var accessType = context.getHttpClientContext().getHeader(“x-access-type”);

  var result = (accessType == “external”);

  return result;

}

function onFirstStageLogin(config, context, result) {

  var logger = context.getLogger();

  var loginInfo = context.getLoginInfo();

  var user = loginInfo.getUser();

  var logonId = user.getUniqueName();

  if (user.isMemberOfGroup(‘GRUP.PRIVATE_DATASOURCE.un:Administrators’, true)) {

    // By default second factor will be required

logger.logInfo(‘Two-factor authentication required for user: ‘ + logonId);

  } else {

    // Do not require second factor for non-administrator users

result.doNotRequireSecondFactor();

logger.logInfo(‘Single-factor authentication of user: ‘ + logonId);

  }

}

function onSecondStageLogin(config, context, result) {

  if (isExternalAccess(context)) {

    // Limited permissions

result.setAuthorizationScopes([“EXTERNAL_ACCESS”], result.GRANT_ROLES_WITHOUT_SCOPES);

  } else {

    // Full permissions

result.setAuthorizationScopes([“INTERNAL_ACCESS”], result.GRANT_ROLES_WITHOUT_SCOPES);

  }

}

Scenario 5: ”Mobile access from outside corporate network”: We extend Scenario 3 with offering mobile access from inside and outside corporate network.

Risk indicators	Context value	Risk	2FA	Limited Permissions
Access	Internal & External	Yes	Yes	Limited External Access
User power	Employee	No	No	No
Device type	Mobile device	Yes	Yes	No

We would like to offer mobile access to our employees but we assume that the access via mobile devices brings a lot of risk for our business resources. This is why we want to enable 2FA for all  authentications coming from a mobile device. We would like also to offer Mobile single sign-on available via “remember client” option of the SAP Authenticator. Remember client capability is based on persistent cookies, issued the first time when the user authenticates to the application using his/her mobile device. Persistent cookies are used in combination with one-time password, generated by the SAP Authenticator, for the Mobile single sign-on solution. For security reasons we want to limit the issue of the persistent cookie when users are outside corporate network. This limitation doesn’t affect the usage of the persistent cookie for Mobile SSO from outside corporate network. The limitation will be valid only for the “activation” of the Mobile SSO – the issue of the persistent cookie will be available only inside corporate network.

With regard to the external access in general, we would like to enforce 2FA in combination with authorization limitations – every user will have to provide 2FA when working from outside corporate network and also will have limited authorizations (only the roles assigned to him/her with “Scopes” value “EXTERNAL_ACCESS” and all other roles assigned that don’t have a specific “Scopes”). When users are working inside corporate network they will have full access (all their roles with “Scopes” values “INTERNAL_ACCESS” and all other roles assigned that don’t have a specific “Scopes”) and 2FA will be necessary only for the mobile access.

Sample JavaScript – On the first stage login, if the access is from a mobile device, we enable the server setting for accepting session cookies (the 2FA is requested by default). On the same stage login, if the access is from a desktop PC and the authentication request is internal, 2FA is not necessary and the access is full. In our example 2FA is necessary when the access is external or is internal but on mobile device. This way on second stage login in case of external access the authorizations are limited and in case of internal access (this will be always on mobile device) the access is full and a session cookie for Mobile SSO will be issued:

function isExternalAccess(context) {

  var accessType = context.getHttpClientContext().getHeader(“x-access-type”);

  var result = (accessType == “external”);

  return result;

}

function isMobileDevice(context) {

  var authnMethod = context.getLoginInfo().getAuthenticationMethod();

  var result = authnMethod.startsWith(“otp”);

  return result;

}

function onFirstStageLogin(config, context, result) {

  var logger = context.getLogger();

  var loginInfo = context.getLoginInfo();

  var authnMethod = loginInfo.getAuthenticationMethod();

  var user = loginInfo.getUser();

  var logonId = user.getUniqueName();

 

  if (isMobileDevice(context)) {

    // Access from a mobile device with SAP Authenticator

config.setProperty(“tfa.accept.client.cookie”, “yes”);

    // Two-factor authentication is required for both internal and external access

    return;

  }

  // Access from a PC

  if (isExternalAccess(context)) {

    // Two-factor authentication required for external access

logger.logInfo(‘[EXTERNAL ACCESS] Two-factor authentication required for user: ‘ + logonId);

  } else {

    // Do not require second factor for internal access

result.doNotRequireSecondFactor();

    // Full permissions

result.setAuthorizationScopes([“INTERNAL_ACCESS”], result.GRANT_ROLES_WITHOUT_SCOPES);

logger.logInfo(‘[INTERNAL ACCESS] Single-factor authentication of user: ‘ + logonId);

  }

}

function onSecondStageLogin(config, context, result) {

  if (isExternalAccess(context)) {

    // Limited permissions

result.setAuthorizationScopes([“EXTERNAL_ACCESS”], result.GRANT_ROLES_WITHOUT_SCOPES);

  } else {

    // Full permissions

result.setAuthorizationScopes([“INTERNAL_ACCESS”], result.GRANT_ROLES_WITHOUT_SCOPES);

    // Remember mobile device

    if (isMobileDevice(context)) {

config.setProperty(“tfa.issue.client.cookie”, “yes”);

    }

  }

}

More info:

Risk-Based Authentication for Your Critical Business Processes

Strong Two-Factor Authentication with One-Time Password Solution

SAP Enterprise Portal and SAP Fiori – Common Architecture and Recommendations including Risk-based authentication and Mobile SSO

SAP Note: 2151025 – User Management Engine Support for Dynamic Authorizations <<< new