Still on DSEE? Try ForgeRock OpenDJ

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

This post in inspired by Ludovic Poitou’s reply to a thread in the ForgeRock OpenDJ Forum around DSEE to ForgeRock OpenDJ migration. Consider this to be just a hint, and not an answer. In a video log that’s embedded just below this write up, you’ll see some clues on a couple of different methods that you could consider to move away from a product that’s now in sustaining stage to ForgeRock’s Directory Services Solution. I don’t need to mention here how important a task it is to carefully draft a plan for migration from one product to another, and I’m sure you’ll not take this video log as the only reference while doing so.

So if you’ve half an hour to spare, you’ll see in the video:
Act 1:
– A ‘Flash Back’ on DSEE installation and configuration
– Exporting the data from the DSEE instance
– Installation & Configuration of ForgeRock OpenDJ
– Importing the DSEE instance backup to ForgeRock OpenDJ
Act 2:
– Installation of ForgeRock OpenIDM
– Configuration of External LDAP Server (DSEE instance) as a Managed Resource in ForgeRock OpenIDM (using samples)
– Configuration of OpenDJ instance as a Managed Resource in ForgeRock OpenIDM (using the UI)
– Reconciliation between the DSEE instance (source) and OpenDJ instance (target)

Enjoy!

REST on every side

This blog post was first published @ http://identityrocks.blogspot.fr/, included here with permission.

Regardless if web application, mobile application, device application or thing application development – identity management is there for you. Be it internal or external. The fast way in is REST. ForgeRock’s identity management platform delivers through REST. I’ll illustrate by example authentication via REST against a complex authentication chain.

“Representational State Transfer (REST) is a software architecture style for building scalable web services.” [1] [2]

The Authentication Chain
OpenAM’s authentication service can be composed of multiple authentication modules. The authentication chain consists 4 authentication modules including LDAP and device fingerprint. The relevance of such a chain was discussed in a previous article titled “Smarter Security with Device Fingerprints”.
For the purpose of simplicity, the OneTimePassword is replaced with a DataStore authentication module. Rather than providing a one time password (e.g. SMS passcode), the user has to provide username and password (same or different than before depending on the OpenAM configuration).
As there is no browser involved, any json structure can be sent back as the fingerprint.
The authentication process consists of 6 steps if no corresponding and valid device fingerprint was previously registered. In case it was, the authentication finishes after step 3.

The Tools: CURL, JQ and the Scripts
As client in this example serves the straightforward curl tool. This allows easy investigation of requests and responses.
Note that the JWT (JSON Web Token) needs to be passed on between all callbacks. For extracting specific elements of json, like the JWT, the jq tool can be of great use (for instance JWT_TOKEN=`echo ${CURL_RESPONSE} | jq –raw-output ‘.authId’`).
In case you want to build this example or something similar, I published in a GitHub project  scripts which could be of inspiration (see in particular 620-deviceid-base-config, 621-deviceid-rest-base, 622-deviceid-rest-ootb).

The Authentication Steps in Detail [3]
Step 1: Get the authentication token
An “empty” request is sent to obtain the JWT (JSON Web Token) and the first set of callbacks.

Request
curl -s –request POST –header “Content-Type: application/json” https://sso.yellowstone.com:443/sso/json/authenticate?realm=/deviceidrealm
Response

{
  "authId": "eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogImdvbGhwOHFrNDVtbTI5cm91YWpyOHI2b2dkIiwgInJlYWxtIjogIm89ZGV2aWNlaWRyZWFsbSxvdT1zZXJ2aWNlcyxkYz1zc28tY29uZmlnLGRjPWNvbSIsICJzZXNzaW9uSWQiOiAiQVFJQzV3TTJMWTRTZmN5dDJ5VTFoc3J1OHZNZkhzVW1hMjd1QjA0S3YtQk5iZEUuKkFBSlRTUUFDTURJQUFsTkxBQk10TlRrek9UQXlOek0yTURJME1EZ3lNakkyQUFKVE1RQUNNREUuKiIgfQ.ZQGuCe3qDUEchsxcDCLdRU73g1i-isUAZDdp5ZOvVdM",
  "template": "",
  "stage": "LDAP1",
  "header": "Sign in to OpenAM",
  "callbacks": [
    {
      "type": "NameCallback",
      "output": [
        {
          "name": "prompt",
          "value": "User Name:"
        }
      ],
      "input": [
        {
          "name": "IDToken1",
          "value": ""
        }
      ]
    },
    {
      "type": "PasswordCallback",
      "output": [
        {
          "name": "prompt",
          "value": "Password:"
        }
      ],
      "input": [
        {
          "name": "IDToken2",
          "value": ""
        }
      ]
    }
  ]
}

