Class OpenID::Consumer
In: lib/openid/consumer.rb
Parent: Object

Overview

Brief terminology:

Consumer
The website wanting to verify an OpenID identity URL. Sometimes called a "relying party". If you want people to log into your site using OpenID, then you are the consumer.
Server
The website which makes assertions as to whether or not the user at the end of the browser owns the URL they say they do.
Redirect
An HTTP 302 (Temporarily Moved) redirect. When issued as an HTTP response from the server, the browser changes it‘s location to the value specified.

The OpenID authentication process requires the following steps, as visible to the user of this library:

  1. The user enters their OpenID into a field on the consumer‘s site, and hits a login button.
  2. The consumer site discovers the user‘s OpenID server information using the Yadis protocol (Potentially falling back to OpenID 1.0 "linkrel" discovery).
  3. The consumer site prepares a URL to be sent to the server which contains the OpenID autentication information, and issues a redirect user‘s browser.
  4. The server then verifies that the user owns the URL provided, and sends the browser a redirect back to the consumer. This redirect contains the server‘s response to the authentication request.

The most important part of the flow to note is the consumer‘s site must handle two separate HTTP requests in order to perform the full identity check. These two HTTP requests are described in steps 1 and 4 above, and are handled by Consumer.begin and Consumer.complete respectively.

Consumer Library Design

The library is designed with the above flow in mind. The goal is to make it as easy as possible to perform the above steps securely.

At a high level, there are two important parts in the consumer library. The first important part is the OpenID::Consumer class, which contains the public interface to the consumer logic. The second is the OpenID::Store class, which defines the interface needed to store the state the consumer needs to maintain between requests.

In general, the second part is less important for users of the library to know about, as several concrete store implementations are provided. The user simply needs to choose the store which best fits their environment and requirements.

Stores and Dumb Mode

OpenID is a protocol that works best when the consumer site is able to store some state. This is the normal mode of operation for the protocol, and is sometimes referred to as smart mode. There is also a fallback mode, known as dumb mode, which is available when the consumer site is not able to store state. This mode should be avoided when possible, as it leaves the implementation more vulnerable to replay attacks.

The mode the library works in for normal operation is determined by the store that it is given. The store is an abstraction that handles the data that the consumer needs to manage between HTTP requests in order to operate efficiently and securely.

Several store implementation are provided, and the interface is fully documented so that custom stores can be used as well. The implementations that are provided allow the consumer site to store data in a couple of different ways: in the filesystem, or in an SQL database.

There is an additional concrete store provided that puts the consumer in dumb mode. This is not recommended, as it removes the library‘s ability to stop replay attacks reliably. It still uses time-based checking to make replay attacks only possible within a small window, but they remain possible within that window. This store should only be used if the consumer site has no way to retain data between requests at all. See DumbStore for more info.

If your ennvironment permits, use of the FilesystemStore is recommended.

Immediate Mode

If you are new to OpenID, it is suggested that you skip this section and refer to it later. Immediate mode is an advanced consumer topic.

In the flow described in the overview, the user may need to confirm to the identity server that it‘s ok to authorize his or her identity. The server may draw pages asking for information from the user before it redirects the browser back to the consumer‘s site. This is generally transparent to the consumer site, so it is typically ignored as an implementation detail.

There can be times, however, where the consumer site wants to get a response immediately. When this is the case, the consumer can put the library in immediate mode. In immediate mode, there is an extra response possible from the server, which is essentially the server reporting that it doesn‘t have enough information to answer the question yet. In addition to saying that, the identity server provides a URL to which the user can be sent to provide the needed information and let the server finish handling the original request.

You may invoke immediate mode when building the redirect URL to the OpenID server in the SuccessRequest.redirect_url method. Pass true for the immediate paramter. Read the interface for Consumer.complete for information about handling the additional response.

Using the Library

Integrating this library into an application is a relatively straightforward process. The process usually follows this plan:

Add an OpenID login field somewhere on your site. When an OpenID is entered in that field and the form is submitted, it should make a request to the site which includes that OpenID URL.

When your site receives that request, it should create an OpenID::Consumer instance, and call OpenID::Consumer.begin. If begin completes successfully, it will return a SuccessRequest object. Otherwise it will subclass of OpenIDStatus which contains additional information about the the failure.

If successful, build a redirect URL to the server by calling SuccessRequest.redirect_url and send back an HTTP 302 redirect of that URL to the user‘s browser. The redirect_url accepts a return_to parameter, which is the URL to which they will return to fininsh the OpenID transaction. This URL is supplied by you, and should be able to handle step 4 of the flow described in the overview.

That‘s the first half of the authentication process. The second half of the process is done after the OpenID server sends the user‘s browser a redirect back to your site with the authentication response.

When that happens, the browser will make a request to the return_to URL you provided to the SuccessRequest.redirect_url method. The request will have several query parameters added to the URL by the identity server as the information necessary to finish the request.

