are all about Identity Relationship Management, about helping to deliver and protect great web based services to users, devices and "things".
But the secret to delivering a great service is in knowing exactly who you're talking to. This involves Authentication and that's just one of the functions of OpenAM
, part of the Open Identity Stack from ForgeRock.
"Authentication" to many people means logging-in by supplying usernames and passwords which are checked against back-end directory servers, databases, or other systems. But with the massive adoption of Mobile technology there are an increasing number of alternative ways for users to reliably identify themselves including:
- one time passwords (maybe sent via email or SMS)
- PKI using certificates on devices
- multi-factor authenticators (used to be security fobs but now increasingly phone Apps)
- biometric authentication
...to name just a few.
OpenAM supports a vast array of authentication modules but what is v. cool is that these can be "chained" to deliver smarter, context-aware authentication. Let me explain...
Suppose I want to deliver a web-based service to my community members or customers. The service is pretty valuable so I want to make sure that only those people who subscribed to it can get it. Therefore, I want to use multi-factor authentication (MFA). But I've also had feedback from subscribers that says MFA is a pain when logging in frequently. So here's the plan:
- At the first login attempt from a device we've never seen before we should require MFA;
- subsequent logins from that device can use simple username/password;
- but every 30 days I want to force MFA again, just to make sure.
In OpenAM you can create a chain that looks like this:
- collect username and password credentials from the user and ensure they're valid against the DataStore (in my case this was an LDAP directory); This must succeed (Required) before the chain continues;
- next, run the Adaptive authentication module of OpenAM. This is worthy of a whole blog post itself, but suffice to say that this was configured to look for a Device Cookie. If the cookie is present then we've got enough data to grant access. If not, we fall through to the HOTP (HMAC One-Time Password) module;
- The HOTP module knows the user is in the directory from step 1, so it looks for the email address (or cell phone for SMS delivery) and sends a One Time Password to the user with a time limited lifespan.
The user experience goes like this:
If I have typed in my credentials correctly, then the browser prompts me for a One Time Password, and before you can ask "where do I get one of those?", my phone goes "Ping" with, in my case, an email containing the said OTP.
Once I enter this, I am in to the site.
Now the cute thing is that the second time I visit this site, I don't need to enter a OTP because OpenAM set a Device cookie last time round.
Hence I have met all my objectives listed above, and both my security team and subscribers are happy.
P.S. A few details about the Adaptive Authentication Module Configuration:
The Device Registration Cookie was enabled thus:
Where the Risk Score is enough to tip us over the Risk Threshold.
And don't forget to specify the Adaptive Auth Post Authentication Processing class in the Chain configuration: