Skip navigation.
Home

RP Discovery using Drupal

  • : preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/dopey/cozmanova.com/includes/unicode.inc on line 345.
  • : preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/dopey/cozmanova.com/includes/unicode.inc on line 345.
  • : preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/dopey/cozmanova.com/includes/unicode.inc on line 345.
  • : preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/dopey/cozmanova.com/includes/unicode.inc on line 345.

Drupal supports OpenID as a means for users to logon. This support is implemented in an optional OpenID module that the administrator of a Drupal site can check to install. While the OpenID protocol seems pretty simple, there are quite some functions to offer to actually support OpenID in every way that should be possible. One of these often features that can quite easily be overlooked, is RP Discovery. Most people find out about RP Discovery when trying to use OpenID with Yahoo, because of Yahoo mentions that a website is untrusted when it could not verify the RP.

RP Discovery is the process where an IdP takes the initiative to verify the realm or the return_to address that the client passed in the original checkid_setup-request (OpenID 2.0 specs for RP Discovery). To make RP Discovery work, the IdP tries to figure out where to find the XRDS-document for the RP by making a YADIS request to the "realm" or if this is not entered, the return_to address.

This request (that should contain HTTP Accept headers for application/xrds+xml) returns either:
- the XRDS document (server can know this because of the HTTP Accept headers)
- a HTTP-Response header X-XRDS-Location with the address of the XRDS-document
- a XRDS-location meta-tag in the resulting document, containing the address of the XRDS-document.

The XRDS-document must contain a Service/type of http://specs.openid.net/auth/2.0/return_to that has a Service/URI-element containing return_to-value that is used. The Drupal OpenID-module uses the context of your website as the realm, sho you should advertise this to be the valid return_to location.

These two parts of RP-discovery allow for two changes in Drupal:
1) Adjusting HTTP Response headers to advertise the XRDS-location
2) Creating an XRDS-document with the appropriate Service-type

Please note: the solution that is presented here is a quick hack to show how it should work; the proper implementation of a Drupal-module to implement this functionality is beyond the scope of this article, and should actually be contained in the existing OpenID-module.

To adjust the HTTP Response headers, you can adjust the function drupal_page_header() in include/bootstrap.inc to also include the following line:

header("X-XRDS-Location http://www.yourdomain.com/xrds.php");

To create the XRDS Document, create a file names "xrds.php" with the following content in the root directory of your website:


<?php
header("Content-type: application/xrds+xml; charset=UTF-8");
?><? echo "<?";?>xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="1">
<Type>http://specs.openid.net/auth/2.0/return_to</Type>
<URI>http://<? echo $_SERVER["HTTP_HOST"];?></URI>
</Service>
</XRD>
</xrds:XRDS>

That should do it!