Your job here is to make sure that the action performed at the return_to URL creates an instnce of OpenID::Consumer, and calls the Consumer.complete method. This call will return a SuccessResponse object, or a subclass of OpenIDStatus explaining, the failure. See the documentation for Consumer.complete for a full explanation of the possible responses.

If you received a SuccessResponse, you may access the identity URL of the user though it‘s identity_url method.

Methods

Attributes

consumer  [RW] 
fetcher  [RW] 
session  [RW] 

Public Class methods

Creates a new OpenID::Consumer instance. You should create a new instance of the Consumer object with every HTTP request that handles OpenID transactions. Do not store the instance of it in a global variable somewhere.

session
A hash-like object representing the user‘s session data. This is used for keeping state of the OpenID transaction when the user is redirected to the server. In a rails application, the controller‘s @session instance variable should be used.
store
This must be an object that implements the OpenID::Store interface. Several concrete implementations are provided, to cover most common use cases. We recommend using the simple file based store bundled with the library: OpenID::FilesystemStore.
fetcher
Optional. If provided, this must be an instance that implements OpenID::Fetcher interface. If no fetcher is provided, an OpenID::StandardFetcher instance will be created for you automatically. If you need custom fetcher behavior, it is probably best to subclass StandardFetcher, and pass your instance in here.

This object keeps an internal instance of OpenID::GenericConsumer for low level OpenID calls, called consumer. You may use a custom certificate authority PEM file for veryifying HTTPS server certs by calling the GenericConsumer.ca_path= method of the consumer instance variable.

Public Instance methods

begin is called to start the OpenID verification process. See steps 1-2 in the overview at the top of this file.

Parameters

user_url
Identity URL given by the user. begin performs a textual transformation of the URL to try and make sure it is "normalized", for example, a user_url of example.com will be normalized to example.com/ normalizing and resolving any redirects the server might issue.

Return Value

begin returns a subclass of OpenIDStatus, which is an object that has a status method. The status methodfor this object will either return OpenID::SUCCESS, or OpenID::FAILURE. Generally begin will fail if the users’ OpenID page cannot be retrieved or OpenID server information cannot be determined.

Success

In the case that request.status equals OpenID::SUCCESS, the response will be of type OpenID::SuccessRequest. The SuccessRequest object may the be used to add simple registration extension arguments, using SuccessRequest.add_extension_arg, and build the redirect url to the server using SuccessRequest.redirect_url as described in step 3 of the overview.

The next step in the success case is to actually build the redirect URL to the server. Please see the documentation for SuccessRequest.redirect_url for details. Once the redirect url is created, you should issue an HTTP 302 temporary redirect to the user‘s browser, sending her to the OpenID server. Once the user finishes the operations on the server, she will be redirected back to the return_to URL you passed to redirect_url, which should invoke the Consumer.complete method.

Failure

If the library is unable to fetch the user_url, or no server information can be determined, or if the server information is malformed, begin will return a FailureRequest object. The status method of this object will return OpenID::FAILURE. FailureRequest objects have a msg method which provides more detailed information as to why the request failed.

Start the OpenID transaction without doing OpenID server discovery. This method is used internally by Consumer.begin after discovery is performed, and exists to provide an interface for library users needing to perform their own discovery.

Parameters

service must be an OpenID::OpenIDServiceEnpoint object, or an object that implements it‘s interface. You may produce these objects and perform discovery manually using OpenID::OpenIDDiscovery.

Return Value

begin_without_discovery always returns an OpenID::SuccessRequest object. Please see the success documentation for OpenID::Consumer.begin for more information.

Called to interpret the server‘s response to an OpenID request. It is called in step 4 of the flow described in the consumer overview.

Parameters

query
A hash of the query paramters for this HTTP request.

Return Value

Return value is a subclass of OpenIDStatus, and may have a status of OpenID::SUCCESS, OpenID::CANCEL, OpenID::FAILURE, or OpenID::SETUP_NEEDED. The status may be accessed through the status method of the response object.

When OpenID::SUCCESS is returned, the response object will be of type SuccessResponse, which has several useful attributes including identity_url, service, and a method extension_response for extracting potential signed extension reponses from the server. See the documentation for OpenID::SuccessResponse for more information about it‘s interface and methods.

In the case of response.status being OpenID::CANCEL, the user cancelled the OpenID transaction on the server. The response will be an instance of OpenID::CancelResponse, and you may access the originally submitted identity URL and service information through that object.

When status is OpenID::FAILURE, the object will be an instance of OpenID::FailureResponse. If the identity which failed can be determined it will be available by accessing the identity_url attribute of the response. FailureResponse objects also have a msg attribute which may be useful in debugging. If no msg is specified, msg will be nil.

When OpenID::SETUP_NEEDED is returned, the response object is an instance of OpenID::SetupNeededResponse. The useful piece of information contained in this response is the setup_url method, which should be used to send the user to the server and log in. This response is only generated by immediate mode requests (openid.mode=immediate). The user should be redirected in to the setup_url, either in the current window or in a new browser window.

Protected Instance methods

Used internally to create an instnace of the OpenIDDiscovery object.

[Validate]