Multi-factor authentication, why not?

With enterprise systems moving to the cloud, security has never been so important.

As access to systems in the cloud are becoming more convenient, the more companies should strengthen access to these systems.

A few standard best practices include using strong encryption on data transit (VPN, SSL like HTTPS, etc.), multi-level firewalls, strong password policies, and more recently the emphasis of using stronger authentication mechanism like multi-factor authentication (MFA).

In recent years MFA had become popular not just to corporate but to the end-user. Thanks to Google’s Google-Authenticator (https://code.google.com/p/google-authenticator/), typical web user like myself am able to better secure my Google account (Gmail, G+, etc) and even cloud providers like Amazon allows MFA to Amazon Web Services using Google-Authenticator (read IAM topic). I can have comparable level of security  when I logon to my Google account to when I connect to my corporate network (e.g. using VPN). At what cost?  not much or actually no cost at all, assuming I already have a smart device – iphone/android/etc..

The concept of MFA is not new. In the context of this blog, the concept is quite simple – with a security token associated to my account, someone may have a hard time guessing my password but even harder to steal my phone!

In my previous blog I have played with Custom Login module in the Portal to implement single-signon to the SAP NW Portal using a Facebook account (http://scn.sap.com/community/social-media/blog/2013/02/17/login-with-facebook-anyone)

This blog is a continuation of the concepts of the custom LoginModule. This time, demonstrating how to customise the SAP NW Portal logon to enable MFA.

Here are the components

1. Logon Page – this is a custom web application that is protected by Form login. The Logon page looks as follows. I’m not good at web design, so I have to give credits (end of this blog) to those clever folks who provides tutorials

2. Login Module – This custom login module does the verification of the security token / code based on the secret key that is associated to the user. The generation and assocation of secret key (which happens first) is explained next

And again I’m not an expert in TOTP algorithm and the Google Authenticator PAM module, so credits (bottom of this page) again to those very clever people

What basically hapens in the Login module is as follows

– checks username if it is valid

– with the username, determine the secret key for this user. I have done simple implementation by saving the secret key into a file and reading the key from it. An extra check is also implemented to see if the file is there (then MFA is active), if not then MFA is not active. In the latter case, login will proceed successfully (security code is skipped as with normal Basic authentication)

– with the secret key, verify if the code passed in the logon screen is valid

– return true in login() for successful logon

3.Logon redirect  – this is just redirect page to the portal (/irj/portal), and is part of the custom logon page in #1 above. This page is protected by the custom Login Module. The JAAS stack loos like the following.

EvaluateTicket – if the user is already logged in the Portal (has valid SSO token), then no need to prompt for logon

BasicPassword – does the form based user/pass check

GAuthLogin – checks the validity security token / code

CreateTicket – upon successful logon with user, pass, code combination, create SSO token

4. MFA registration and activation – HTML and JSP files to basically generate a secret key, show the QR code so Google Authentication app can store it, and the Portal to store the secret key to the file associated to the user

Secret key is saved to a file

Once active, then account is ready for MFA

Credits:

http://designwoop.com/2011/04/create-a-clean-and-stylish-login-form-with-html5-and-css3/

http://thegreyblog.blogspot.co.nz/2011/12/google-authenticator-using-it-in-your.html