Google+ Social Login Risk Profiling using ZeroFOX

Introduction

ZeroFOX Enterprise evaluates and records the risk associated with social media users and organizations. This evaluation is conducted through the ZeroFOX Enterprise security analysis engine which analyzes the full social graph for a targeted user to include their associated people, organizations and interactions.

The ZeroFOX Social Risk Score API allows OpenAM to query the ZeroFOX Enterprise Platform RESTful API for risk attributes associated with a given social media asset- social media user or organization. If ZF does not have recent ZeroFOX data on the requested asset, it is immediately submitted for analysis and can be queried again at a later time.

For purposes of this demo with Google Plus, I created a custom OpenAM 13 build that enables chaining the Scripted Authentication Module to the OAuth module. The custom build also enables passing an Authorization header into the httpClient POST API in the server-side script. On every login attempt from a Social Login platform, the Scripted Authentication Module invokes the ZF api with an Authorization header to assess the risk associated with the login.

The following risk attributes can be flagged on a social account and each one of these can be detected from within the Scripted Authentication Module in OpenAM via the ZeroFOX Social Login Risk Score API.

Configuration

From Common Tasks, under the “Configure Social Authentication” menu, select and configure ‘Configure Google Authentication’.

Create a Scripted Authentication Module instance in OpenAM. Add code in the server side script to invoke the ZF API:

httpClient.post("https://api.zerofox.com/1.0/sra/", "{"network":"google+", "user_id":"+userId +"}", {cookies:[], headers:[{"field": "Content-type","value":"application/json"},{"field": "Authorization","value": "forgerock:*******"}]});

Chain the Scripted Authentication Module instance to the GoogleSocialAuthentication instance created in the previous step:

In Google Plus, open a test account and post a phishing link. At this point you should kick off the scan by invoking the ZF API from Postman or using curl. If you do not do it now, the scan is started when you attempt to login into OpenAM using this malicious account, except of course, the Social Login Score is not ready just yet and authentication passes.

Demo

From the OpenAM login page, click on the Google Plus icon to login:

Login as the malicious user and you should immediately see an Authentication denied error. The Scripted Authentication Module checks for high threat indicators and denies login if one or more are found.

Using Postman, invoking the ZF Social Login Score API confirms that phishing links were found on the account and threat level is too high to allow login into OpenAM.

{
  • "phishing": "2015-04-24 17:13:24 UTC",
  • "drugs_and_alcohol": "2015-04-24 17:09:24 UTC",
  • "malware": "2015-04-24 17:13:24 UTC"
}

ForgeRock OpenAM Multi Factor Authentication Using Adaptive Risk Authentication Module & OTP

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

In this episode, you’ll see ForgeRock OpenAM’s two factor authentication feature employing it’s Adaptive Risk Authentication Module instance and HOTP module instance

So in the video demonstration that follows this post, you’ll see a user attempting to login against an Authentication Chain (say ‘MyAuthChain’) which has three module instances namely (i) Data Store, (ii) Adaptive Risk and (iii) HOTP. If the user is able to supply the right credentials against the Data Store, he or she is allowed in without any further challenge. On the other hand, if the the attempt to authenticate against the first Module instance (Data Store) fails, then the user is prompted for additional credentials like One Time Password.

The following illustration might give a rough idea on the what’s discussed above and the video that follows might make it pretty clear.

MultiFactorAuthentcation

Enjoy!