1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/securing.html Fri Apr 08 23:09:33 2005 +0000
1.3 @@ -0,0 +1,101 @@
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 +<html xmlns="http://www.w3.org/1999/xhtml">
1.8 +<head>
1.9 + <title>Securing a WebStack Application</title>
1.10 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
1.11 + <link href="styles.css" rel="stylesheet" type="text/css" />
1.12 +</head>
1.13 +
1.14 +<body>
1.15 +<h1>Securing a WebStack Application</h1>
1.16 +
1.17 +<p>Making sure that Web applications are "secure" involves many different
1.18 +aspects of application design, deployment and administration. This document
1.19 +covers only the usage of the authentication features of the WebStack API.</p>
1.20 +
1.21 +<h2>Authentication in WebStack</h2>
1.22 +
1.23 +<p>There are two principal methods of introducing authentication and applying
1.24 +access control to WebStack applications:</p>
1.25 +<ul>
1.26 + <li>Use of authenticators, where the "remote user" is set in the
1.27 + server/framework environment and tested in the application.</li>
1.28 + <li>Use of the <code>WebStack.Resources.LoginRedirect</code> and
1.29 + <code>WebStack.Resources.Login</code> modules.</li>
1.30 +</ul>
1.31 +
1.32 +<h3>Application-Wide Authenticators</h3>
1.33 +
1.34 +<p>First, set up the usage of such authentication mechanisms in the
1.35 +server/framework environment. For example, introduce <code>Auth</code>
1.36 +directives in your Apache configuration (see
1.37 +<code>docs/ModPython/NOTES.txt</code>) or protected folders in your Zope
1.38 +instance (see <code>docs/Zope/NOTES.txt</code>).</p>
1.39 +
1.40 +<p>Then, define an authenticator when deploying your application; this
1.41 +authenticator will respond with a decision when prompted by the server or
1.42 +underlying framework, either allowing or denying access for the user whose
1.43 +identity has been presented to the server/framework.</p>
1.44 +
1.45 +<p>In this mechanism, authenticators rely on authentication information from
1.46 +the server/framework and have a "global" effect on access to the
1.47 +application.</p>
1.48 +
1.49 +<h3>LoginRedirect and Login Modules</h3>
1.50 +
1.51 +<p>The <code>LoginRedirect</code> and <code>Login</code> modules provide a
1.52 +"single sign-on" environment for WebStack applications. Unlike the
1.53 +authenticator-only approach, each application or part of an application
1.54 +utilising this mechanism must be wrapped inside a
1.55 +<code>LoginRedirectResource</code> object which determines whether a given
1.56 +transaction contains information identifying the application's user.</p>
1.57 +
1.58 +<p>Should sufficient information be present in the transaction, the user is
1.59 +allowed to access the application and is identified in the normal way (ie.
1.60 +the <code>get_user</code> method on the transaction object). Otherwise, a
1.61 +redirect occurs to a login screen provided by a <code>LoginResource</code>
1.62 +object which then presents a login form to be completed by the user.</p>
1.63 +
1.64 +<p>The <code>LoginResource</code> object verifies the identity of the user,
1.65 +testing the supplied credentials against the credentials database specified
1.66 +in the deployment of the resource. Upon successful authentication, the user
1.67 +is redirected back to the application, which should let the user gain
1.68 +access.</p>
1.69 +
1.70 +<p>Some server/framework environments do not permit automatic redirection
1.71 +back to the application, notably Apache/mod_python. In such cases, a success
1.72 +screen is presented to the user with a link to the application they were
1.73 +attempting to access.</p>
1.74 +
1.75 +<p>In this mechanism, authenticators are employed, but only to verify the
1.76 +credentials of users when <code>LoginResource</code> or
1.77 +<code>LoginRedirectResource</code> objects are accessed.</p>
1.78 +
1.79 +<h3>Anonymous Access</h3>
1.80 +
1.81 +<p>With application-wide authenticators, anonymous access to resources and
1.82 +applications can be difficult to permit alongside access by specific users,
1.83 +mostly because servers and frameworks which employ HTTP authentication
1.84 +schemes do so globally for a given application.</p>
1.85 +
1.86 +<p>With the <code>LoginRedirect</code> and <code>Login</code> modules, it is
1.87 +possible to declare a particular request parameter which must be present in
1.88 +the URL used to access a particular application for the client to be given
1.89 +anonymous access. Consequently, anonymous users are then identified specially
1.90 +with a special username that can also be configured.</p>
1.91 +
1.92 +<h3>Logout Functions</h3>
1.93 +
1.94 +<p>With application-wide authenticators, a logout function may not be
1.95 +available if the server/framework has been configured to use HTTP
1.96 +authentication schemes, since no such function is defined for such
1.97 +schemes.</p>
1.98 +
1.99 +<p>With the <code>LoginRedirect</code> and <code>Login</code> modules, it is
1.100 +possible to declare a particular request parameter which must be present in
1.101 +the URL used to access a particular application for the client to be logged
1.102 +out. A special logout confirmation URL may also be configured.</p>
1.103 +</body>
1.104 +</html>