1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/AUTH.txt Sat May 29 23:55:15 2004 +0000
1.3 @@ -0,0 +1,55 @@
1.4 +Authentication in WebStack
1.5 +--------------------------
1.6 +
1.7 +There are two principal methods of introducing authentication and applying
1.8 +access control to WebStack applications:
1.9 +
1.10 + * Use of authenticators, where the "remote user" is set in the
1.11 + server/framework environment and tested in the application.
1.12 +
1.13 + * Use of the LoginRedirect and Login resources.
1.14 +
1.15 +Application-wide Authenticators
1.16 +-------------------------------
1.17 +
1.18 +First, set up the usage of such authentication mechanisms in the
1.19 +server/framework environment. For example, introduce Auth directives in your
1.20 +Apache configuration (see docs/ModPython/NOTES.txt).
1.21 +
1.22 +Then, define an authenticator when deploying your application; this
1.23 +authenticator will respond with a decision when prompted by the server or
1.24 +underlying framework, either allowing or denying access for the user whose
1.25 +identity has been presented to the server/framework.
1.26 +
1.27 +In this mechanism, authenticators rely on authentication information from the
1.28 +server/framework and have a "global" effect on access to the application.
1.29 +
1.30 +LoginRedirect and Login Resources
1.31 +---------------------------------
1.32 +
1.33 +The LoginRedirect and Login resources provide a single sign-on environment for
1.34 +WebStack applications. Unlike the authenticator-only approach, each application
1.35 +or part of an application utilising this mechanism must be wrapped inside a
1.36 +LoginRedirect resource which determines whether a given transaction contains
1.37 +information identifying the application's user.
1.38 +
1.39 +Should sufficient information be present in the transaction, the user is allowed
1.40 +to access the application and is identified in the normal way (ie. the
1.41 +Transaction object's get_user method). Otherwise, a redirect occurs to the Login
1.42 +resource which then presents a login form to be completed by the user.
1.43 +
1.44 +The Login resource verifies the identity of the user, testing the supplied
1.45 +credentials against the credentials database specified in the deployment of the
1.46 +resource. Upon successful authentication, the user is redirected back to the
1.47 +application, which should let the user gain access.
1.48 +
1.49 +Some server/framework environments do not permit automatic redirection back to
1.50 +the application, notably Apache/mod_python. In such cases, a success screen is
1.51 +presented to the user with a link to the application they were attempting to
1.52 +access.
1.53 +
1.54 +In this mechanism, authenticators are employed, but only in the Login resource
1.55 +in order to verify the credentials of users. The LoginRedirector is the actual
1.56 +component that determines access to the application by testing whether the
1.57 +supplied authentication information is valid and redirecting them to the Login
1.58 +resource if this is not the case.