Authentication and Authorization
Objective: The objective of this page is to provide developers with all information necessary to develop applications and services that require Authentication and Authorization.
This documents provides developers with all necessary information to be able to develop services and applications that require authorization and authentication from a user. If you develop an application that uses external service than requires user's credentials, then your application behaves as an oAuth consumer and support for this should be implemented. If you develop an external service that can be used within applications, then you have to implement oAuth provider service.
oAuth allows user to log into external service only once, user does not have to log in again next time she visits the service.
OpenId allows to have single credentials over several external services.
OAuth + OpenId allows to achieve SSO (single sign on), when user does not have to log into externals services in her applications.
This section provides information on relevant terms as well as their definitions and abbreviations used throughout this page.
oAuth
A protocol that allows user to log into external service only once, user does not have to log in again next time she visits the service.
oAuth provider
When an external service implements oAuth protocol and this service can be used by other services/applications it is an oAuth provider.
oAuth consumer
Services and application that use external service supporting oAuth protocol are oAuth consumers.
OpenId
OpenId allows to have single credentials over several external services
SSO (single sign on)
Single sign on allows user to get automatically logged in into several external services
This section provides information on relevant facts about this library.
http://tools.ietf.org/html/rfc5849
http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi
http://openid.net/developers/specs/
This section lists the policies to be met for proper operation of this library.
This section describes the Authentication/Authorization solutions existing in ROLE. In Section #Instructions, you find HowTos demonstrating how to user authentication and authorization services.
This section describes the ROLE architecture.
The following picture depicts the process of registering a widget in different containers. A widget needs to be registered for each container it will be used. OAuth credentials are wired to a specific domain, thus to use a widget in 3 containers it has to request 3 different oauth credentials, once per domain/container.
This section includes a set of instructional HowTos to get developers started with Authentication and Authorization for their services and widgets.
Objective: This section provides instructions on how to enable any widget to act as a basic XMPP client entity with the help of the ROLE dojo extension.
Who: This HowTo addresses developers who intend to use this library to implement XMPP-enabled gadgets.
Steps:
The following steps demonstrate how to create an oAuth widget. The widget displays your address book from GMail. In this scenario GMail behaves as oAuth provider and widget (running on Apache Shindig) behaves as oAuth consumer.
- Get oAuth keys from oAuth provider
How to get oAuth keys for gmail as an example: https://www.google.com/accounts/ManageDomains
- Apply changes to Apache Shindig code.
2.1) You should get shindig source code:
svn checkout http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.0.0/ .
2.2) The following code should be added into shindig's file: shindig/config/oAuth.json
"http://graaasp.epfl.ch/gadget/oauth_example.xml" : {
"google" : {
"consumer_secret" : "consumer_secret_here",
"consumer_key" : "consumer_key_here",
"key_type" : "HMAC_SHA1"
}
},
2.3) Then you should recompile shindig and start the jetty server.
$ mvn -Dmaven.test.skip
$ cd java/server
$ mvn jetty:run
- Gadget changes
<ModulePrefs title="OAuth gadget">
<Require feature="opensocial-0.8" />
<OAuth>
<Service name="google">
<Access url="https://www.google.com/accounts/OAuthGetAccessToken" method="GET" />
<Request url="https://www.google.com/accounts/OAuthGetRequestToken
?scope=http://www.google.com/m8/feeds/" method="GET" />
<Authorization url="https://www.google.com/accounts/OAuthAuthorizeToken
?oauth_callback=http://oauth.gmodules.com/gadgets/oauthcallback" />
</Service>
</OAuth>
</ModulePrefs>
Full gadget code is available here: http://graaasp.epfl.ch/gadget/oauth_example.xml
- View the oAuth gadget
Objective: This section provides instructions on how to implement your own oAuth Service provider.
Who: This howTo addresses developers who intend their services to be accessible with oAuth. They have to implement oAuth Provider mechanism at their servers.
'''Existing oAuth provider libraries: ''' OAuth server/client for ruby http://oauth.rubyforge.org/
Steps: In general this HowTo summarites the steps as described in the official oAuth specification http://tools.ietf.org/html/rfc5849 Some Sample code is developed for the CAM Web Service, see here Mainly three URL's are required to enable oAuth in your own service: :1) request token url
The client obtains a set of temporary credentials from the service provider (server). The temporary credentials are used to identify the access request throughout the authorization process.
- request_token url:
:* It is recommended to implement the url as HTTP POST method:
:* Example Client Request:
POST /request_token HTTP/1.1
Host: server.example.com
Authorization: OAuth realm="Example",
oauth_consumer_key="jd83jd92dhsh93js",
oauth_signature_method="PLAINTEXT",
oauth_callback="http%3A%2F%2Fclient.example.net%2Fcb%3Fx%3D1",
oauth_signature="ja893SD9%26"
:* validate the request
:** recalculate and validate signature based on signature method (see 5))
:** validate nonce and timestamp (coming soon)
:* generate and return oauth_token and oauth_token_secret
:** The response contains the following REQUIRED parameters:
:*** oauth_token (The temporary credentials identifier)
:*** oauth_token_secret (The temporary credentials shared-secret)
:*** oauth_callback_confirmed (MUST be present and set to "true". The parameter is used to differentiate from previous versions of the protocol.)
:** Example Response:
HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencoded
oauth_token=hdk48Djdsa&oauth_token_secret=xyz4992k83j47x0b&oauth_callback_confirmed=true
- authorize url:
:* Represents a Web Page where the user has to verify his identity (e.g. via user log-in) and afterwards grants or denies the client-application the access to the user's protected resources.
:* The client directs the resource owner to the constructed URI. The request MUST use the HTTP GET method.
:* Example Request:
GET /authorize?oauth_token=hdk48Djdsa HTTP/1.1
Host: server.example.com
:* When asking the resource owner to authorize the requested access, the server SHOULD present to the resource owner information about the client requesting access based on the association of the temporary credentials with the client identity.
:* After receiving an authorization decision from the resource owner, the server redirects the resource owner to the callback URI if one was provided in the "oauth_callback" parameter or by other means.
:* If the client did not provide a callback URI, the server SHOULD display the value of the verification code, and instruct the resource owner to manually inform the client that authorization is completed.
- access_token:
:* generating the access token should reuse the request_token method
:* HTTP POST method
:* When making the request, the client authenticates using the client credentials as well as the temporary credentials.
:* The temporary credentials are used as a substitute for token credentials in the authenticated request and transmitted using the "oauth_token" parameter.
:* Example Request:
POST /request_token HTTP/1.1
Host: server.example.com
Authorization: OAuth realm="Example",
oauth_consumer_key="jd83jd92dhsh93js",
oauth_token="hdk48Djdsa",
oauth_signature_method="PLAINTEXT",
oauth_verifier="473f82d3",
oauth_signature="ja893SD9%26xyz4992k83j47x0b"
- Request protected resources url:
:* The client requests the user's protected resources by calling the respective web-method
:* The client authenticates using the access_token credentials and consumer credentials.
:* Example Request
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
:* The oAuth Provider must validate the request
:** recalculate and validate signature based on signature method (see 5))
:** validate nonce and timestamp (coming soon)
- Recalculate Signature:
The signature base string is constructed by concatenating together, in order, the following HTTP request elements:
-
The HTTP request method in uppercase. For example: "HEAD", "GET", "POST", etc.
-
An "&" character (ASCII code 38).
-
The base string URI after being encoded.
-
An "&" character (ASCII code 38).
-
The request parameters as normalized, after being encoded. specification Section 3.4.1.3.2
For example, the HTTP request:
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
is represented by the following signature base string (line breaks are for display purposes only):
POST&http%3A%2F%2Fexample.com%2Frequest&a2%3Dr%2520b%26a3%3D2%2520q
%26a3%3Da%26b5%3D%253D%25253D%26c%2540%3D%26c2%3D%26oauth_consumer_
key%3D9djdj82h48djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_m
ethod%3DHMAC-SHA1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk
9d7dh3k39sjv7
Objective: Widgets container should provide support for oAuth to widgets. Apache Shindig provides this support, however, some additional implementation are required on Shindig's side to allow widget developers to add oAuth keys for their widgets.
Who: This howTo addresses developers who intend to develop widget containers supporting oAuth.
Steps: Steps to provide support for oAuth in Shindig are discussed here: https://cwiki.apache.org/confluence/display/SHINDIG/Enabling+OAuth+support
Example widgets that make use of OAuth are provided in the ROLE SDK under src/gadget/samples/openapp.