Advertising sustains the DA. Ads are hidden for members. Join today

On this page

OpenID Road Map for Drupal by Darren Ferguson

Last updated on
30 April 2025

Parts of the road map explained here change with the RFC on the OpenID roadmap from April 4, 2009.

Objective

The objective of this document is to outline some thoughts regarding the current Drupal OpenID client and provider functionality. In this document we hope to show that it is reasonable to split the two sets of functionality into two separate modules the provider and client (RP).

  • OpenID Provider – this will be a combination of modules that support OpenID Provider functionality.
  • OpenID Relying Party – this will be a combination of modules that support the OpenID Relying Party functionality.

OpenID Provider Module

Currently we have the openid_provider module written by James Walker. The module is still in an alpha state but it will allow you to log in via OpenID for a server. This module should be the basis for all of the provider modules. The provider module should support the following:

  • OpenID Provider: the main provider module supporting the establishment of the session and login.
  • OpenID Provider Persona: this would be a contrib module and would provide the user the ability to create personas on the server.
  • OpenID Provider SREG: this module would provide the ability to cope with simple registration requests that occur.
  • OpenID Provider AX: this module would provide the ability to cope with attribute exchange requests that occur.

By splitting the portions into smaller more manageable modules it will allow the user to manage what they are wanting their OpenID provider (Drupal in this case) to support. Also with splitting the modules and ultimately making the OpenID provider module a framework holder we can easily plug other modules into the framework as required.

OpenID Provider

The OpenID provider module will allow the user to establish a session and verify that they user does exist in the system and hence allow them to log in. The provider module should provide hooks that will allow the other sub modules to modify the request before it is sent back to the relying party.

hook_openid_provider – this hook will be similar to hook_openid on the client side however it will deal only with provider requests and it will pass in the request as an additional parameter so the modules have access to both the response the provider will send and the request that was received from the relying party.

OpenID Provider Persona

This module will deal solely with the creation, deletion and management of user personas. The module can tie into other modules such as the node_profile, CCK or any other in order to allow the users to synchronize the information in their personas with the information on their server. The openid_provider module would only ever receive information from the persona module when sreg or ax requests occur, however the persona module will be able to draw on an infinite number of possible areas in order to retrieve and return the data required.

  • Module will support multiple personas per user.
  • Module will allow synchronizing personas with other personas and outside entities such as profile nodes etc.
  • Module can provide a mapping between the sreg or ax attribute and the coresponding field in another type i.e. cck, node profile, user object etc. (Module will be utilized by the sreg and ax modules to retrieve these mappings so they can get the information and return it in the response).

OpenID Provider SREG

This module will provide the ability to respond to sreg requests that have been received by the OpenID Provider module. This module will implement hook_openid_provider and will return the pertinent information via this hook to the OpenID Provider module.

The module will either allow you to map sreg fields directly to the user object or via the OpenID Provider Persona module. (Can check if the persona module exists and if it does, can call the sreg mapping function which will return an array map with the sreg as the key and the pertinent information with which to resolve the sreg value).

The module should provide the ability for users to alter the OpenID Provider form to inform the users that sreg has been asked for and do they wish to transfer the specific fields to the relying party. If they do just once then we have to continually do this check. If they do all of the time, we can flag the variables and allow it to pass all of the time without displaying the form. We should allow the ability to provide different fields being returned per relying party since you might not wish to send all information to a specific relying party.

OpenID Provider AX

This module will provide the ability for attribute exchange for the OpenID Provider module. The module will do the same as the SREG above in that it will implement hook_openid_provider and will return the pertinent information via this hook to the OpenID Provider module.

The module will either allow you to map ax fields directly to the user object or via the OpenID Provider Persona module. (Can check if the persona module exists and if it does, can call the ax mapping function which will return an array map with the ax field as the key and the pertinent information with which to resolve the ax value. Note we would pass in the alias at this point so we know the key will be correct since AX does alias the request based off the namespace in the request sent by the relying party).

The module should provide the ability for users to alter the OpenID provider form to inform the users that sreg has been asked for and do they wish to transfer the specific fields to the relying party. If they do just once then we have to continually do this check. If they do all of the time, we can flag the variables and allow it to pass all of the time without displaying the form. We should allow the ability to provide different fields being returned per relying party since you might not wish to send all information to a specific relying party.

OpenID Relying Party Module

Currently in Drupal there is the OpenID module that is in drupal core. This module supports the basics for sending an OpenID request to a server and performs minimal sreg with the request in order to get a nickname and email address for the user incase a new Drupal user needs to be created. This module should be extended to include the following:

  • OpenID RP – this is the current OpenID module.
  • OpenID RP Persona – this would be a mapping module that will allow the users to map the sreg and ax portions to pertinent user objects such as the user object itself or the users profile node.
  • OpenID RP SREG – this would be a simple registration implementation for the module
  • OpenID RP AX – this would be a rp attribute exchange implementation for the module.
  • OpenID RP

This module is currently in Drupal core and is called the OpenID module. This module provides the basic hook_openid which allows modules to modify the request before it is sent to the provider. The issue with this module is once we receive a response the modules that implemented hook_openid have no way of retrieving the response and hence cannot do anything with the information they requested.

I would like to suggest a hook_openid_response for this module to implement. This hook would accept the user account for the user who has been logged in and also the response text. With the user account we can modify the user object if the mappings determine that is the way and then call the user_save function to make them permanent. The modules that implement the hook could then check the persona mappings for any other objects that may need to be updated and perform the update. This would be a very simple two line add to the module and would provide a lot of extra functionality that other modules could tie into.

OpenID RP Persona

This module will not be a listing of personas as per the provider module but will store mappings that the user can utilize to make sure the correct fields have the correct values in them. The module will provide the ability to map sreg and ax fields to their corresponding values. The module should provide the function to allow the calling modules the ability to retrieve these mappings.

OpenID RP SREG

This module will provide the ability to add sreg parameters to the request that is being sent to the OpenID provider. The fields that you wish to retrieve will then be added to the request in hook_openid that this module will implement and then returned to the module via hook_openid_response as hopefully will be implemented by the OpenID RP module.

The module once it receives its response will parse out only the sreg attributes and then get the mappings for each of these. Once the mappings have been found it will put the values into the mapping fields and then save them for the object be it the user or node profile or some other defined object supported by Drupal.

OpenID RP AX

This module will provide the ability to add ax parameters to the request being sent to the OpenID provider. The fields that you wish to retrieve will then be added to the request via hook_openid that this module will implement and then returned to the module via hook_openid_response.

This module will receive its response and then provide the alias that it is using for ax requests to the mapping function in order that it can receive the correct mappings based off its alias. Once the mappings have been found it will put the values into the mapping fields and then save them for the defined object.

Help improve this page

Page status: Not set

You can: