Consuming OAuth Services in Alfresco Share Alfresco Summit 2013 Will Abson / @wabson

My Role at Alfresco At Alfresco since 2005 Started Share Extras project 2010 Joined Integrations Team 2012

Integrations Matter Increasing complexity of IT landscape Rapid adoption of Cloud services Source: http://www.flickr.com/photos/ross/3055802287/

Back in the Day Integrations were PAINFUL Long, iterative dev cycles Transport protocols were XML-based (WSDL, SOAP, etc.) or language-specific (e.g. RMI) How to authenticate?

The Situation Today REST + JSON = Happy Developers? Scriptable APIs Powerful client capabilities

What About Identity? Sharing usernames and passwords is BAD Details may be compromised Passwords may be changed Passwords not always secure Using tokens allows users to delegate authorization to external applications Tokens may be revoked by the user and may expire... But will not change Long alphanumeric values normally used

Enter OAuth An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications. - oauth.net

OAuth Two variants OAuth 1.0(a) OAuth 2.0 Really completely different standards OAuth 2.0 has been controversial

OAuth 1.0a Flow

OAuth 2.0 Flow

Comparing The Two OAuth 1.0 Grant Token must be obtained up-front User tokens consist of access token and secret token (for signing) Every request must be signed as prescribed by SP Access Tokens normally long-lived but cannot be renewed OAuth 2.0 No Grant Tokens Users provided with access token only, no secret token No Signing of requests, relies on SSL Access Tokens are short- lived but Refresh Tokens can be used to renew them

Your Code API The Dream Dashlets Admin Console Doclib Actions etc. Twitter Salesforce Flickr etc.

Introducing Share OAuth Goal: To make RESTful, OAuth-protected APIs natively and easily accessible through client-side JavaScript in Alfresco Share Just like we can easily access the Alfresco repository For OAuth 1.0 and 2.0 services

Challenges How should developers declare endpoints, client IDs and secrets? Dealing with the “OAuth Dance” Where to persist access tokens? How do we sign requests? How do we keep this secure?

Surf Concepts Endpoints give the location of remote resources Connectors are used to fetch those resources Each endpoint must identify a single connector to use Connectors may use a named Authenticator, which in turn may use a Credentials Store

Surf Concepts Illustrated AuthenticatingConnector Credentials Store Endpoint Connector

File spring-webscripts-config.xml

Introducing Share OAuth Goal: To make RESTful, OAuth-protected APIs natively and easily accessible through client-side JavaScript in Alfresco Share Just like we can easily access the Alfresco repository For OAuth 1.0 and 2.0 services

Initial Impl - OAuth 1.0 Connector MyDashlet Extras.OAuthHelper Return Web Script Custom Model Token Web Scripts Service Provider HttpOAuthConnector

Initial Impl - OAuth 1.0 Connector MyDashlet Extras.OAuthHelper Return Web Script Custom Model Token Web Scripts Service Provider HttpOAuthConnector

Repository Tier Custom Model Defines a single aspect with a d:content property Aspect is added to the cm:person object, containing serialized JSON data Data contains OAuth token, secret and other optional values Token Web Scripts Get and set OAuth data on the person object

Web Tier Return Web Script Provider redirects the user back here with a verification code Responsible for calling out to provider to exchange verification code for token Stores access token and secret using token web scripts Redirects user to their original page

Web Tier HttpOAuthConnector Receives requests bound for the service provider, which have been sent via the Share endpoint proxy Access token and secret must be added by the browser via a custom header Secret is used to sign the request but is NOT sent to provider Response is streamed back to the client

Dashlet Request Flow Fetch token from Token Web Scripts If API request successful, display the data If unauthorized, display Connect action If token found, make API request via custom Connector If no token found, display Connect action Fetch token from Token Web Scripts

New Impl - OAuth 2.0 Connector MyDashlet Return Web Script Credentials Store Web Scripts Service Provider Credentials Store HttpOAuth2Connector

Repository Tier OAuth Credentials Store Web Scripts Use the dedicated credentials service (new in Alfresco 4.1) to store tokens on behalf of the user No custom model needed, values are stored encrypted

Web Tier Credentials Store Responsible for loading tokens from the repository (using Credentials Store Web Scripts), storing in the user’s session context and saving new values Return Web Script Uses the Credentials Store to save the access token data (no need to manually call repo web scripts)

Dashlet Request Flow Make API request via custom Connector If API request successful, display the data If unauthorized, display Connect action Make API request via custom Connector

Example Implementations GitHub Dashlet Chatter Dashlet JavaScript Console

More Implementations Twitter Dashlets Flickr Dashlets LinkedIn Dashlet Yammer Dashlet

Future OAuth 1.0 Support via Credentials Store Requires Grant Token support via a custom web script Deprecate client-side Extras.OAuthHelper class Simplify Twitter, LinkedIn, Flickr and Yammer dashlets

More Information http://sharextras.github.io/