1.1 --- a/docs/securing.html Sat Apr 09 23:25:43 2005 +0000
1.2 +++ b/docs/securing.html Sat Apr 09 23:25:58 2005 +0000
1.3 @@ -1,6 +1,6 @@
1.4 <?xml version="1.0" encoding="iso-8859-1"?>
1.5 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
1.6 - "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
1.7 + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
1.8 <html xmlns="http://www.w3.org/1999/xhtml">
1.9 <head>
1.10 <title>Securing a WebStack Application</title>
1.11 @@ -26,76 +26,10 @@
1.12 <code>WebStack.Resources.Login</code> modules.</li>
1.13 </ul>
1.14
1.15 -<h3>Application-Wide Authenticators</h3>
1.16 -
1.17 -<p>First, set up the usage of such authentication mechanisms in the
1.18 -server/framework environment. For example, introduce <code>Auth</code>
1.19 -directives in your Apache configuration (see
1.20 -<code>docs/ModPython/NOTES.txt</code>) or protected folders in your Zope
1.21 -instance (see <code>docs/Zope/NOTES.txt</code>).</p>
1.22 -
1.23 -<p>Then, define an authenticator when deploying your application; this
1.24 -authenticator will respond with a decision when prompted by the server or
1.25 -underlying framework, either allowing or denying access for the user whose
1.26 -identity has been presented to the server/framework.</p>
1.27 -
1.28 -<p>In this mechanism, authenticators rely on authentication information from
1.29 -the server/framework and have a "global" effect on access to the
1.30 -application.</p>
1.31 -
1.32 -<h3>LoginRedirect and Login Modules</h3>
1.33 -
1.34 -<p>The <code>LoginRedirect</code> and <code>Login</code> modules provide a
1.35 -"single sign-on" environment for WebStack applications. Unlike the
1.36 -authenticator-only approach, each application or part of an application
1.37 -utilising this mechanism must be wrapped inside a
1.38 -<code>LoginRedirectResource</code> object which determines whether a given
1.39 -transaction contains information identifying the application's user.</p>
1.40 -
1.41 -<p>Should sufficient information be present in the transaction, the user is
1.42 -allowed to access the application and is identified in the normal way (ie.
1.43 -the <code>get_user</code> method on the transaction object). Otherwise, a
1.44 -redirect occurs to a login screen provided by a <code>LoginResource</code>
1.45 -object which then presents a login form to be completed by the user.</p>
1.46 -
1.47 -<p>The <code>LoginResource</code> object verifies the identity of the user,
1.48 -testing the supplied credentials against the credentials database specified
1.49 -in the deployment of the resource. Upon successful authentication, the user
1.50 -is redirected back to the application, which should let the user gain
1.51 -access.</p>
1.52 -
1.53 -<p>Some server/framework environments do not permit automatic redirection
1.54 -back to the application, notably Apache/mod_python. In such cases, a success
1.55 -screen is presented to the user with a link to the application they were
1.56 -attempting to access.</p>
1.57 -
1.58 -<p>In this mechanism, authenticators are employed, but only to verify the
1.59 -credentials of users when <code>LoginResource</code> or
1.60 -<code>LoginRedirectResource</code> objects are accessed.</p>
1.61 -
1.62 -<h3>Anonymous Access</h3>
1.63 -
1.64 -<p>With application-wide authenticators, anonymous access to resources and
1.65 -applications can be difficult to permit alongside access by specific users,
1.66 -mostly because servers and frameworks which employ HTTP authentication
1.67 -schemes do so globally for a given application.</p>
1.68 -
1.69 -<p>With the <code>LoginRedirect</code> and <code>Login</code> modules, it is
1.70 -possible to declare a particular request parameter which must be present in
1.71 -the URL used to access a particular application for the client to be given
1.72 -anonymous access. Consequently, anonymous users are then identified specially
1.73 -with a special username that can also be configured.</p>
1.74 -
1.75 -<h3>Logout Functions</h3>
1.76 -
1.77 -<p>With application-wide authenticators, a logout function may not be
1.78 -available if the server/framework has been configured to use HTTP
1.79 -authentication schemes, since no such function is defined for such
1.80 -schemes.</p>
1.81 -
1.82 -<p>With the <code>LoginRedirect</code> and <code>Login</code> modules, it is
1.83 -possible to declare a particular request parameter which must be present in
1.84 -the URL used to access a particular application for the client to be logged
1.85 -out. A special logout confirmation URL may also be configured.</p>
1.86 +<h2>Choosing an Authentication Strategy</h2>
1.87 +<ul>
1.88 + <li><a href="authenticators.html">Application-Wide Authenticators</a></li>
1.89 + <li><a href="login-redirect.html">LoginRedirect and Login Modules</a></li>
1.90 +</ul>
1.91 </body>
1.92 </html>