1.1 --- a/docs/AUTH.txt Sun May 30 17:44:59 2004 +0000
1.2 +++ b/docs/AUTH.txt Sun May 30 18:00:39 2004 +0000
1.3 @@ -7,7 +7,8 @@
1.4 * Use of authenticators, where the "remote user" is set in the
1.5 server/framework environment and tested in the application.
1.6
1.7 - * Use of the LoginRedirect and Login resources.
1.8 + * Use of the WebStack.Resources.LoginRedirect and WebStack.Resources.Login
1.9 + modules.
1.10
1.11 Application-wide Authenticators
1.12 -------------------------------
1.13 @@ -24,32 +25,57 @@
1.14 In this mechanism, authenticators rely on authentication information from the
1.15 server/framework and have a "global" effect on access to the application.
1.16
1.17 -LoginRedirect and Login Resources
1.18 ----------------------------------
1.19 +LoginRedirect and Login Modules
1.20 +-------------------------------
1.21
1.22 -The LoginRedirect and Login resources provide a single sign-on environment for
1.23 -WebStack applications. Unlike the authenticator-only approach, each application
1.24 -or part of an application utilising this mechanism must be wrapped inside a
1.25 -LoginRedirect resource which determines whether a given transaction contains
1.26 -information identifying the application's user.
1.27 +The LoginRedirect and Login modules provide a single sign-on environment for
1.28 +WebStack applications. Unlike the authenticator-only approach, each
1.29 +application or part of an application utilising this mechanism must be wrapped
1.30 +inside a LoginRedirectResource object which determines whether a given
1.31 +transaction contains information identifying the application's user.
1.32
1.33 -Should sufficient information be present in the transaction, the user is allowed
1.34 -to access the application and is identified in the normal way (ie. the
1.35 -Transaction object's get_user method). Otherwise, a redirect occurs to the Login
1.36 -resource which then presents a login form to be completed by the user.
1.37 +Should sufficient information be present in the transaction, the user is
1.38 +allowed to access the application and is identified in the normal way (ie. the
1.39 +Transaction object's get_user method). Otherwise, a redirect occurs to a login
1.40 +screen provided by a LoginResource object which then presents a login form to
1.41 +be completed by the user.
1.42
1.43 -The Login resource verifies the identity of the user, testing the supplied
1.44 -credentials against the credentials database specified in the deployment of the
1.45 -resource. Upon successful authentication, the user is redirected back to the
1.46 -application, which should let the user gain access.
1.47 +The LoginResource object verifies the identity of the user, testing the
1.48 +supplied credentials against the credentials database specified in the
1.49 +deployment of the resource. Upon successful authentication, the user is
1.50 +redirected back to the application, which should let the user gain access.
1.51
1.52 Some server/framework environments do not permit automatic redirection back to
1.53 the application, notably Apache/mod_python. In such cases, a success screen is
1.54 presented to the user with a link to the application they were attempting to
1.55 access.
1.56
1.57 -In this mechanism, authenticators are employed, but only in the Login resource
1.58 -in order to verify the credentials of users. The LoginRedirector is the actual
1.59 -component that determines access to the application by testing whether the
1.60 -supplied authentication information is valid and redirecting them to the Login
1.61 -resource if this is not the case.
1.62 +In this mechanism, authenticators are employed, but only to verify the
1.63 +credentials of users when LoginResource or LoginRedirectResource objects are
1.64 +accessed.
1.65 +
1.66 +Anonymous Access
1.67 +----------------
1.68 +
1.69 +With application-wide authenticators, anonymous access to resources and
1.70 +applications can be difficult to permit alongside access by specific users,
1.71 +mostly because servers and frameworks which employ HTTP authentication schemes
1.72 +do so globally for a given application.
1.73 +
1.74 +With the LoginRedirect and Login modules, it is possible to declare a
1.75 +particular request parameter which must be present in the URL used to access a
1.76 +particular application for the client to be given anonymous access.
1.77 +Consequently, anonymous users are then identified specially with a special
1.78 +username that can also be configured.
1.79 +
1.80 +Logout Functions
1.81 +----------------
1.82 +
1.83 +With application-wide authenticators, a logout function may not be available
1.84 +if the server/framework has been configured to use HTTP authentication
1.85 +schemes, since no such function is defined for such schemes.
1.86 +
1.87 +With the LoginRedirect and Login modules, it is possible to declare a
1.88 +particular request parameter which must be present in the URL used to access a
1.89 +particular application for the client to be logged out. A special logout
1.90 +confirmation URL may also be configured.