[OpenID] Make OpenID Easy to Adopt - Via FastCGI "Authorizer"

[Brian Maher]

Hello OpenID Users,

I've read up on openid and love it!  Yesterday I got my first
implementation of an openid consumer running using the lovely
Net::OpenID::JanRain::Consumer library.  The current implementation
I've done is very crude and not generic enough for general
consumption, however I do believe the "core idea" of my implementation
could make openid "enabling" a website super simple so I thought I
would share this idea.

>From a webmaster's perspective "open id enabling" your website could
be as easy as this:

  [1] Download from CPAN Net::OpenID::FastCGI::Authorizer and all
dependencies (this is the perl module that is "yet to be written").

  [2] Write a script as such:

    #!/usr/bin/perl -w
    use strict;
    use Net::OpenID::FastCGI::Authorizer qw(dispatch);
    dispatch("/path/to/configuration/file");

  [3] Configure your webserver so it uses this fastcgi authorizer.
Here is what the lighttpd configuration looks like (after applying the
patch here http://trac.lighttpd.net/trac/ticket/321):

  fastcgi.server = (
    "/" => ((
        "check-local" => "disable",
        "mode"        => "authorizer",
        "socket"      =>  var.root + "/state/fastcgi-authorizer.sock",
    ))
  )

  I haven't tried using the authorizer behind apache yet, but it looks
pretty straight forward:

  http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiAuthorizer

  [4] Set-up some configuration for the authorizer such as:

    * Set what data-store to use (file based or mysql based to begin
with).  This is the only required configuration.  If using mysql, you
must initialize the database by running `perl
-MNet::OpenID::FastCGI::Authorizer -e dbinit` which will prompt for
your db username/password.
    * Forcing redirects to SSL by specifying the SSL port.
    * Use a custom login form rather than the default.
    * Any URL patterns that do not require authentication.
    * Ability to exempt IP's and/or user agent strings from authentication.
    * The name of the cookie that stores the temporarily issued "cert".
    * Ability to somehow configure trusted and untrusted openid
providers.  For example, if a  malicious openid provider was used to
add spam to your website you could exclude them, or if you ran an
intranet you could set-up your authorizer so it only allows the
intranet openid provider and excludes all others.

  [5] Start-up your fastcgi application so it listens on the socket
mentioned in the webserver configuration.

The end result:

  All requests that are not some how "excluded from authentication"
will result in a redirect to a login form (which you may create a
custom version).  After entering their openid url in the form and
successfully authenticating, the user will be redirected back to the
original page they requested.

  The REMOTE_USER environment variable will be set to a users openid
url.  Most "applications" recognize this standard CGI environment
variable and will require very little customization.  This environment
variable can also easily be logged to your access log.

  This means static content can easily be "protected" without having
to go through a cgi.

  Please note that no "authorizing" is performed (aka no group
membership check), so this is not a complete solution, however it does
take care of the 90% use case, and most existing applications already
have their own authorizing scheme (aka the application knows who is an
admin and who is not an admin).

Please reply to me if you have interest in making the above happen, or
if you know of an existing implementation of the above.  If there is
not interest, then I will not bother.

Thanks,
-Brian

-- 
Brian Maher >> Glory to God <<