IBM Security Verify

 View Only

Policy parameters for OTP mechanisms

By Jasmine Smith posted 9 days ago

  

In the last few Verify Access releases we’ve been adding more and more mechanism properties as policy parameters. This means that the configuration values don’t have to be static strings, but instead can be read from session or request parameters! It also means that certain parameters are no longer global configuration and can be specifically configured where needed.

We’re continuing our efforts to add more policy parameters in 10.0.8 with heaps of entries added for the OTP mechanisms. This includes MAC OTP, HOTP and TOTP.

This blog however is going to focus on the parameters added for TOTP with an example that also uses the new OTP enrollment mechanism.

We’re interested in the following TOTP parameter:

macAlgorithm
The algorithm that is used to generate the one-time password. Valid options include the following algorithms:

  • HmacSHA1
  • HmacSHA256
  • HmacSHA512

Policy parameters in action

This blog assumes that you have a reverse proxy instance already, and that it’s been configured with the Authentication and Context Based Access wizard. And that two users exist, testuser1 and testuser2.

First up, we need to create two InfoMap mechanisms, which we’ll use in our two policies.

Create Post OTP Enrollment mechanism

  1. In the configuration UI, go to AAC > Global Settings > Mapping Rules.
  2. Click Add.
  3. Enter the following code: 
    importClass(Packages.com.tivoli.am.fim.trustserver.sts.utilities.IDMappingExtUtils);
importMappingRule("BranchingHelper");

// Copyright contributors to the IBM Security Verify Access AAC Mapping Rules project.

IDMappingExtUtils.traceString("entry Post OTP Enrollment");

var errors = [];
var missing = [];
var rc = true;

var username = getUsernameFromSession();
if (username != null) {
    var dmapCache = IDMappingExtUtils.getIDMappingExtCache();
    dmapCache.put("new.otp.enroll."+username, "true", -1);
}
success.setValue(rc);
IDMappingExtUtils.traceString("exit Post OTP Enrollment");
  4. For the name, type in: Post_OTP_Enrollment
  5. For the category, select InfoMap
  6. Click Save and deploy the pending changes.
  7. Now go to AAC > Policy > Authentication > Mechanisms.
  8. Click Add, click Info Map Mechanism.
  9. For the name, type in: Post OTP Enrollment
  10. For the identifier, type in: post_otp_enroll
  11. Click Properties.
  12. Click Mapping Rule, then click Edit.
  13. From the dropdown, pick Post_OTP_Enrollment
  14. Click Ok, then click Save and deploy the pending changes.

Create Pre OTP Authentication mechanism

  1. In the configuration UI, go to AAC > Global Settings > Mapping Rules.
  2. Click Add.
  3. Enter the following code: 
    importClass(Packages.com.tivoli.am.fim.trustserver.sts.utilities.IDMappingExtUtils);
importMappingRule("BranchingHelper");

// Copyright contributors to the IBM Security Verify Access AAC Mapping Rules project.

IDMappingExtUtils.traceString("entry Pre OTP Authentication");

var errors = [];
var missing = [];
var rc = true;

var username = getUsernameFromSession();
var dmapCache = IDMappingExtUtils.getIDMappingExtCache();

if (username != null && dmapCache.exists("new.otp.enroll."+username)) {
    context.set(Scope.SESSION, "urn:otp", "algorithm", "HmacSHA512");
} else {
    context.set(Scope.SESSION, "urn:otp", "algorithm", "HmacSHA1");
}
success.setValue(rc);
IDMappingExtUtils.traceString("exit Pre OTP Authentication");
  4. For the name, type in: Pre_OTP_Authentication
  5. For the category, select InfoMap
  6. Click Save and deploy the pending changes.
  7. Now go to AAC > Policy > Authentication > Mechanisms.
  8. Click Add, click Info Map Mechanism.
  9. For the name, type in: Pre OTP Authentication
  10. For the identifier, type in: pre_otp_auth
  11. Click Properties.
  12. Click Mapping Rule, then click Edit.
  13. From the dropdown, pick Pre_OTP_Authentication
  14. Click Ok, then click Save and deploy the pending changes.

