view release on metacpan or  search on metacpan

Wyrd/Services/Auth.pm  view on Meta::CPAN

use 5.006;
use strict;
use warnings;
no warnings qw(uninitialized);

package Apache::Wyrd::Services::Auth;
our $VERSION = '0.98';
use Apache::Wyrd::Services::CodeRing;
use Apache::Wyrd::Services::TicketPad;
use Digest::SHA qw(sha256_hex);
use Apache::Wyrd::Request;
use Apache::Constants qw(AUTH_REQUIRED HTTP_SERVICE_UNAVAILABLE REDIRECT DECLINED);
use Apache::Wyrd::Cookie;
use Apache::URI;
use MIME::Base64;
use LWP::UserAgent;
use HTTP::Request::Common;

=pod

=head1 NAME

Apache::Wyrd::Services::Auth - Cookie-based authorization handler

=head1 SYNOPSIS

    <Directory /var/www/restricted/>
      SetHandler perl-script
      PerlHandler Apache::Wyrd::Services::Auth BASENAME::Handler
      PerlSetVar  LoginFormURL   /login.html
      PerlSetVar  NoCookieURL    /cookies.html
      PerlSetVar  LSKeyURL       https://login.someserver.com/login.html
      PerlSetVar  LSLoginURL     https://login.someserver.com/login.html
      PerlSetVar  LSDownURL      /lsdown.html
      PerlSetVar  AuthPath       /
      PerlSetVar  UserObject     BASENAME::User
      PerlSetVar  ReturnError    error_message
      PerlSetVar  AuthLevel      restricted
      PerlSetVar  Debug          0
      PerlSetVar  TieAddr        1
    </Directory>

=head1 DESCRIPTION

Auth provides a secure cookies-based login system for a Wyrd-enabled server
that might not itself be equipped with SSL.  It can do so if provided a
connection to an SSL-enabled Apache server with an
C<Apache::Wyrd::Services::LoginServer> available on a secure port.  It uses
a standard SSL channel to circumvent an unauthorized party from obtaining
login credentials (username/password) by packet-sniffing.

To do so, it maintains a cookie-based authorization scheme which is
implemented using stacked handlers.  It handles authorization by login
and/or cookie, and passes the user information to handlers down the
stack via mod_perl's C<notes> table.  The Auth module should be the
first handler in a chain of handlers.

The Auth Module first checks for a "challenge" variable under CGI which
it expects to contain a username/password pair encrypted via it's own
private encryption key (see the use of the
C<Apache::Wyrd::Services::Key> object in relation to the
C<Apache::Wyrd::Services::CodeRing> object).  This challenge is
generated by a LoginServer (see below), and is part of the regular login
sequence.  If this variable is provided, it will attempt to create a
user object from it and set a cookie on the browser (B<auth_cookie>)
which keeps this user object stored for later use.

If the challenge is not found, it checks for a cookie called
auth_cookie, and decrypts it, passing it on in an XML notes item called
"user" if it finds it.  (The user note is in perl code, stored and
retrieved by the next handler via C<XML::Dumper>.)

If the cookie is not found, it checks first to see if cookies are
enabled on the browser, and if not, sends the browser to a url to
explain the need for cookies.  It does this check by reloading the page
with a test cookie defined and checking for that cookie in the following
request.

If cookies are enabled, it will attempt to set up a login.  First, it
will establish an encrypted session with a login server via SSL in which
it will give the login server it's internal key, encrypted with a random
key and that key.  If this session fails, it will direct the browser to
a page explaining that the login server is down and authorization cannot
proceed.

If the session succeeds, it will encode the URL the browser originally
requested so that it may be redirected to that URL on successful login. 
This encoded URL, an authorization URL, and the encrypted key it gave
the login server is given to the browser as a GET-request redirection to
a login page.  On the login page, the encoded URL and the encrypted key
are to be used as hidden fields to pass to the login url which is given
as the action attribute of the login form.  The login form has, at a
minimum, a username and password.  These are all submitted to the login
server via SSL.

The login server will then decrypt the encrypted key, use that key to
encrypt the login information, and send that information to the
originally-requested URL via the challenge CGI variable.  As the Auth
object will again be in the stack, it will receive the challenge per the
first paragraph of this description.

Under SSL, instead, the Auth module checks for a user with appropriate
clearance.  Not finding one, it will expect to find the username and password
under CGI variables of those names.  If found, it will attempt athentication.
If this fails, as above, the browser will be redirected to the login URL.
Instead of a LoginServer, however, the login form will be expected to attempt
the URL it was refused in the first place, and will return the browser
to the login page on each subsequent failure until a login succeeds.

Note that under SSL, since CGI variables are scanned for authentication