Multi Factor Authentication using Duo Security


Duo Security provides an array of security products including Duo Mobile which is a stronger method of authentication using a registered device per user. More details can be found here Duo Mobile.

OpenAM is able to invoke the Duo Security API with the “push” factor that uses a push notification to the Duo Mobile app installed on your device for one-tap authentication. Please note that the demo presented here is purely for instructional purposes.


The user and device are first registered with the Duo Security application platform. This is done by the designated administrator. Multiple integrations can be created per organization allowing categorization of user communities by device, geo location or other factors.

Configuration in Duo


You can setup certain users with special privileges such as “bypass”, etc.

The user-id in Duo Security must match the user-id in OpenAM’s user repository for the authentication to succeed.

Configuration in OpenAM

Chain the DataStore module with the custom Duo module.


The user simply has to enter username and password to OpenAM. After verification of username and password, OpenAM starts the Duo custom authentication module.

After hitting submit, the following placeholder screen is shown. This is automatically refreshed until the user accepts or rejects the logon attempt from their device.

The custom authentication module invokes the Duo REST API with factor=push, and username. The request is signed with the integration key and secret key. A transaction id is returned that is saved for polling the request in the next step. The user gets a push notification on their Duo Mobile app.

After opening the Duo Mobile app the user is presented with an accept/deny screen.

Meanwhile, OpenAM polls the Duo REST API using the transaction id to check if the user accepted the push-notification. If so, they are immediately logged into OpenAM.

The user may decline the logon attempt.

The user may indicate whether it was a mistake or seems fraudulent.


If declined, authentication to OpenAM is denied immediately.



Simplified pseudo-code for a custom authentication module is presented here.

