While writing/testing some OpenID patches, I noticed that associating with a Google Account via OpenID on Drupal 6-15 no longer works.

With google.com or gmail.com as claimed id, discovery somehow 'fails' to get an OP identifier and I'll get the error message:

Sorry, that is not a valid OpenID. Please ensure you have spelled your ID correctly.

I will investigate further when I have time. It may simply be a change at Google's end.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Heine’s picture

Seems we're back to using https://www.google.com/accounts/o8/id as OP Identifier again :(

Heine’s picture

As far as I can see, this is a change at the google side.

IMO we have three choices:

1. Follow the recommended Google Login UI flow, where users select an image of the OpenID provider.
2. Hardcode support for https://www.google.com/accounts/o8/id when people enter a gmail address.
3. Do nothing and have people use https://www.google.com/accounts/o8/id as OP identifier

Considering the enormous userbase google has, my preference is for 2) as 1) is clearly impractical and would limit us to a small set of providers and 3) is pretty scary for endusers.

Heine’s picture

Title: Unable to use gmail.com as OP Identifier » Hardcode support for gmail.com as OP Identifier
Damien Tournoud’s picture

If we want to properly support Google (and Google Apps for Domain), we will have to implement Google's own discovery protocol:

http://groups.google.com/group/google-federated-login-api/web/openid-dis...

Seems like a good idea to me.

Damien Tournoud’s picture

Version: 6.15 » 7.x-dev

If I read that stuff correctly, Google discovery protocol is just a special case of normalization. The OpenID 2.0 specification (section 7.2) describe two normalizations: XRI and URL, we just need to add here a third one.

Bumping to Drupal 7, which has the same issue.

Damien Tournoud’s picture

Status: Active » Needs review
FileSize
6.23 KB

The following patch makes the discovery methods pluggable, and implement Google IDP (except signature verification).

Four discovery methods are tried in turn by default:

  • _openid_google_idp_discovery(): if the claimed identifier looks like an email address, extract its domain and try a Google IDP discovery on that
  • _openid_xri_discovery(): if the claimed identifier looks like a XRI, extract the corresponding XRDS and perform an XRDS discovery on that
  • _openid_xrds_discovery(): if the claimed identifier looks like an URL, perform an XRDS discovery
  • _openid_google_user_discovery(): if the claimed identifier looks like an URL, extract its domain and try a Google User discovery on that

The first method that retrieve a valid list of services win.

Damien Tournoud’s picture

Ignore the previous patch. This one has a correctly implemented openid_discovery(): the first discovery method that returns a valid list of services should win, and discovery should be stopped there.

Status: Needs review » Needs work

The last submitted patch, 727650-google-discovery-protocol.patch, failed testing.

Damien Tournoud’s picture

Status: Needs work » Needs review
FileSize
6.32 KB

Do not prevent stupid normalization example.com > http://example.com/ from happening.

Damien Tournoud’s picture

Improved patch, based on a Dries' review earlier tonight.

We make normalization methods pluggeable too, in addition to discovery methods. This allows implementing Google OpenID IDP as two separate operations:

Also improved the inline code comments, added test for the normalization operation, and added a CHANGELOG.txt entry.

Damien Tournoud’s picture

Title: Hardcode support for gmail.com as OP Identifier » Support Google-specific OpenID discovery protocol

Increasing the scope of this issue.

Damien Tournoud’s picture

Implemented proper (and tested) Attribute Exchange in #634562: OpenID AX support. This is the remaining piece needed for true OpenID awesomeness.

Dries’s picture

This is important because it actually allows us to extend the OpenID module in contrib, instead of being stuck with something that sucks. Committed to CVS HEAD!

Heine’s picture

Status: Needs review » Needs work

Unfortunately, foo@domain.tld is not only an email address, it is also a valid URL. The OpenID 2.0 specification demands that we normalize foo@domain.tld to http://foo@domain.tld before doing discovery.

As implemented now, we violate the OpenID 2.0 spec (again ;)

IMO normalization should not be touched, instead, after discovering 0 services via the normal OpenID 2.0/1.1 specification steps, we should try the additional Google discovery steps.

DamZ on IRC indicates this might mean that discovery must be able to change the claimed_id. A point of note is how this will change the way openid_complete works. Discovery there is essential for assertion verification.

Damien Tournoud’s picture

Status: Needs work » Needs review
FileSize
7.83 KB

I agree that we should stick to the specification as much as possible.

We can actually fold the two steps of the Google-specific discovery process into one, and run that only after standard discovery fails. There is actually no need to alter the claimed ID, because we are using the Claimed ID returned by the End Point in openid_complete(), after validating it.

Status: Needs review » Needs work

The last submitted patch, 727650-follow-up.patch, failed testing.

