Single Sign On

OAuth

Introduction

OAuth is an open authorization delegation protocol. It allows users (User) to share private resources (photos, videos, contact list, bank accounts) stored on one site (Service Provider) with another (Consumer) without having to hand out username and password. OAuth delegates access scenario, also known as 3-legged scenario, where three parties (legs) are involved: Service Provider, Consumer, and User. But OAuth can be used also for direct access scenario, known as 2-legged scenario – one side authenticates with the other, for example, a person logging to a site using username and password.

Example/Scenario

User wants to print photos using online print shop (in OAuth Consumer). The User logs in the online print shop and says: „Import photos for printing from Flickr“. The user will be redirected to Flickr (in OAuth Service Provider) and has to log in and grant access to the online print shop to his photos. Mostly the access is time-constrained (e.g. 1 hour). Then the user is redirected to the print shop and can choose from all his imported pictures from Flickr those for printing without sharing his credentials with the printing application.

Roles/Definitions

• Service Provider – Website or web-service where the restricted resources are located (e.g. Flickr)
• User – has account with Service Provider
• Consumer – web or desktop application uses OAuth to access the Service Provider on behalf of the user (e.g. online printing application)
• Consumer Developer - An individual or organization that implements a Consumer.

• Consumer Key - A value used by the Consumer to identify itself to the Service Provider.
• Consumer Secret - A secret used by the Consumer to establish ownership of the Consumer Key.

• Request Token - A value used by the Consumer to obtain authorization from the User, and exchanged for an Access Token.
• Access Token - A value used by the Consumer to gain access to the Protected Resources on behalf of the User, instead of using the User's Service Provider credentials.
• Token Secret - A secret used by the Consumer to establish ownership of a given Token.

• OAuth Protocol Parameters - Parameters with names beginning with oauth_.

OAuth includes a Consumer Key and matching Consumer Secret that together authenticate the Consumer (as opposed to the User) to the Service Provider. Consumer-specific identification allows the Service Provider to vary access levels to Consumers (such as un-throttled access to resources).

Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA).

see OAuth Core 1.0

How it works?

OAuth authentication is the process in which Users grant access to their Protected Resources (e.g. Photos) without sharing their credentials with the Consumer (e.g. Printing app). OAuth uses Tokens generated by the Service Provider instead of the User's credentials in Protected Resources requests.

OAuth Authentication is done in three steps, for more details see OAuth Core 1.0 - Authenticating with OAuth:

The Consumer obtains an unauthorized Request Token

(3) Consumer Obtains a Request Token

The Consumer obtains an unauthorized Request Token by asking the Service Provider to issue a Token. Request Token URL is used to obtain an unauthorized Request Token. The request MUST be signed and contains the parameters shown in the graphic.

For signature, timestamp and nonce see Hueniverse Security Architecture.

The oauth_callback is an absolute URL to which the Service Provider will redirect the User back when the Obtaining User Authorization step is completed.

(4) Service Provider Issues an Unauthorized Request Token

The Service Provider verifies the signature and Consumer Key. If successful, it generates a Request Token and Token Secret and returns them to the Consumer in the HTTP response body as defined in Service Provider Response Parameters.

For more information see OAuth Core 1.0 - Obtaining an Unauthorized Request Token

The User authorizes the Request Token

• (5) Consumer directs the User to the Service Provider

In order for the Consumer to be able to exchange the Request Token for an Access Token, the Consumer MUST obtain approval from the User by directing the User to the Service Provider. User Authorization URL is used to obtain User authorization for Consumer access.

• (6) and (7) Service Provider authenticates the User and obtains Consent

The Service Provider verifies the User's identity and asks for consent as detailed. OAuth does not specify how the Service Provider authenticates the User, but defines a set of REQUIRED steps:

