/ 
Apache-Wyrd-0.81
River stage zero No dependents
/ Apache::Wyrd::Services::Auth

NAME

Apache::Wyrd::Services::Auth

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
</Directory>

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 Apache::Wyrd::Services::LoginServer available on a secure port. It is not designed to be highly secure, but 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 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 Apache::Wyrd::Services::Key object in relation to the 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 (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 via 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.

PERL METHODS

(format: (returns) name (arguments after self))

(RESPONSE) handler (Apache)

All the processes above are handled by the handler subroutine.

PERLSETVAR DIRECTIVES

LoginFormURL

Form URL (required)

UserObject

Module for the User object which performs authorization (required). See the Apache::Wyrd::User module.

NoCookieURL

URL to send cookie-less browsers to (required)

ReturnError

Send error back to the Login URL via the given variable (optional)

LSKeyURL

Login Server URL for key (required for now)

LSLoginURL

Login Server URL for login (required for now)

LSForce

Force the use of a Login Server on an SSL port 443 server (required on https for now)

LSDownURL

URL to redirect to when Login Server is down. (optional, but recommended)

UserVar

CGI param for username if not 'username'

PassVar

CGI param for password if not 'password'

BUGS/CAVEATS

As with many such schemes, man-in-the-middle attacks are always possible. Additionally, a "stolen cookie", i.e. one obtained via packet sniffing or similar technique can be used to gain access until the server's key is regenerated on server restart.

AUTHOR

Barry King <wyrd@nospam.wyrdwright.com>

SEE ALSO

Apache::Wyrd::Interfaces::GetUser

Methods for getting User/authorization information from the authorization cookie for use when no Auth method is in the handler stack.

Apache::Wyrd::Services::Key

Shared-memory encryption key and cypher.

Apache::Wyrd::Services::LoginServer

Perl Handler for login services.

LICENSE

Copyright 2002-2004 Wyrdwright, Inc. and licensed under the GNU GPL.

See LICENSE under the documentation for Apache::Wyrd.