No subject


Thu Jan 11 23:01:28 UTC 2007


  [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 =3D (
    "/" =3D> ((
        "check-local" =3D> "disable",
        "mode"        =3D> "authorizer",
        "socket"      =3D>  var.root + "/state/fastcgi-authorizer.sock",
    ))
  )

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

=20
http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiAuthoriz
er

  [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 <<
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general


More information about the general mailing list