[OpenID] Make OpenID Easy to Adopt - Via FastCGI "Authorizer"
drecordon at verisign.com
Fri Feb 9 07:36:31 UTC 2007
You should get a hold of Jesse Vincent from Best Practical, he and I
were talking about this exact same thing a few days ago in terms of
developing an OpenID RP while on an airplane.
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Brian Maher
Sent: Monday, February 05, 2007 10:42 AM
To: general at openid.net
Subject: [OpenID] Make OpenID Easy to Adopt - Via FastCGI "Authorizer"
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
>From a webmaster's perspective "open id enabling" your website could be
as easy as this:
 Download from CPAN Net::OpenID::FastCGI::Authorizer and all
dependencies (this is the perl module that is "yet to be written").
 Write a script as such:
use Net::OpenID::FastCGI::Authorizer qw(dispatch);
 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:
 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
* 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
* 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.
 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
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.
Brian Maher >> Glory to God <<
general mailing list
general at openid.net
More information about the general