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