1 Authentication in WebStack
2 --------------------------
3
4 There are two principal methods of introducing authentication and applying
5 access control to WebStack applications:
6
7 * Use of authenticators, where the "remote user" is set in the
8 server/framework environment and tested in the application.
9
10 * Use of the WebStack.Resources.LoginRedirect and WebStack.Resources.Login
11 modules.
12
13 Application-wide Authenticators
14 -------------------------------
15
16 First, set up the usage of such authentication mechanisms in the
17 server/framework environment. For example, introduce Auth directives in your
18 Apache configuration (see docs/ModPython/NOTES.txt).
19
20 Then, define an authenticator when deploying your application; this
21 authenticator will respond with a decision when prompted by the server or
22 underlying framework, either allowing or denying access for the user whose
23 identity has been presented to the server/framework.
24
25 In this mechanism, authenticators rely on authentication information from the
26 server/framework and have a "global" effect on access to the application.
27
28 LoginRedirect and Login Modules
29 -------------------------------
30
31 The LoginRedirect and Login modules provide a single sign-on environment for
32 WebStack applications. Unlike the authenticator-only approach, each
33 application or part of an application utilising this mechanism must be wrapped
34 inside a LoginRedirectResource object which determines whether a given
35 transaction contains information identifying the application's user.
36
37 Should sufficient information be present in the transaction, the user is
38 allowed to access the application and is identified in the normal way (ie. the
39 Transaction object's get_user method). Otherwise, a redirect occurs to a login
40 screen provided by a LoginResource object which then presents a login form to
41 be completed by the user.
42
43 The LoginResource object verifies the identity of the user, testing the
44 supplied credentials against the credentials database specified in the
45 deployment of the resource. Upon successful authentication, the user is
46 redirected back to the application, which should let the user gain access.
47
48 Some server/framework environments do not permit automatic redirection back to
49 the application, notably Apache/mod_python. In such cases, a success screen is
50 presented to the user with a link to the application they were attempting to
51 access.
52
53 In this mechanism, authenticators are employed, but only to verify the
54 credentials of users when LoginResource or LoginRedirectResource objects are
55 accessed.
56
57 Anonymous Access
58 ----------------
59
60 With application-wide authenticators, anonymous access to resources and
61 applications can be difficult to permit alongside access by specific users,
62 mostly because servers and frameworks which employ HTTP authentication schemes
63 do so globally for a given application.
64
65 With the LoginRedirect and Login modules, it is possible to declare a
66 particular request parameter which must be present in the URL used to access a
67 particular application for the client to be given anonymous access.
68 Consequently, anonymous users are then identified specially with a special
69 username that can also be configured.
70
71 Logout Functions
72 ----------------
73
74 With application-wide authenticators, a logout function may not be available
75 if the server/framework has been configured to use HTTP authentication
76 schemes, since no such function is defined for such schemes.
77
78 With the LoginRedirect and Login modules, it is possible to declare a
79 particular request parameter which must be present in the URL used to access a
80 particular application for the client to be logged out. A special logout
81 confirmation URL may also be configured.
