Saturday, October 24, 2015

OpenAM : How to exchange for a long-lived access token from Facebook?

I have a customer who has a big data marketing engine running and they request for more information from Facebook to gather insights into their customers.

By default, when a user authenticates with Facebook via OpenAM Login Page, only a short-lived access token is captured.

There are 2 issues:

  1. The marketing engine will only run nightly/weekly. The short-lived access token would have expired then.
  2. The access token, even if it has not expired, is not persisted. Thus the marketing engine has no means to pick it up.

I did some research and this is what is required to exchange a short-lived access token with a long-lived access token.

You must exchange this short lived token with a long lived token by invoking a GET request to the following URL:[APP_ID]&client_secret=[APP_SECRET]&fb_exchange_token=[SHORT_LIVED_TOKEN] 

APP_ID is your application id. 
APP_SECRET is your application secret. 
SHORT_LIVED_TOKEN is the short lived user access token received in the previous step. 

What comes back: 
The JSON response will contain the long lived access token.

To achieve customer's requirement, we can write some custom codes in Post-Authentication Processing module.

    public void onLoginSuccess( Map requestParamsMap, HttpServletRequest request,
        HttpServletResponse response, SSOToken ssoToken )
            throws AuthenticationException {

         if (authentication module is Facebook) {

              // THIS IS KEY! Without it, there is no way to exchange for a long-lived
              // access token
              // this is short-lived access token returned from Facebook at OAuth 
              // authentication module
              String accessToken = ssoToken.getProperty

              // clientId, clientSecret, tokenServiceUrl 
              // quick and dirty is to hardcode; 
              // otherwise, read, and
              String clientId = ...;
              String clientSecret = ...;
              String tokenServiceUrl = ...;

              // follow the URL format above (highlighted in blue)
              String url = getFormattedTokenServiceUrlForFBLongLivedToken
                        (accessToken, clientId, clientSecret, tokenServiceUrl);

              // make a GET call to Facebook to exchange for a long-lived access token
              // methods getContent() and getContentStreamByGET() available 
              // in (no need to reinvent wheel; modify a bit will do)
               String longLivedToken  =  getContent(url);

              // Need to strip: 
              //    e.g. access_token=[LONG-LIVED-ACCESS-TOKEN]&expires=5148647
              longLivedToken = longLivedToken.substring(13,longLivedToken.indexOf("&"));

              // Persist FB long-lived access token to user's LDAP entry
              updateFBLongLivedAccessToken (longLivedToken, ssoToken);




Tuesday, October 20, 2015

OpenAM 12 - Social Authentication

In OpenAM 12,  one of the new features released was Social Authentication made-easy.

Social Authentication  
Log in to an OpenAM protected resource by using your existing social website credentials. OpenAM supports Facebook, Google, Microsoft, or any other OpenID Connect 1.0 compliant identity provider.

OpenAM administrator can easily configure Social Authentication via the Common Tasks tab.

And the respectively Social Login logos will auto-magically appear on the default OpenAM Login Page, without any customization. Wow!

Yes, it did wow-ed one of my customers when some pre-sales presented this feature during selling/POC.

Side note: You'll be quite amazed the decision makers here are easily wow-ed by UI experience, rather than comparing products technically. (Few years ago, I did mentioned about the hard selling of OpenIDM without a proper UI. These days, it's much easier to sell with the launch of UI in OpenIDM 3.x.)

Back to our original topic, what's the catch? 

Read again:

Social Authentication  
Log in to an OpenAM protected resource by using your existing social website credentials. OpenAM supports Facebook, Google, Microsoft, or any other OpenID Connect 1.0 compliant identity provider.

So during project implementation,  this particular customer wants to have LinkedIn "auto-magically" appear on the Login Page as this was what he requested then.

Technically, to configure via the "short-cut" in Common Tasks tab is impossible. That's what I have to admit to Mr Customer. This is because LinkedIn does not currently supports OpenID Connect.

There is, however, workaround which I have researched for him and made it work for him.

OpenAM is very flexible to tweak around. But of course, some investment in time are required.


Thursday, October 15, 2015

OpenAM XUI Policy Editor ... on Safari

I was developing a custom policy condition for a customer. In the process, I was constantly clearing/disabling browser cache and was playing with XUI Policy Editor a lot. 

I'm seldom on Safari even though I'm using a Mac. But because of my laziness to keep clearing cache, I used Safari in one of my testings. That's when I found something weird in Safari. 

The last line "policy.subjectType.Policy.title" in Subject Conditions is always showing in Safari.

The last line "policy.conditionTypes.Policy.title" in Environment Conditions is always showing in Safari.

Note: I only added a MySQL Query Filter Condition which works perfectly fine.

So I went ahead to install a default OpenAM without any customisation.  The same behaviour exists in Safari.

Kind of strange... maybe I'll spend some time searching OpenAM bugster to see if this issue has been raised before.


Tuesday, October 13, 2015

OpenAM XUI Policy Editor ... Inconsistent UI

Having played with XUI for the OpenAM Policy Editor for a while (coming to 2 months), I must say I do not yet have a positive experience with it.

For example, there is this piece of inconsistency in the OpenAM Policy Editor implementation.

To add a resource, it's fairly simple.

Step 1: Roll over the mouse on "Available patterns". A green arrow appears. Click on the arrow.

Step 2: On the right-hand side, a "+" appears. Click on it and it will add the pattern to the resource. Simple!

If you want to remove the pattern, a "X" is available to carry out the function. Intuitive. 

Now, the UI experience for Define Subject Conditions and Define Environment Conditions is not consistent with the previous experience.

For example, to add a subject type, one has to drag the grey bar to the green area. (I missed this totally when I first used this XUI policy editor)

Where is the "+" to add?

Now, to remove a subject condition, one has to click on the "rubbish bin" icon, instead of "X" which was used in Resources.

Both "rubbish bin" and "X" serve the same function perfectly. However, in a product (especially within the same Policy Editor), one would expect the UI experience to be consistent throughout.

Kind of weird to me.

If I were to implement such a UI, I would have failed my Human-Computer Interaction course badly many years back in the University. I had a strict lecturer then. :)