1 <?xml version="1.0" encoding="iso-8859-1"?> 2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 3 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 4 <html xmlns="http://www.w3.org/1999/xhtml"> 5 <head> 6 <title>Securing a WebStack Application</title> 7 <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" /> 8 <link href="styles.css" rel="stylesheet" type="text/css" /> 9 </head> 10 11 <body> 12 <h1>Securing a WebStack Application</h1> 13 14 <p>Making sure that Web applications are "secure" involves many different 15 aspects of application design, deployment and administration. This document 16 covers only the usage of the authentication features of the WebStack API.</p> 17 18 <h2>Authentication in WebStack</h2> 19 20 <p>There are two principal methods of introducing authentication and applying 21 access control to WebStack applications:</p> 22 <ul> 23 <li>Use of authenticators, where the "remote user" is set in the 24 server/framework environment and tested in the application.</li> 25 <li>Use of the <code>WebStack.Resources.LoginRedirect</code> and 26 <code>WebStack.Resources.Login</code> modules.</li> 27 </ul> 28 29 <h3>Application-Wide Authenticators</h3> 30 31 <p>First, set up the usage of such authentication mechanisms in the 32 server/framework environment. For example, introduce <code>Auth</code> 33 directives in your Apache configuration (see 34 <code>docs/ModPython/NOTES.txt</code>) or protected folders in your Zope 35 instance (see <code>docs/Zope/NOTES.txt</code>).</p> 36 37 <p>Then, define an authenticator when deploying your application; this 38 authenticator will respond with a decision when prompted by the server or 39 underlying framework, either allowing or denying access for the user whose 40 identity has been presented to the server/framework.</p> 41 42 <p>In this mechanism, authenticators rely on authentication information from 43 the server/framework and have a "global" effect on access to the 44 application.</p> 45 46 <h3>LoginRedirect and Login Modules</h3> 47 48 <p>The <code>LoginRedirect</code> and <code>Login</code> modules provide a 49 "single sign-on" environment for WebStack applications. Unlike the 50 authenticator-only approach, each application or part of an application 51 utilising this mechanism must be wrapped inside a 52 <code>LoginRedirectResource</code> object which determines whether a given 53 transaction contains information identifying the application's user.</p> 54 55 <p>Should sufficient information be present in the transaction, the user is 56 allowed to access the application and is identified in the normal way (ie. 57 the <code>get_user</code> method on the transaction object). Otherwise, a 58 redirect occurs to a login screen provided by a <code>LoginResource</code> 59 object which then presents a login form to be completed by the user.</p> 60 61 <p>The <code>LoginResource</code> object verifies the identity of the user, 62 testing the supplied credentials against the credentials database specified 63 in the deployment of the resource. Upon successful authentication, the user 64 is redirected back to the application, which should let the user gain 65 access.</p> 66 67 <p>Some server/framework environments do not permit automatic redirection 68 back to the application, notably Apache/mod_python. In such cases, a success 69 screen is presented to the user with a link to the application they were 70 attempting to access.</p> 71 72 <p>In this mechanism, authenticators are employed, but only to verify the 73 credentials of users when <code>LoginResource</code> or 74 <code>LoginRedirectResource</code> objects are accessed.</p> 75 76 <h3>Anonymous Access</h3> 77 78 <p>With application-wide authenticators, anonymous access to resources and 79 applications can be difficult to permit alongside access by specific users, 80 mostly because servers and frameworks which employ HTTP authentication 81 schemes do so globally for a given application.</p> 82 83 <p>With the <code>LoginRedirect</code> and <code>Login</code> modules, it is 84 possible to declare a particular request parameter which must be present in 85 the URL used to access a particular application for the client to be given 86 anonymous access. Consequently, anonymous users are then identified specially 87 with a special username that can also be configured.</p> 88 89 <h3>Logout Functions</h3> 90 91 <p>With application-wide authenticators, a logout function may not be 92 available if the server/framework has been configured to use HTTP 93 authentication schemes, since no such function is defined for such 94 schemes.</p> 95 96 <p>With the <code>LoginRedirect</code> and <code>Login</code> modules, it is 97 possible to declare a particular request parameter which must be present in 98 the URL used to access a particular application for the client to be logged 99 out. A special logout confirmation URL may also be configured.</p> 100 </body> 101 </html>