Step 2: Provide callbacks for LDAP module
The JWT is passed with any subsequent request in this authentication process. Username and password are passed as required by the LDAP authentication module’s callback.

Request
curl -s –request POST –header “Content-Type: application/json” –data @callback-step2.json https://sso.yellowstone.com:443/sso/json/authenticate?realm=/deviceidrealm
callback-step2.json :

{
  "authId": "eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogImdvbGhwOHFrNDVtbTI5cm91YWpyOHI2b2dkIiwgInJlYWxtIjogIm89ZGV2aWNlaWRyZWFsbSxvdT1zZXJ2aWNlcyxkYz1zc28tY29uZmlnLGRjPWNvbSIsICJzZXNzaW9uSWQiOiAiQVFJQzV3TTJMWTRTZmN5dDJ5VTFoc3J1OHZNZkhzVW1hMjd1QjA0S3YtQk5iZEUuKkFBSlRTUUFDTURJQUFsTkxBQk10TlRrek9UQXlOek0yTURJME1EZ3lNakkyQUFKVE1RQUNNREUuKiIgfQ.ZQGuCe3qDUEchsxcDCLdRU73g1i-isUAZDdp5ZOvVdM",
  "template": "",
  "stage": "LDAP1",
  "callbacks": [
    {
      "type": "NameCallback",
      "output": [
        {
          "name": "prompt",
          "value": " User Name: "
        }
      ],
      "input": [
        {
          "name": "IDToken1",
          "value": "demo"
        }
      ]
    },
    {
      "type": "PasswordCallback",
      "output": [
        {
          "name": "prompt",
          "value": " Password: "
        }
      ],
      "input": [
        {
          "name": "IDToken2",
          "value": "changeit"
        }
      ]
    }
  ]
}

Response
After successful LDAP authentication, the JavaScript which computes the fingerprint is sent in the TextOutputCallback.

{
  "authId": "eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogImdvbGhwOHFrNDVtbTI5cm91YWpyOHI2b2dkIiwgInJlYWxtIjogIm89ZGV2aWNlaWRyZWFsbSxvdT1zZXJ2aWNlcyxkYz1zc28tY29uZmlnLGRjPWNvbSIsICJzZXNzaW9uSWQiOiAiQVFJQzV3TTJMWTRTZmN5dDJ5VTFoc3J1OHZNZkhzVW1hMjd1QjA0S3YtQk5iZEUuKkFBSlRTUUFDTURJQUFsTkxBQk10TlRrek9UQXlOek0yTURJME1EZ3lNakkyQUFKVE1RQUNNREUuKiIgfQ.ZQGuCe3qDUEchsxcDCLdRU73g1i-isUAZDdp5ZOvVdM",
  "template": "",
  "stage": "DeviceIdMatch2",
  "header": "Sign in to OpenAM",
  "callbacks": [
    {
      "type": "HiddenValueCallback",
      "output": [
        {
          "name": "value",
          "value": ""
        }
      ],
      "input": [
        {
          "name": "IDToken1",
          "value": "clientScriptOutputData"
        }
      ]
    },
    {
      "type": "TextOutputCallback",
      "output": [
        {
          "name": "message",
          "value": "JAVASCRIPT TO BE EXECUTED IN THE CLIENT BROWSER. OMITTED FOR READABILITY"
        },
        {
          "name": "messageType",
          "value": "4"
        }
      ]
    }
  ]
}

Step 3: Provide callbacks for DeviceId (Match) module
The fingerprint is sent back to the authentication process through the HiddenValueCallback. As there is no browser involved, any json element can be sent in. Note that the value element is of type String and the String contains the json. So properly encode the json (i.e. escape double quotes).

Request
curl -s –request POST –header “Content-Type: application/json” –data @callback-step3.json https://sso.yellowstone.com:443/sso/json/authenticate?realm=/deviceidrealmcallback-step3.json :

