Securing a WebStack Application

Making sure that Web applications are "secure" involves many different aspects of application design, deployment and administration. This document covers only the usage of the authentication features of the WebStack API.

Authentication in WebStack

There are two principal methods of introducing authentication and applying access control to WebStack applications:

Application-Wide Authenticators

First, set up the usage of such authentication mechanisms in the server/framework environment. For example, introduce Auth directives in your Apache configuration (see docs/ModPython/NOTES.txt) or protected folders in your Zope instance (see docs/Zope/NOTES.txt).

Then, define an authenticator when deploying your application; this authenticator will respond with a decision when prompted by the server or underlying framework, either allowing or denying access for the user whose identity has been presented to the server/framework.

In this mechanism, authenticators rely on authentication information from the server/framework and have a "global" effect on access to the application.

LoginRedirect and Login Modules

The LoginRedirect and Login modules provide a "single sign-on" environment for WebStack applications. Unlike the authenticator-only approach, each application or part of an application utilising this mechanism must be wrapped inside a LoginRedirectResource object which determines whether a given transaction contains information identifying the application's user.

Should sufficient information be present in the transaction, the user is allowed to access the application and is identified in the normal way (ie. the get_user method on the transaction object). Otherwise, a redirect occurs to a login screen provided by a LoginResource object which then presents a login form to be completed by the user.

The LoginResource object verifies the identity of the user, testing the supplied credentials against the credentials database specified in the deployment of the resource. Upon successful authentication, the user is redirected back to the application, which should let the user gain access.

Some server/framework environments do not permit automatic redirection back to the application, notably Apache/mod_python. In such cases, a success screen is presented to the user with a link to the application they were attempting to access.

In this mechanism, authenticators are employed, but only to verify the credentials of users when LoginResource or LoginRedirectResource objects are accessed.

Anonymous Access

With application-wide authenticators, anonymous access to resources and applications can be difficult to permit alongside access by specific users, mostly because servers and frameworks which employ HTTP authentication schemes do so globally for a given application.

With the LoginRedirect and Login modules, it is possible to declare a particular request parameter which must be present in the URL used to access a particular application for the client to be given anonymous access. Consequently, anonymous users are then identified specially with a special username that can also be configured.

Logout Functions

With application-wide authenticators, a logout function may not be available if the server/framework has been configured to use HTTP authentication schemes, since no such function is defined for such schemes.

With the LoginRedirect and Login modules, it is possible to declare a particular request parameter which must be present in the URL used to access a particular application for the client to be logged out. A special logout confirmation URL may also be configured.