Examples of Two-Factor Authentication with Virtual Users

Example 1: Two-Factor Authentication with External Passcode Validation

Prerequisites

  1. In the SAP NetWeaver Administrator at http(s)://<host>:<port>/nwa, you have protected an application with the login module TOTPLoginModule, and the following login module options:

    Name of the Login Module Option

    Value of the Login Module Option

    What Does It Do

    tfa.first.factor.login.module

    SecureLoginModule20LDAP

    Verifies user’s credentials against preconfigured LDAP server.

    UserMappingMode

    VirtualUser

    If the user authenticated by the first factor login module does not exist in the UME database, a virtual user is created for the duration of the application session.

  2. You have created a policy for external passcode validation. For more information, see Develop a Script for External Passcode Validation.
  3. You have configured external passcode validation. For more information, see Configuring External Passcode Validation.

How Does It Work

Michael Adams is an employee of company A. Michael logs into an application protected with the login module TOTPLoginModule. The first factor login module is SecureLoginModule20LDAP, so Michael is requested to provide his LDAP credentials. Michael provides the credentials, and the first step of the two-factor authentication succeeds. As there is no user called Michael Adams in the UME data source, a new virtual user is created with no attribute, role, or group assignments. Michael is prompted to enter a passcode. After providing the passcode, this is validated externally, and Michael is successfully authenticated.

When Michael logs out of the application, or the application session expires, the virtual user is deleted.

Example 2: Two-Factor Authentication with SAMLLoginModule and Passcode Sent via Email

Prerequisites

  1. You have configured SAP NetWeaver Application Server (AS) Java as a service provider. For more information, see Configuring AS Java as a Service Provider.

  2. You have configured trust between the service provider and an identity provider. For more information, see Trusting an Identity Provider.
  3. You have configured federation type virtual users, and have mapped SAML 2.0 attribute email. For more information, see Configuring Federation Type Virtual Users.
  4. In the SAP NetWeaver Administrator at http(s)://<host>:<port>/nwa, you have protected an application with the login module TOTPLoginModule, and the following login module options:

    Name of the Login Module Option

    Value of the Login Module Option

    What Does It Do

    tfa.first.factor.login.module

    SAML2LoginModule

    Uses SAML 2.0 as first factor authentication.

  5. You have created a policy to send an email with the passcode. For more information, see Configuring Authentication with a Random Passcode Sent by SMS, E-Mail, or Another Channel.

How Does It Work

Michael Adams is an employee of company A. Michael opens the application protected with the login module TOTPLoginModule and is redirected to the identity provider in order to authenticate. After Michael authenticates on the identity provider, he is redirected back to the service provider. The first factor authentication passes successfully, and SAML2LoginModule creates VirtualUserPrincipal.

The user Michael Adams does not exist in the UME on the service provider, and does not have one-time password activation, so he could not provide a second factor. As the user principal created by the first factor login module is VirtualUserPrincipal, a new virtual user is created with groups, roles and attributes assigned as defined in VirtualUserPrincipal. An e-mail with the passcode is sent to Michael's e-mail address. Michael uses this passcode for the second factor authentication, and the overall authentication to the protected application succeeds.

Example 3: Two-Factor Authentication with 3rd Party Login Module and Passcode Sent via Email

This example is very similar to Example 1, but instead of using the login module option UserMappingMode, a VirtualUserPrincipal is created via a policy script. In the policy script, you can specify attributes, groups, and roles to be assigned to the virtual user.

Prerequisites

  1. In the SAP NetWeaver Administrator at http(s)://<host>:<port>/nwa, you have protected an application with the login module TOTPLoginModule, and the following login module option:

    Name of the Login Module Option

    Value of the Login Module Option

    What Does It Do

    tfa.first.factor.login.module

    <3rd party login module name>

    Authenticates the user according to the 3rd party login module’s logic.

  2. You have created a policy script in the Policy Script Administration Console, which replaces the user principal from the first step of authentication in the onUserIdentified() function with a new VirtualUserPrincipal, specifying details for the user (for example, email attribute). The policy also must send an e-mail to the user’s e-mail address with the passcode for the second step of authentication. For more information on how to create new virtual principal, see Policy Script Functions and Methods.
  3. You have set this policy in the One-Time Password Administration UI at http(s)://<host>:<port>/ssoadmin/otp.

How Does It Work

Michael Adams is an employee of company A. Michael does not have a persistent user in the UME database, but the 3rd party login module can authenticate Michael against an external data source. Michael logs into an application protected with the login module TOTPLoginModule. The 3rd party login module authenticates Michael successfully. The policy script replaces the 3rd party user principal created by the 3rd party login module with a new VirtualUserPrincipal. In the policy script, you can specify roles, groups and attributes for the new virtual user that will be created. For this example, the e-mail attribute must be specified, so that an e-mail containing the passcode for the second step of authentication can be sent to the user. The virtual user is created successfully after the first step of the authentication, and an e-mail with the passcode is sent to Michael's e-mail address. Michael uses this passcode for the second factor, and the overall authentication to the protected application succeeds.