{
  "authId": "eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogImdvbGhwOHFrNDVtbTI5cm91YWpyOHI2b2dkIiwgInJlYWxtIjogIm89ZGV2aWNlaWRyZWFsbSxvdT1zZXJ2aWNlcyxkYz1zc28tY29uZmlnLGRjPWNvbSIsICJzZXNzaW9uSWQiOiAiQVFJQzV3TTJMWTRTZmN5dDJ5VTFoc3J1OHZNZkhzVW1hMjd1QjA0S3YtQk5iZEUuKkFBSlRTUUFDTURJQUFsTkxBQk10TlRrek9UQXlOek0yTURJME1EZ3lNakkyQUFKVE1RQUNNREUuKiIgfQ.ZQGuCe3qDUEchsxcDCLdRU73g1i-isUAZDdp5ZOvVdM",
  "template": "",
  "stage": "DeviceIdMatch2",
  "callbacks": [
    {
      "type": "HiddenValueCallback",
      "input": [
        {
          "name": "IDToken1",
          "value": "THE FINGERPRINT GATHERED "
        }
      ]
    },
    {
      "type": "TextOutputCallback",
      "output": [
        {
          "name": "messageType",
          "value": "4"
        }
      ]
    }
  ]
}
Response

If the fingerprint corresponds to a registered fingerprint, then the authentication process would return successfully at this point. Otherwise (in this case), a second factor is required (DataStore module).

{
  "authId": "eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogImdvbGhwOHFrNDVtbTI5cm91YWpyOHI2b2dkIiwgInJlYWxtIjogIm89ZGV2aWNlaWRyZWFsbSxvdT1zZXJ2aWNlcyxkYz1zc28tY29uZmlnLGRjPWNvbSIsICJzZXNzaW9uSWQiOiAiQVFJQzV3TTJMWTRTZmN5dDJ5VTFoc3J1OHZNZkhzVW1hMjd1QjA0S3YtQk5iZEUuKkFBSlRTUUFDTURJQUFsTkxBQk10TlRrek9UQXlOek0yTURJME1EZ3lNakkyQUFKVE1RQUNNREUuKiIgfQ.ZQGuCe3qDUEchsxcDCLdRU73g1i-isUAZDdp5ZOvVdM",
  "template": "",
  "stage": "DataStore1",
  "header": "Sign in to OpenAM",
  "callbacks": [
    {
      "type": "NameCallback",
      "output": [
        {
          "name": "prompt",
          "value": "User Name:"
        }
      ],
      "input": [
        {
          "name": "IDToken1",
          "value": ""
        }
      ]
    },
    {
      "type": "PasswordCallback",
      "output": [
        {
          "name": "prompt",
          "value": "Password:"
        }
      ],
      "input": [
        {
          "name": "IDToken2",
          "value": ""
        }
      ]
    }
  ]
}

Step 4: Provide callbacks for DataStore module
Request
curl -s –request POST –header “Content-Type: application/json” –data @callback-step4.json https://sso.yellowstone.com:443/sso/json/authenticate?realm=/deviceidrealm

callback-step4.json :

{
  "authId": "eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogImdvbGhwOHFrNDVtbTI5cm91YWpyOHI2b2dkIiwgInJlYWxtIjogIm89ZGV2aWNlaWRyZWFsbSxvdT1zZXJ2aWNlcyxkYz1zc28tY29uZmlnLGRjPWNvbSIsICJzZXNzaW9uSWQiOiAiQVFJQzV3TTJMWTRTZmN5dDJ5VTFoc3J1OHZNZkhzVW1hMjd1QjA0S3YtQk5iZEUuKkFBSlRTUUFDTURJQUFsTkxBQk10TlRrek9UQXlOek0yTURJME1EZ3lNakkyQUFKVE1RQUNNREUuKiIgfQ.ZQGuCe3qDUEchsxcDCLdRU73g1i-isUAZDdp5ZOvVdM",
  "template": "",
  "stage": "DataStore1",
  "callbacks": [
    {
      "type": "NameCallback",
      "output": [
        {
          "name": "prompt",
          "value": " User Name: "
        }
      ],
      "input": [
        {
          "name": "IDToken1",
          "value": "demo"
        }
      ]
    },
    {
      "type": "PasswordCallback",
      "output": [
        {
          "name": "prompt",
          "value": " Password: "
        }
      ],
      "input": [
        {
          "name": "IDToken2",
          "value": "changeit"
        }
      ]
    }
  ]
}
Response 