• • The Service Provider MUST first verify the User's identity before asking for consent. It MAY prompt the User to sign in if the User has not already done so.
  • The Service Provider presents to the User information about the Consumer requesting access (as registered by the Consumer Developer). The information includes the duration of the access and the Protected Resources provided.
  • The User MUST grant or deny permission for the Service Provider to give the Consumer access to the Protected Resources on behalf of the User. If the User denies the Consumer access, the Service Provider MUST NOT allow access to the Protected Resources.

• (8) Service Provider directs the User Back to the Consumer

After the User authenticates with the Service Provider and grants permission for Consumer access, the Consumer MUST be notified that the Request Token has been authorized and ready to be exchanged for an Access Token.

For more details see OAuth Core 1.0 - Obtaining User Authorization

The Consumer exchanges the Request Token for an Access Token

The Consumer exchanges the Request Token for an Access Token capable of accessing the Protected Resources.

• (9) Consumer Requests an Access Token

The Request Token and Token Secret MUST be exchanged for an Access Token and Token Secret. To request an Access Token, the Consumer makes an HTTP request to the Service Provider's Access Token URL.

• (10) Service Provider Grants an Access Token

If successful, the Service Provider generates an Access Token and Token Secret and returns them in the HTTP response body as defined in Service Provider Response Parameters. The Access Token and Token Secret are stored by the Consumer and used when signing Protected Resources requests.

Fore more details see OAuth Core 1.0 Obtaining an Access Token

Accessing Protected Resources

The Access Token is used by the Consumer to access the Protected Resources on behalf of the User.

• Access Tokens MAY limit access to certain Protected Resources, and MAY have a limited lifetime.
• Service Providers SHOULD allow Users to revoke Access Tokens.
• Only the Access Token SHALL be used to access the Protect Resources.

After successfully receiving the Access Token and Token Secret, the Consumer is able to access the Protected Resources on behalf of the User. The request MUST be signed per Signing Requests, and contains the parameters shown in the graphic.

Software Package

OAuth-Code: These libraries are contributed by members of the community and have not been tested or are necessarily known to work.

Implementation of OAuth are available for following languages:

• .NET
• ColdFusion
• CommonLisp
• Java
• JavaScript
• Ruby
• PHP
• Perl
• Python
• OCaml
• Objective-C for Mac developers
• OAuth Plugin for the Jifty Framework

For more details see OAuth Code

Specification

OAuth Core 1.0 Revision A

Links

OAuth code libraries and supporting examples

Beginner’s Guide to OAuth – Part I: Overview

Beginner’s Guide to OAuth – Part II : Protocol Workflow

Beginner’s Guide to OAuth – Part III : Security Architecture

Twitter4J OAuth code example

Shibboleth

Introduction

Shibboleth is standard based, open source software package for web single sign-on across or within organizational boundaries. Shibboleth implements widely used federated identity standards, principally OASIS' Security Assertion Markup Language (SAML), to provide a federated single sign-on and attribute exchange framework.

Example/Scenario

In the past, universities, companies or government agencies, that offer services and collaborate online, required its own ID and password for each service. Also users typically access both online resources inside or outside their organizations. For the user this workflow meant set of credentials for the applications and for the institution a challenge to close security holes for services and manage access changes.

Shibboleth Single Sign-on and Federating Software was developed specifically to address the challenges of:

• multiple passwords required for multiple applications
• scaling the account management of multiple applications
• security issues associated with accessing third-party services
• privacy
• interoperability within and across organizational boundaries
• enabling institutions to choose their authentication technology (Shibboleth sits on top and provides the web single sign-on functionality)

For more details see Shibboleth About

With Shibboleth:

• the campus manages the authentication of users
• service providers decide whether the user can acces the resource according to the user attributes

Shibboleth Federation

A Federation is a group of organisations usually with common purpose (e.g. research and education), who trust one another. Federations operate to a set of agreed rules, some of which will be common to all federations, others may be useful or necessary to be developed locally. Federations can have their own legal status as an organisation in their own right.

A Shibboleth Federation is an agreement between resource (service) providers and institutions (identity providers) wishing to access those resources or services. For sharing to occur, all parties need to agree on a common set of acceptable authorisation attributes for their users, and a schema to describe them.

