Version 1

    Specification

    UI Flows to cover

    1) New account - Sign up with...

     

    1. Portal login page with “Sign in with Facebook/Google” buttons
    2. Redirect to Facebook / Google
      1. Login page if there is no active session
      2. Authorization request of “GateIn Portal” application.
    3. Redirect back to GateIn Portal for user registration
      1. New account registration form - normal flow. Depending on data exposed from external service part of registration form is pre populated (birth date, location, profile info and etc.) User chooses username himself.

    2) Login with existing account (GateIn account already linked with social network)

     

    1. Portal login page with “Sign in with Facebook/Google buttons
    2. Redirect to Facebook / Google to enter credentials if there is no active session detected.
    3. Redirect back to GateIn Portal

     

    3) Existing account with revoked token (User revoked access to GateIn from Facebook/Google UI or the token expired)

     

    1. Portal login page with “Sign in with Facebook/Google buttons
    2. Redirect to Facebook / Google
      1. Login page if no active session
      2. Authorization request of “GateIn Portal” application
    3. Redirect back to GateIn Portal

     

    4) Connecting another social provider to existing account

    When there is user account registered using “Sign in with Google” and user wants to add Facebook and vice versa.

     

    1. User profile popup. Additional tab with “Social Networks” or “OAuth” label
      1. Facebook, Google options with Enabled/Disabled or On/Off switches
      2. Click on “Enable/On” redirects to Facebook/Google for authorization. Could be a popup if possible
      3. Click on “Disable/Off” displays a warning explaining consequences of unlinking social network account. May ask to confirm operation with user password defined for gatein account. Therefore user will be aware about credentials to use after removing social network account.
      4. Possibility to add more fine grained configuration to define which user activities should be published for a given social network account

     

    Configuration

    In the file configuration.properties:

    gatein.oauth.facebook.enabled=false

    gatein.oauth.facebook.appid=<<to be replaced>>

    gatein.oauth.facebook.appsecret=<<to be replaced>>

    gatein.oauth.facebook.redirecturl=http://localhost:8080/portal

    gatein.oauth.facebook.scope=email,read_friendlists,create_event

    gatein.oauth.facebook.display=

     

    gatein.oauth.google.enabled=false

    gatein.oauth.google.clientid=<<to be replaced>>

    gatein.oauth.google.clientsecret=<<to be replaced>>

    Implementation

    General requirements

     

    • User always endup with a “normal” gatein account. Either created before connecting to a social network, or by logging in a social network and finish registration within GateIn.
    • OAuth can be used to register new gatein account and pre fill registration form with data fetched from external provider (Facebook, Google). Drastically speeds up the process.
    • Each gatein account can have several linked social network accounts (UI Flow 4). This is one to many matching between gatein username and FB/Google ids. All references are stored as unique user attributes in PicketLink IDM.
    • OAuth can be used to “transparently” log into existing gatein account - if it is linked with external social network and user has active session there. SSO between Facebook/Google and gatein.
    • User tokens stored as user property. Each gatein user account can have several linked social network accounts. Tokens kept in encrypted way
    • For linked social networks gatein portal will be authorized to access user data (also post to FB wall or twitt). Portlet can use service for such activities on behalf of user currently logged into gatein portal.
    • On registration page, if someone logs with a Fabook or Google account that has already been registered, the user gets logged in.

    User Properties

    We need to store the following as user properties (Organization service)

    • Facebook username - org.gatein.oauth.facebook.username
    • Google username - org.gatein.oauth.google.username
    • Encrypted Facebook accesstoken - org.gatein.oauth.facebook.accesstoken.
    • Encrypted Google accesstoken - org.gatein.oauth.google.accesstoken

    “Social Networks” Service

    Logic to access unencrypted user token (from user profile)

    Registered to eXo Kernel and accessible from a portlet the same way one access to the organization service for instance.

    <<Method names>> (Get Facebook and Google access token of the current user)

    This service is to be used by portlets willing to access Facebook and Google APIs to retrieve friends list or post on behalf of the user for instance.

    Access token encryption

    Encryption key in filesystem, autogenerated on first start if not available. See if we can reuse encryption mechanism in other places (such as remember me tokens).

     

    3rd party libraries - [to be determined].

     

    • PicketLink Social for OAuth2
    • Agorava - beyond authentication and simple usecases
    • FB/Google specific libraries if needed

    Operations

     

    • Link social network account with user
    • Unlink social network account with user
    • Obtain unencrypted oauth token for current user
    • Obtain unencrypted oauth token of a given user
    • Store encrypted oauth token for a given user

    UI changes

    Requires to add a Facebook Connect and/or a Google button on the login page if those services are enabled in the configuration.

    The login page is currently being changed for mobile ‘support’.

    • Login Page
    • User registration page
    • User properties popup - for user (Social tag)
    • User properties page - for administrator

     

    Quickstart(s)

    Once the support done, we should have a basic portlet that retrieves accesstoken of the logged-in user and display his friends list (Google or Facebook depending where he’s logged) and a text field to push status update on Facebook.

    Steps

    Various steps in the implementation may happen in several different releases of GateIn. Each step is supposed to add value and fulfil completely some usecases.

    Step 1

    UI Flow 1

    Step 2

    UI Flow 2 and 3

    Step 3

    UI Flow 4

    More

     

    • Do the same with Twitter (OAuth 1.0a)
    • Do the same with LinkedIn (OAuth 1.0a)
    • Limit tokens to be stored in session rather than as a user property
    • Administration UI to manage user tokens (remove someone’s link to Facebook or Google)