Now that both factors succeeded, the user is asked whether to store the device fingerprint or not.

{
  "authId": "eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogImdvbGhwOHFrNDVtbTI5cm91YWpyOHI2b2dkIiwgInJlYWxtIjogIm89ZGV2aWNlaWRyZWFsbSxvdT1zZXJ2aWNlcyxkYz1zc28tY29uZmlnLGRjPWNvbSIsICJzZXNzaW9uSWQiOiAiQVFJQzV3TTJMWTRTZmN5dDJ5VTFoc3J1OHZNZkhzVW1hMjd1QjA0S3YtQk5iZEUuKkFBSlRTUUFDTURJQUFsTkxBQk10TlRrek9UQXlOek0yTURJME1EZ3lNakkyQUFKVE1RQUNNREUuKiIgfQ.ZQGuCe3qDUEchsxcDCLdRU73g1i-isUAZDdp5ZOvVdM",
  "template": "",
  "stage": "DeviceIdSave2",
  "header": "Add to Trusted Devices",
  "callbacks": [
    {
      "type": "ChoiceCallback",
      "output": [
        {
          "name": "prompt",
          "value": "Add to Trusted Devices?"
        },
        {
          "name": "choices",
          "value": [
            "Yes",
            "No"
          ]
        },
        {
          "name": "defaultChoice",
          "value": 1
        }
      ],
      "input": [
        {
          "name": "IDToken1",
          "value": 1
        }
      ]
    }
  ]
} 

Step 5: Provide callbacks for DeviceId (Save) module – Consent to store device profile
The value 0 in the ChoiceCallback indicates that the user want to store the device fingerprint with his profile.

Request
curl -s –request POST –header “Content-Type: application/json” –data @callback-step5.json https://sso.yellowstone.com:443/sso/json/authenticate?realm=/deviceidrealm 
callback-step5.json :

{
  "authId": "eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogImdvbGhwOHFrNDVtbTI5cm91YWpyOHI2b2dkIiwgInJlYWxtIjogIm89ZGV2aWNlaWRyZWFsbSxvdT1zZXJ2aWNlcyxkYz1zc28tY29uZmlnLGRjPWNvbSIsICJzZXNzaW9uSWQiOiAiQVFJQzV3TTJMWTRTZmN5dDJ5VTFoc3J1OHZNZkhzVW1hMjd1QjA0S3YtQk5iZEUuKkFBSlRTUUFDTURJQUFsTkxBQk10TlRrek9UQXlOek0yTURJME1EZ3lNakkyQUFKVE1RQUNNREUuKiIgfQ.ZQGuCe3qDUEchsxcDCLdRU73g1i-isUAZDdp5ZOvVdM",
  "template": "",
  "stage": "DeviceSave2",
  "callbacks": [
    {
      "type": "ChoiceCallback",
      "input": [
        {
          "name": "IDToken1",
          "value": "0"
        }
      ]
    }
  ]
}
Response

Then the user is prompted to provide a name under which the new profile shall be stored.

{
  "authId": "eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogImdvbGhwOHFrNDVtbTI5cm91YWpyOHI2b2dkIiwgInJlYWxtIjogIm89ZGV2aWNlaWRyZWFsbSxvdT1zZXJ2aWNlcyxkYz1zc28tY29uZmlnLGRjPWNvbSIsICJzZXNzaW9uSWQiOiAiQVFJQzV3TTJMWTRTZmN5dDJ5VTFoc3J1OHZNZkhzVW1hMjd1QjA0S3YtQk5iZEUuKkFBSlRTUUFDTURJQUFsTkxBQk10TlRrek9UQXlOek0yTURJME1EZ3lNakkyQUFKVE1RQUNNREUuKiIgfQ.ZQGuCe3qDUEchsxcDCLdRU73g1i-isUAZDdp5ZOvVdM",
  "template": "",
  "stage": "DeviceIdSave3",
  "header": "Trusted Device Name",
  "callbacks": [
    {
      "type": "NameCallback",
      "output": [
        {
          "name": "prompt",
          "value": "Trusted Device Name?"
        }
      ],
      "input": [
        {
          "name": "IDToken1",
          "value": ""
        }
      ]
    }
  ]
}