Now we’ll build out the two policies.

Create TOTP Enrollment policy

  1. In the configuration UI, go to AAC > Policy > Authentication.
  2. Click Add.
  3. For the name, type in: TOTP Enrollment
  4. For the identifier, type in: totp_enroll
  5. Click Add Step.
  6. From the dropdown, select OTP Enrollment.
  7. Click the Parameters button.
  8. Enable the checkbox next to algorithm, select Value as the source, and select HmacSHA512 for the value.
  9. Enable the checkbox next to type, select Value as the source, and select totp for the value.
  10. Click OK and click OK again.
  11. Click Add Step.
  12. From the dropdown, select Post OTP Enrollment.
  13. Click OK.
  14. Click Save and deploy the changes.

Create TOTP Authentication policy

  1. In the configuration UI, go to AAC > Policy > Authentication.
  2. Click Add.
  3. For the name, type in: TOTP Authentication
  4. For the identifier, type in: totp_auth
  5. Click Add Step.
  6. From the dropdown, select Pre OTP Authentication.
  7. Click OK.
  8. Click Add Step.
  9. From the dropdown, select TOTP One-time Password.
  10. Click the Parameters button.
  11. Enable the checkbox next to macAlgorithm, select Session as the source, and type algorithm for the attribute ID and urn:otp for the namespace.
  12. Click OK and click OK again.
  13. Click Save and deploy the changes.

Now there’s one more setting we need to change before we can see this in action. Since there’s a new way to add TOTP and HOTP enrollements with the OTP Enrollment, the old way of adding them was deactivated. So we should go turn that back on.

  1. In the configuration UI, go to AAC > Global Settings > Advanced Configuration.
  2. In the filter, type otp.usc.legacyBehavior
  3. Click the edit button, and then click the Enabled button so that it is set to true.
  4. Click Save.
  5. In the filter, type sps.authService.policyKickoffMethod
  6. Click the edit button, and then choose both from the dropdown.
  7. Click Save and deploy the pending changes

Time to try it out!

In a new browser tab, go to your reverse proxy URL and login as testuser1.

Then go to https://<reverse_proxy>/mga/sps/mga/user/mgmt/html/otp/otp.html

Scan the TOTP QR code with the authenticator app of your choice (we recommend IBM Verify!)
This adds a TOTP enrollment using the algorithm HmacSHA1.

Now, logout by going to https://<reverse_proxy>/pkmslogout

Log back in, but this time as testuser2.

Then go to https://<reverse_proxy>/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:totp_enroll

Again, scan the QR code with your authenticator app. This time we’re adding a TOTP enrollment using the algorithm HmacSHA512.

Then click continue, and enter the code generated by your app.

Click Validate, and then click Done!

After clicking Done, the Post OTP Enrollment InfoMap runs, saving an entry in the DMAP associated with the username to indicate that this enrollment has the higher algorithm set.

While we are logged in as testuser2, let’s try out the authentication policy. Go to https://<reverse_proxy>/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:totp_auth

The Pre OTP Authentication InfoMap automatically looks for the DMAP entry for the algorithm, and populates the session attribute we configured in the policy for the TOTP parameters. Because the DMAP entry exists, the algorithm is set to HmacSHA512.

Enter the next code generated by your authenticator for testuser2 (this must be different to the last one!) then click Validate.

The login should be successful with the algorithm set to HmacSHA512!

Logout by going to pkmslogout again: https://<reverse_proxy>/pkmslogout

Log back into your reverse proxy with testuser1 this time. Go back to the authentication policy at https://<reverse_proxy>/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:totp_auth

Because testuser1 did not use the TOTP Enrollment policy to add their enrollment, the algorithm was set to HmacSHA1, and no entry exists in the DMAP for testuser1. So the Pre OTP Authentication InfoMap sets the session parameter to HmacSHA1.

This time, enter the code generated for testuser 1. This should be successful! Both users can authenticate using the same policy, even though their enrollments have different algorithms!

0 comments
8 views

Permalink