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