WebStack

docs/AUTH.txt

289:43e23cde36c2
2004-09-21 paulb [project @ 2004-09-21 17:59:03 by paulb] Fixed path field discovery by removing parameters with empty names. This may not be totally correct, however.
     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.