Single Sign On
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.
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.
- 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:
(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
- (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.
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:
- Objective-C for Mac developers
- OAuth Plugin for the Jifty Framework
For more details see OAuth Code
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.
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
- 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
- the campus manages the authentication of users
- service providers decide whether the user can acces the resource according to the user attributes
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:
- 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
- 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)
- Authentication (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.
- (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.
Installation-Packages for IdP, SP and DP can be found at Shibboleht Installation
Supported Operation Systems
- Mac OS
Out of date? Shib Specification
- Supported Operationg Systems, Installation, Attributes: Borel Introduction to Shib
- Test environment DFN-AAI
- DFN-AAI Federation
- MPG-AAI Federation
|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|