Step 6: Provide callbacks for DeviceId (Save) module – Device profile name
Then If an empty Then If an empty v is provided as the device name, the authentication module will compute one which looks like “Profile: 21/08/2015 15:51”.
Request
curl -s –request POST –header “Content-Type: application/json” –data @callback-step6.json https://sso.yellowstone.com:443/sso/json/authenticate?realm=/deviceidrealm 
callback-step6.json :

{
  "authId": "eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAib3RrIjogImdvbGhwOHFrNDVtbTI5cm91YWpyOHI2b2dkIiwgInJlYWxtIjogIm89ZGV2aWNlaWRyZWFsbSxvdT1zZXJ2aWNlcyxkYz1zc28tY29uZmlnLGRjPWNvbSIsICJzZXNzaW9uSWQiOiAiQVFJQzV3TTJMWTRTZmN5dDJ5VTFoc3J1OHZNZkhzVW1hMjd1QjA0S3YtQk5iZEUuKkFBSlRTUUFDTURJQUFsTkxBQk10TlRrek9UQXlOek0yTURJME1EZ3lNakkyQUFKVE1RQUNNREUuKiIgfQ.ZQGuCe3qDUEchsxcDCLdRU73g1i-isUAZDdp5ZOvVdM",
  "template": "",
  "stage": "DeviceIdSave3",
  "callbacks": [
    {
      "type": "NameCallback",
      "input": [
        {
          "name": "IDToken1",
          "value": ""
        }
      ]
    }
  ]
} 
Response
Now the response contains an SSOToken. This means the authentication was successful.
{
  "tokenId": "AQIC5wM2LY4SfczOURj5zOskLzpSNfuSU9GYnW5XTu8Tudg.*AAJTSQACMDIAAlNLABM2OTIyMTc1MTIwOTUxMTA2NTcxAAJTMQACMDE.*",
  "successUrl": "/sso/console"
}

“And the LORD gave them rest on every side”. Joshua 21:44 [4]

 

References

[1] Pautasso, Cesare; Wilde, Erik; Alarcon, Rosa (2014), REST: Advanced Research Topics and Practical Applications
[2] Wikipedia contributors. “Representational state transfer.” Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 1 Sep. 2015. Web. 1 Sep. 2015.
[3] Craig, Mark; Goldsmith, David; Hirayama, Gene: Lee, Chris, et al. OpenAM Developer’s Guide Version 13.0.0-SNAPSHOT. ForgeRock, AS., 2015. <http://openam.forgerock.org/openam-documentation/openam-doc-source/doc/webhelp/dev-guide/rest-api-auth-json.html>
[4] The Holy Bible, New International Version, NIV Copyright 1973, 1978, 1984, 2011 by Biblica

Certification in ForgeRock OpenIDM – Concluding Episode

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

This blog entry picks up from my earlier blog post around Certification facility in ForgeRock OpenIDM. Like many of my other video demonstration, this one also is based on the neat ForgeRock documentation on OpenIDM. So without any further ado, let me present unto you my video log on Certification in ForgeRock OpenIDM.

Enjoy!

Certification in ForgeRock OpenIDM Episode I: Initial Reconciliation

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

If this was a book, what we have here is a prologue. Just as you don’t expect the prologue to throw a full story at you, so does this web log unveil absolutely no details around Certification in ForgeRock OpenIDM. What it does though is to setup a ‘plot’ for a possible video demonstration on Certification facility in ForgeRock’s Identity Management Solution. And that’s coming soon…

So in the video log, that’s actually a visual representation of the brilliant ForgeRock Documentation on OpenIDM, you’ll see:
– Installation of ForgeRock OpenDJ
– Configuration of OpenDJ as an external resource managed by OpenIDM (using sample files)
– Performing the initial reconciliation using REST to load users from OpenDJ to OpenIDM

Soon we’ll put all those users in action for Certification in OpenIDM. For now, just as you’d skim through the prologue of a book, take a quick look at the ~5 minute video

Baby Step in DTrace on ForgeRock OpenDJ

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