func process[] {






               if “waiting”, set-next-auth-state[poll-step]

               if “allow”, set-next-auth-state[LOGIN_SUCCEED]

               if “deny”, throw Exception


func get-transactionId-from-Duo-REST-API[] {

    invoke-HTTP-POST on /auth/v2/auth


func poll-Duo-REST-API[] {

    invoke-HTTP-GET on /auth/v2/auth_status


Source Code

OpenAM Duo Security module on Github

OpenAM 2FA using the TeleSign PhoneID Score API


TeleSign PhoneID Score combines predictive data from multiple sources, including telecom data, traffic patterns, and reported fraud to assess the risk level of a phone number. The product provides a reputation score, ranging from 0 to 1000, a risk level, and a recommendation based on a user’s phone number. PhoneID Score provides a real-time score, risk assessment, and recommendation. The scoring algorithm is dynamically updated to match ever-changing fraud trends. In fact, whenever a user’s activities change so does the score. More information can be found at TeleSign .

TeleSign Verify SMS API can be used to authenticate a known user, verify a transaction, or block fraudsters from opening thousands of accounts on your site. TeleSign Verify SMS verifies users in real time by sending a one-time verification code via SMS to their mobile phone. TeleSign delivers SMS to more than 200 countries. More info can be found here.


A custom authentication module receives the user’s telephone number, and uses TeleSign PhoneID Score API to evaluate the risk level of the phone number. If the phone number is of acceptable risk (low or moderate), then the authentication module uses the TeleSign Verify SMS API to send a verification code to the phone number entered.

The API returns a risk level for the phone number. If the risk level is “allow”, the module will send a random verify code via the TeleSign Verify SMS API, and upon user entry, use the TeleSign Verify SMS API to verify the code.

If the risk level from Score API is “deny”, OpenAM will show a denied screen to the user. A deny response looks like this:

{"reference_id":"####","sub_resource":"score","errors":[],"status":{"updated_on":"2015-03-10T22:48:59.139040Z","code":300,"description":"Transaction successfully completed"},"numbering":{"original":{"phone_number":"####","complete_phone_number":"####","country_code":"92"},"cleansing":{"sms":{"phone_number":"####","country_code":"92","min_length":9,"max_length":12,"cleansed_code":105},"call":{"phone_number":"####","country_code":"92","min_length":9,"max_length":12,"cleansed_code":105}}},"risk":{"level":"high","score":959,"recommendation":"block"}}

If the user entered an incorrect code, the TeleSign Verify SMS API will indicate as such, and OpenAM will reject the login attempt.

If the verify code validates correctly, then the user simply has to enter their username to login to AM.

An low risk response from the TeleSign PhoneID Score API looks like this:

{"reference_id":"####","sub_resource":"score","errors":[],"status":{"updated_on":"2015-03-10T22:52:17.603141Z","code":300,"description":"Transaction successfully completed"},"numbering":{"original":{"phone_number":"####","complete_phone_number":"####","country_code":"1"},"cleansing":{"sms":{"phone_number":"####","country_code":"1","min_length":10,"max_length":10,"cleansed_code":100},"call":{"phone_number":"####","country_code":"1","min_length":10,"max_length":10,"cleansed_code":100}}},"risk":{"level":"low","score":1,"recommendation":"allow"}}

Note that TeleSign uses a global phone directory, so if you do not prefix your country code, it will take the first digit(s) from the phone from the left and use that to identify the country.

Source Code



This article was first published on the OpenAM Wiki Confluence site: OpenAM and TeleSign Integration

ForgeRock Authenticator (OATH) in ForgeRock OpenAM 13

This blog post was first published @, included here with permission.

If you’re in possession of a Smart Phone that runs either the Apple iOS or Android, you may probably be interested to know that the ForgeRock’s newer version of its Access Management solution now has an Authenticator App for you. Once installed and the device registered with ForgeRock OpenAM 13, one could use this Mobile App to generate One Time Password to validate his/her identity and thereby gain access to resources protected by the OpenAM. Needless to add, the ForgeRock Authenticator Mobile App is available on Apple iTunes Store for the iOS users and the Google Playstore for the Android fans.

Once installed, you’ll see on your phone something close to what is in the picture below:

Here’s what I did with my copy of ForgeRock Authenticator App on my iPhone:

– Configured an Authentication Chain ‘myAuthChain’ in my OpenAM 13 instance
– The said chain consisted of two Authentication Modules namely DataStore & ForgeRock Authenticator (OATH)
– When a subject authenticates against the ‘myAuthChain’ Authentication Chain in OpenAM, he/she is prompted for the DataStore credentials (an embedded OpenDJ instance), which on success is followed by another prompt where the user can register his/her device (using QR Code), generate an OTP that can be used to gain access to the resources protected by OpenAM.


If you are interested to see all of this in action, please spare five minutes to watch the video below.


Related documents/videos:
ForgeRock Documentation
Smart Security Using Phone App Demo

It’s Not Unhackable, But Twitter Makes a Start

This week Twitter introduced a new two-factor authentication process to verify account logins.  This comes on the back on some pretty big Twitter account hacks in recent months.  Now, whilst you can argue that it is not Twitter (or any other service providers) responsibility for you to keep your account details secure, they potentially do have a duty to some extent to make increased security an option if an end user does want to use it.

A typical end user isn't particularly interested in security.  Yes, they don't want hacking, yes, they don't want to have their bank details stolen, or their Facebook timeline polluted with nasties, but a typical end user won't actively take extra steps to avoid that from happening.

The concept of strong passwords is pretty much standard these days.  At least 8 characters, an uppercase letter, a number and / or a special character too.  End users have a list of passwords in their minds that fit the criteria.  Unfortunately these passwords are probably being recycled across every site that requires a 'complex' password, perhaps incrementing the number at the end every time it expires.

The use of secondary verification, become familiar for typical web users, when Facebook verification was introduced a year or two back.  If you login to Facebook from an unknown device or network location, you are asked to go through an additional set of verification steps.  This could include security question responses (knowledge based authentication), mobile verification or the most interesting in my mind, confirming you know the people in selected photos from your albums.  Again this is a form of KBA, but without the need to set up or remember arcane questions about your first pet or primary school.

To set up Twitter's additional verification isn't particularly complicated.  A couple of minutes setting up a phone to use as the registered verification device and a few test text messages and you're done.  Albeit the mobile anti-virus scanner on my phone flagged the responding text message from Twitter as 'suspicious' made me smile.

But will this extra step prevent hacks?  The simple answer is no, well yes in some cases, but maybe in others!  Basically there is no simple answer.  Of course it makes cold hacking a lot more difficult, due to having to break something someone knows (the password) alongside breaking the physical something someone has (the phone).  However, what happens if you lose your phone?  I for one do most of my tweeting from a smartphone as many others do to.  For a single end user that could pose an issue as both the Twitter client will undoubtedly have a cached password and obviously the physical phone is able to receive the text message for verification.

However, in corporate PR scenarios a large client may require a team of 3,4 or more executives managing the Twitter account.  Twitter is alive 24x7 and no one individual could manage that for a large consumer client.  This therefore results in multiple machines and potentially multiple clients.  Whilst those clients can be authorised, the security risk is spread as you have multiple access vectors for malware, accidental misuse, malicious misuse and so on.  So whilst Twitter has upped its game on the backend, end users still have a duty with regards managing who has access to the account in general and how those users are managed and vetted.

If nothing else, the introduction of an additional authentication factor increases the information security awareness for the typical end user and starts to make security a much more common step when using services and websites.  The important step next, for Twitter and others, is to make sure there is a larger security 'reward' for those who do engage in the extra steps.

By Simon Moffatt