Authentication Middleware

All authentication can be handled transparently by a middleware component so that your application doesn't need to worry about how to sign users in. This means you can change how your users are authenticated without changing any of your application code.

The authentication middleware can intercept 401 and 403 responses so that the rest of you application doesn't even need to use AuthKit in order for the authenticate part to work.

In a WSGI application it is as simple as:

1	start_response('403 Access denied', [])

In Pylons this is as simple as writing:

1	abort(401)

The authenticate middleware supports the methods HTTP basic, HTTP digest, form and cookie (with sign out), OpenID passurl or internal forward to application. The middleware is either configured directly, from a generic config file or a paste deploy setup.

If you are using paste deploy you can add the middleware and set:

authkit.enable = false

in your config to disable it. One way of enabling it is to do something like this:

authkit.enable = true
authkit.method = basic
authkit.users = james:bananas
                ben:apples

Any 401 status will now be handled and james can sign in with password bananas and ben with apples. Nice and easy eh?

Of course there is a lot more to AuthKit. All the options are described in this manual.

Permission Objects

An auth system should provide a way to check user permissions and has to facilitate the developer in authorising a user at any point in the application stack that the developer feels is appropriate.

AuthKit solves this requirement with permission objects used like this:

1 2 3

from authkit.permissions import * permission1 = UserIn(users=['ben','james']) permission2 = And(RemoteUser(), Not(UserIn(['james'])))

You can use existing permissions or define them yourself.

Permissions have access to the WSGI environ dictionary and start_response callable so as well as being based on information from a database or LDAP repository they could be based on information from the request or even the response and have all the flexibility and power of WSGI middleware.

Authorization Objects

Permission objects need to be checked in different ways depending on where in the application stack the check occurs. There are different authorization objects for use in different parts of a WSGI application but they all have the same effect of requiring the user to be authorized based on the permission object

If a permission check fails a NotAuthorizedError or NotAuthenticatedError is raised by the authorisation object. This stops the request and is eventually handled by the httpexceptions middleware which turns it into a response with a 401 or 403 status code to be handled by the authentication middleware.

Using the above features it is possible to build a sophisticated auth system. AuthKit goes further though and also defines other objects which you can use as they stand, ignore completely or modify for your use:

User Management API

AuthKit provides a simple read-only, extensible user management API and permissions objects to use it. It allows you to get started straight away.

If you want to be able to use the exisitng permissions you can implement a user management API compatible with the AuthKit one and the existing funcationality will work.

If you want to start from scratch, all the authentication methods provide a means of handling user management yourself.

Framework Adaptors

Although AuthKit provides a totally generic API it also has built in support for configuration via Paste Deploy config files and comes with the authkit.pylons_adaptors module which provides tools for integrating AuthKit into Pylons quickly and easily.

It is hoped other framework developers will also implement version of AuthKit and the developers would be keen to assist with any such efforts.

The best way to explain the various components and how they all fit together is with some examples so lets get started.