Heine’s picture

Does this only support option 2) Outsourcing of Signing and host-meta Hosting ? (seems indeed much easier).

Damien Tournoud’s picture

Status: Needs work » Needs review

#15: 727650-follow-up.patch queued for re-testing.

Damien Tournoud’s picture

@Heine: yes, because we haven't implemented the signature verification. Option 1) is not necessary if we only want to support Google-hosted domains for this discovery scheme.

rickvug’s picture

Awesome! Any chance of this change being backported to D6?

c960657’s picture

Hardcoding support for the Google OpenID provider in Drupal core seems controversial.

If I understands Google's strategy correctly, a Google-hosted domain will only work as an OpenID provider on sites that have hardcoded support for Google (like Drupal just got). A domain admin would have to add <meta http-equiv="X-XRDS-Location" content="https://www.google.com/accounts/o8/site-xrds?ns=2&hd=example.com"> to the website of the domain in order to make the accounts work as OpenID identities on other sites. The proposed protocol doesn't scale to a lot of email providers, because all sites supporting OpenID logins should maintain a list of all email providers supporting this protocol, and because the site should potentially contact every one of them when somebody logs in (the latter is both a performance issue and a privacy issue).

In the document linked in #4, Google mentions that they are “participating in several standardization organizations [...] to generate a next-generation OpenID discovery protocol.” However, the protocol described only supports discovery of Google's own domains, i.e. there is not much discovery going on. If a real discovery protocol is in the making, it'll be something different from what is described on that page.

If Google wants to allow their customers to use the accounts as OpenID identities, they could do that without introducing new protocols. It's unclear to me why they chose to remove support for entering just “gmail.com” and to introduce a discovery protocal that only works for themselves and not for other email providers. Are they being evil, or did I miss something?

I agree that supporting login using Google accounts would be a great win for Drupal, but adopting a proprietary protocol to do so seems against the spirit of Drupal, at least as long as we do not support other sign-on schemes like Facebook Connect or Windows Live ID.

Heine’s picture

The Google OpenID identifier is now:

http://www.google.com/profiles/[your profilename]

See http://www.flickr.com/photos/factoryjoe/4134418702/

c960657’s picture

Based on the arguments in #21 and below I suggest backing out the Google-specific discovery method.

The Google page describing the discovery protocol mentions two emerging standards, XRD and LRDD (3rd draft). XRD isn't used in the protocol at all. LRDD is used in the protocol (referred to as (1) in the quote below), but that isn't implemented in the Drupal. Instead we implement the Google Apps-specific variant (2).

On the page, Google themselves write:

(1) http://example.com/.well-known/host-meta
(2) https://www.google.com/accounts/o8/.well-known/host-meta?hd=example.com

RPs who follow the standard discovery flow would just use (1). However an RP can choose to also use (2), for example if they have a login box that explicitly asks users to enter a Google Apps domain name.

I.e. they don't really suggest that (2) is implemented in a general-purpose OpenID login box like the one in Drupal.

As mentioned in #21, the proposed discovery protocol is not required in order to use a Google Apps account as an OpenID identifier. Google Apps customers just need to configure their domain properly by inserting an X-XRDS-Location header or meta tag on their website. This is part of the original OpenID spec and is almost as powerful as the LRDD protocol, except for a few somewhat esoteric cases (see appendix B.3 and B.4).

Also, the protocol still seems a bit immature:
The Google page links to the 3rd draft of LRDD spec that refers to the 1st draft of the site-meta spec. The 5th LRDD draft was just published today. It refers to the 5th draft of the host-meta spec (the host-meta spec was originally part of the site-meta spec). In this document, the format of the host-meta document is no longer compatible with that mentioned in the previous version, i.e. the example given on the Google page and the current implementation in Drupal does not reflect the latest draft of the standard (in the introduction of host-meta draft 0, section 1 and host-meta draft 8, appendix C). The use of /.well-known/ as the preferred location for domain-wide policy files is now RFC 5785. AFAICT this is the only one of the several proposed standards that has reached RFC status. I think we should wait for the dust to settle on these standards before they are released aas part of Drupal core.

This patch backs out the Google Apps-specific discovery protocol but preserves the hooks that allow modules to supply their own discovery and normalization functions. This will allow site admins to install support for Google Apps using a contrib module (they should expect to update the module as the standard and Google's implementation thereof evolves).

Damien Tournoud’s picture

Status: Needs review » Reviewed & tested by the community

I agree with #23. Let's wait for dust to settle on this, we proved with this (premature) support that our OpenID implementation is flexible enough to support this in contrib. That's sufficient for me.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Alright. Rolled back. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

rfay’s picture

Has anything been done about this in contrib? I really had hopes for this feature.