Replace Distributed Authentication System

Proposed by: Paul Kishimoto

Preamble

This stems from a SOC 2006 proposal, and pursuant to Moshe's comment thereon, from issue #97155. The general outline is inspired by this 2007 proposal (thanks!).

After a lot of reading I can't exclusively endorse OpenID, the Yahoo scheme linked in the SOC 2006 proposal (which I've never heard mentioned before), or anything else as the solution for Drupal. At the moment SAML seems like a good fit, but the decision should be left to the student.

Done right, this would be a killer feature for Drupal. Comments, revisions and flak are all welcome!

Problem

Drupal's current distributed authentication (DA) is insecure. It uses an XMLRPC call to drupal_login() on the authenticating website (provider); drupal_login() in turn calls user_load() with a plaintext password (which is only MD5-hashed inside user_load()). Because XMLRPC calls are unencrypted, the plaintext passwords can be obtained by snooping.

There is no reliable, single method to share user information between Drupal installations. For a multi-site installation, database tables may be shared; for single-site installations on the same server, tables in separate databases can be accessed through a variety of methods (eg. SQL VIEW). For installations on separate servers, no solution is available. Thus, Drupal administrators wishing to provide single sign-on (SSO) across many sites under their control must run one multi-site installation, or resort to core hacking.

Finally, there is no restriction of the current DA system to sites within a web of trust.

Proposal

The following tasks are proposed for a Summer of Code student:

• Identify authentication schemes that are potential replacements for current Drupal DA.
• Evaluate schemes with respect to interoperability, standards use, security and programmatic ease-of-use.
• Implement a new DA system using the most desirable scheme.
• Provide per-user, per-role or site-wide options for DA, including lists of trusted and blocked providers and consumers. This may include a requirement for providing a certificate, key or other shared secret for a trusted site.
• Optionally, extend the above systems to securely share user roles and permission information between Drupal sites.

Goals

• Provide basic security for SSO using Drupal DA.
• Conform to standards and increase interoperability.
• Create opportunities for modules consuming remote user information (eg. user/role/permission slaving).

Use Cases

• Alice logs in to drupal.org using a username and password from her own Drupal site. Drupal.org securely communicates an authentication request to Alice's site, receives a reply and logs her in.
• Bob is a developer who wants to save his users the trouble of creating accounts for Drupal sites on separate servers. He writes a module that uses DA hooks to authenticate all login requests by his primary site.
• Camille wants to allow several friends (Danny, Ellen and Frank) with their own Drupal sites to comment on her blog posts and stories. Through the Drupal administration pages, she chooses the addresses of these sites and enters keys provide to her by Danny, Ellen and Frank. These three can now log into Camille's site as themselves to post comments.

Comments on this proposal

This proposal seems pretty enormous
bonobo - March 12, 2007 - 18:45

Leaving aside that we are talking about functionality currently in core as the focus of a SoC project, there are a few issues with this:

1. SAML as the "best" choice is pretty subjective, and, given the myriad opinions already expressed on this, I feel no need to rehash these discussions here --

2. Along the same lines, the first four items in the "proposal" section are all pretty huge/time consuming. Implementing the 5th alongside these 4 seems difficult/unrealistic.

While this proposal points to a real need, it feels too broad for a SoC project.

Cheers,

Bill

-------
http://www.funnymonkey.com
Tools for Teachers
======================================================
======================================================

It could be; it could also be small
Paul Kishimoto - March 16, 2007 - 09:55

Thanks for your comment—I wasn't aware that functionality in core was ruled off-limits for SoC. Sorry!

If you re-read the proposal, you'll note that I state (in the preamble only) that I don't endorse any particular scheme. I mention SAML merely to drop the name alongside OpenID and others which, as you say, have already been discussed. I conclude "the decision should be left to the student," because I really feel that should be the case.

The fifth point of the proposal is "optional" for exactly the reason you state. As for the others, the rigour with which they are pursued is variable. Identifying and selecting a scheme could be as simple as gauging consensus among Drupal developers or reading past discussion; a detailed case study is not required. Similarly I stipulate "per-user, per-role or site-wide options," which requires only some form of trust control. The granularity is, once again, at the discretion of the supervisor and the student.

The language is deliberately ambiguous to allow flexibility in interpretation of the proposal, not to demand the impossible of a SoC student.
======================================================
======================================================