I’m a big fan of Brendan Gregg. The DTrace Book that he co-authored with Jim Mauro stands one of the best I’ve read in Computer Science. While I continue to take my baby steps in DTrace, I thought I’d share with you my video log on attempting to explore ForgeRock OpenDJ using the pid provider in DTrace. Brendan Gregg has published a number of blogs around the pid provider, all of which is accessible from his consolidated blog entry here. OTN has very generously published one chapter from the DTrace Book that talks of using DTrace on Applications, in which the pid provider and its use is detailed.

And with the source code of all ForgeRock Products accessible to the public for study, DTrace might just be the tool that you may want to get your hands on for some fun.

Enjoy!

Provisioning Users to PostgreSQL Database Table Using ForgeRock OpenIDM

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

This one is rather uncomplicated. ForgeRock OpenIDM does provisioning well, be it to a Directory Server, a Database or even to several other external resources. The following video log demonstrates exactly that. You’ll see:

– Super quick installation of ForgeRock OpenIDM
– Installation of PostgreSQL database, creation of user with super user role in PostgreSQL, creation of a database and finally creation of a table
– Configure the OpenIDM Database connector to connect to the PostgreSQL database table created in the above mentioned step
– And finally see how the users from OpenIDM are provisioned on to the PostgreSQL database table

It’s all very simple and easy to understand. So enjoy!

Smarter Security with Device Fingerprints

This blog post was first published @ http://identityrocks.blogspot.fr/, included here with permission.

Smarter security also means user friendly security, moving security beyond compromising convenience.

Multi-factor authentication has many benefits. Going through multiple factors multiple times in a same day from the same device, makes users grumble, especially when working at the office all day. Security can be smarter than that.

It happens to be that web browsers in the hand of individual users develop an increasing level of uniqueness based on a combination of parameters such as browser type, installed fonts and plugins, resolution and colour depth, timezone, preferred language, and even geolocation. All these elements (and potentially others) combined represent the browser fingerprint.

So the user who has already authenticated in the morning using username, password and SMS passcode as a 2nd factor comes back from lunch. A more convenient single factor authentication (username and password) can often be suitable if the user is using from the same device. In reality, users authenticate more often than that against the same system the same day.

The National Institute of Standards and Technology (NIST) researched the friction and disruption created by authentication. It concludes that any authentication task that requires time and effort on the part of the user creates a “wall of disruption” that impedes the performance of primary tasks, even when there are no problems [1].

Besides implementing SSO, device fingerprints are a compelling asset to lower the “wall of disruption.” ForgeRock’s identity platform provides this functionality right out of the box (since OpenAM 12). On top, browser fingerprint collection, matching and storing can be customized and extended. The functionality is part of the commercial and open source, as smart security software should be.

As privacy is built into ForgeRock’s DNA and products, device fingerprints are stored with user consent and the user can view and delete them anytime.

Device Fingerprints in the Authentication Process

OpenAM provides two authentication modules to support device or browser fingerprint. First, the “Device ID (Match)”  module, which invokes the collection of the fingerprint via JavaScript (executed in the user’s web browser), compares the collected fingerprint with stored fingerprints and determines if the device can be considered as known. And second the  “Device ID (Save)” module, which stores, if appropriate, the newly collected fingerprint in the data store.

Device fingerprint authentication is used in combination with other authentication modules with the goal to spare users multiple factors of authentication. Typically users are challenged with a first factor like username password. Only if this succeeds will the fingerprint then be collected and compared with stored fingerprints. If the device is not “known,” the user will face a second factor of authentication like one-time-password via SMS. Only after the second factor succeeded, and upon user consent, will the fingerprint then be stored. If however the device is “known,” no further processing is necessary and user authentication succeeded.

The OpenAM Admin Guide has a bunch of further hints on how to chain the device ID modules with other modules [2].

Privacy and Consent

Before storing a device fingerprint, the user is asked for consent. If a user does not decide to store browser fingerprints, then the device fingerprint modules have no effect and the authentication continues as defined in the authentication chain. Stored browser fingerprints can be managed as “Trusted Devices” by the enduser through the enduser dashboard. By default, device fingerprints have a lifetime of 30 days.

Inside the Device Fingerprint Module

The “DeviceID (Match)” module stores the collected fingerprint in the shared state memory element of the authentication modules (key is devicePrintProfile). This value is picked up by the “DeviceID (Save)” module (if the process gets that far)  from the shared state and then stored in the data store.
Browser fingerprints are stored in the user datastore. For instance, with the embedded store (by default) in the multi-valued attribute devicePrintProfiles in the following form (“pretty printed”):