For using Shibboleth federations are not required. At least one Identity Provider is required for federation. Federation for one - federation with one IdP (e.g. Facebook Connect).

For more information about federations see:

• An introduction to Shibboleth Federations

• DFN-AAI - Authentifikation Autorisierungs Infrastruktur DFN-AAI

• DFN-AAI Presentation Vortrag DFN

• New Identity-Provider in DFN-AAI - Max-Planck-Gesellschaft DFN-AAI Max Planck

Roles/Definitions

• Identity Provider (IdP) - the software run by an organization with users wishing to access a restricted service; Objectives:
  • Authentication (optional)
    • User Management (optional)
  • Authorisation (mandatory, part of Shibboleth)
    • User Management (optional)
• Service Provider (SP) - the software run by the provider managing the restricted service.
  • Access Control (expected successful authentication and user attributes)
• Discovery Service (optional) - List with organization's Identity Provoiders; can be separate service or run by the Service Provider

• Attributes - the base for authorisation and access control.
  • IdP provides the attributes for the user

How it works?

User wants to access a Resource. The workflow can be separated in 3 phase:

User connect to Resource and is redirected

If the user has a valid Shibboleth session, the access to the resource is granted directly. Otherwise the user is redirected to the Discovery Service.

• (1) When the "resource link" is clikced a HTTP request is send to the site of the Service Provider
• (2) User is redirected to the WhereAreYouFrom-Service (wayf) and can choose his home organization

This step is not required. In SAML the organization name could be send tranparent for the user.

Authentication request

• (3) After choosing the home organization the Discovery Service redirects the user to the session initiator of the resource
• (4) The session initiator creates an authentication request for the choosen Home Organization and submits it through the users browser to the Home Organization (IdP). (Start here if you know already the address of the IdP of Home Organization.)
• (5) The Home Organization shows a login page

Authentication and Access

Besides of login and password other forms of credentials could be used - e.g. hardwaretoken (Smartcard)/password, Softwaretoken (public key)/password, biometric authentication method.

• (6) The user provides his credentials to the IdP. The credentials are checked and an assertion including the users attributes is created according to the attribute filter rules.
• (7) The assertion is submitted through the users browser back to the resource. According to the user attributes the authorization is successul or not.

Software Package

Installation-Packages for IdP, SP and DP can be found at Shibboleht Installation

Supported Operation Systems

• Linux
• Mac OS
• X–Solaris
• Windows

Specification

Out of date? Shib Specification

Links

• Supported Operationg Systems, Installation, Attributes: Borel Introduction to Shib
• Test environment DFN-AAI
• DFN-AAI Federation
• MPG-AAI
• MPG-AAI Federation

Comparison OAuth/Shibboleth

Characteristic	OAuth	Shibboleth
user authentication	yes - for SP mandatory, app-specific	yes - part of IdP, not requiered
user authorisation	no - user authorises the SP-app, that can give user data to Consumer	yes - SAML-Assertions
federation support	no - only pairwise arrangements between apps	yes
multiple psw for multimple apps	yes - user credentials are hold by each app	no
IdP, SP Roles	IdP and SP are the same entity	IdP authenticate the user and give attributes, SP understand and handle according to attributes
Consumer, SP Roles	Consumer wants to access user ressources ot the SP, SP holds user ressources and obtains user's consent for giving the res to Consumer	Consumer, SP are IdP, SP at once
API	requiered, see Spec	no API requiered, just read HTTP-Header or CGI vars
Protocols	yes, defined see Spec	yes, SAML definies set of protocols
Tokens	no, token format not defined	yes, token format defined

Uniform Resource Locator

HyperText Transfer Protocol

Hypertext Preprocessor

Logging-in system for computer networks

Security Assertion Markup Language

Identifier

Identity Provider

Deutsches Forschungsnetz

Authentication, Authorization and Identification

Service Provider

Operating System

Application Programming Interface

Computer Generated Imagery