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.

Scenario1.png

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.

Scenario2.png

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.

Scenario3.png

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 JavaScript2FA (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.

Scenario4.png

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:

ScopesF1.png

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

ScopesF2.png

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 JavaScript2FA (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.

Scenario5.png

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 JavaScriptOn 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



To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

    1. Dimitar Mihaylov

      Hi,

      The UME scopes functionality will be downported to the last 2-3 SPs of AS Java 7.30, 7.31, 7.40. I can provide you the exact versions next week. If you are on some of these SPs you won’t need to update the whole system but just patch the UME.

      Regards,

      Dimitar

      (0) 
    2. Nikolay Landzhev

      Hi Everyone,

      The UME scopes functionality will be available for:

      AS Java 7.30 SP 13 and newer

      AS Java 7.31 SP 14 and newer

      AS Java 7.40 SP 09 and newer

      We will update the article with the SAP Note number in the next couple of weeks.

      Best regards,

      Nikolay

      (0) 
    3. Nikolay Landzhev

      Hi Everyone,

      The UME scopes functionality, used implementing dynamic authorizations has been released with SAP Note 2151025 – User Management Engine Support for Dynamic Authorizations. We are still working to bring the functionality to as many releases as possible. In the next days the note will be updated with more releases. At the end we will have the functionality in:

      AS Java 7.30 SP 13 and all newer

      AS Java 7.31 SP 14 and all newer

      AS Java 7.40 SP 09 and all newer

      Pleas let me know if you have any questions or comments?

      Best regards,

      Nikolay

      (0) 
  1. Chandrakanth Angannagari

    Hello, as a administrator i was able to follow what is being tried to be acheived with this. However the technical setup is not very clear ..

     

    1. where do the java scripts get deployed?
    2. are these standard java scripts written by SAP ? can they be used as-is?
    3. if they are to be written by customers, are the above snippets examples ?
    4. some scripts above use snippets like, but how does this header get set in the first place x-access-type ? Do we have to work with our WAF teams that all traffic coming from outside the firewall gets this value set ?

    function isExternalAccess(context) {

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

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

      return result;

    }

     

    Thanks

     

    (0) 

Leave a Reply