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.
There are two principal methods of introducing authentication and applying access control to WebStack applications:
WebStack.Resources.LoginRedirect
and
WebStack.Resources.Login
modules.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.
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.
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.
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.