{
  "lastSelectedDate": 1437623008779,
  "devicePrint": {
    "screen": {
      "screenWidth": 1440,
      "screenHeight": 900,
      "screenColourDepth": 24
    },
    "timezone": {
      "timezone": -120
    },
    "plugins": {
      "installedPlugins": "widevinecdmadapter.plugin;mhjfbmdgcfjbbpaeojofohoefgiehjai;PepperFlashPlayer.plugin;internal-remoting-viewer;internal-nacl-plugin;internal-pdf-viewer;"
    },
    "fonts": {
      "installedFonts": "cursive;monospace;serif;sans-serif;fantasy;default;Arial;Arial Black;Arial Narrow;Arial Rounded MT Bold;Comic Sans MS;Courier;Courier New;Georgia;Impact;Papyrus;Tahoma;Times;Times New Roman;Trebuchet MS;Verdana;"
    },
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.130 Safari/537.36",
    "appName": "Netscape",
    "appCodeName": "Mozilla",
    "appVersion": "5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.130 Safari/537.36",
    "platform": "MacIntel",
    "product": "Gecko",
    "productSub": "20030107",
    "vendor": "Google Inc.",
    "language": "en-US",
    "geolocation": {
      
    }
  },
  "name": "MacBookChrome",
  "selectionCounter": 1,
  "uuid": "a85e66e4-5de3-4795-be43-7159e9590cbb"
}

As mentioned before, the collection and matching can be extended and customised.

Further Reading

The Electronic Frontier Foundation published an interesting article “How Unique Is Your Web  Browser?”  in which, amongst other topics, research on diversity and stability of browser fingerprints is exposed. It concludes :

“Browser fingerprinting is a powerful technique, and fingerprints must be considered alongside cookies, IP addresses and supercookies when we discuss web privacy and user trackability. Although fingerprints turn out not to be particularly stable, browsers reveal so much version and configuration information that they remain overwhelmingly trackable. There are implications both for privacy policy and technical design. Policymakers should start treating fingerprintable records as potentially personally identifiable, and set limits on the durations for which they can be associated with identities and sensitive logs like clickstreams and search terms.” [3]  Note that the default device fingerprint authentication modules support expiration of fingerprints.

Further research on the topic of browser fingerprinting shows alternative ways to compute a fingerprint. For instance, using HTML5 <canvas> elements [4] – and ways for users to circumvent fingerprinting, if they desire. The ForgeRock Identity Platform can cater to both methodologies, as it is open and extensible and honors privacy.

References

[1] Steves, M; Chisnell, D; Sasse, A; Krol, K; Theofanos, M; Wald, H; (2014) Report: Authentication Diary Study. (NIST Interagency or Internal Reports (NISTIR) NIST IR 7983 ). <http://dx.doi.org/10.6028/NIST.IR.7983>
[2] Goldsmith, David; Hirayama, Gene: Lee, Chris, et al. OpenAM Administration Guide, Version 12.0.0. ForgeRock, AS., December 17, 2014. August 28, 2015. <http://docs.forgerock.org/en/openam/12.0.0/admin-guide/index/chap-auth-services.html#device-id-match-hints>
[3] Eckersley, Peter; How Unique Is Your Web Browser? Electronic Frontier Foundation, 2010 <https://panopticlick.eff.org/browser-uniqueness.pdf>
[4] Mowery, Keaton and Shacham Hovav. Pixel Perfect: Fingerprinting Canvas in HTML5.  <http://w2spconf.com/2012/papers/w2sp12-final4.pdf>
[5] Wikipedia contributors. Device fingerprint. Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 27 Jul. 2015. Web. 28 Aug. 2015.

By Joachim Andres

Learning Curve

A few years ago I had the pleasure to work with Rajesh Rajasekharan at Sun. He was an efficient trainer on Sun products and especially on Sun Directory Server. He recently joined ForgeRock and has started a series of blog posts and screen-casts on ForgeRock products and especially OpenDJ, but not only !

If you are getting started with the products or want to see demos of them, there’s no better place than to be on the “Learning Curve

 


Filed under: Identity Tagged: demo, ForgeRock, openam, opendj, openidm, openig, products, screencast, Tips, tutorials, video