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@333 | 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@333 | 23 | <li><a href="authenticators.html">Application-Wide Authenticators</a></li> |
paulb@333 | 24 | <li><a href="login-redirect.html">LoginRedirect and Login Modules</a></li> |
paulb@333 | 25 | </ul> |
paulb@334 | 26 | |
paulb@334 | 27 | <p>Here is a comparison of the features of these mechanisms:</p> |
paulb@334 | 28 | |
paulb@334 | 29 | <table border="1" cellspacing="0" cellpadding="5"> |
paulb@334 | 30 | <tbody> |
paulb@334 | 31 | <tr> |
paulb@334 | 32 | <td></td> |
paulb@334 | 33 | <th>Application-Wide Authenticators</th> |
paulb@334 | 34 | <th>LoginRedirect and Login Modules</th> |
paulb@334 | 35 | </tr> |
paulb@334 | 36 | <tr> |
paulb@334 | 37 | <th>Deployment</th> |
paulb@334 | 38 | <td>Some Web server configuration required.<br /> |
paulb@334 | 39 | Application only requires an additional object for |
paulb@334 | 40 | authentication.</td> |
paulb@334 | 41 | <td>An additional login application or resource must be deployed.</td> |
paulb@334 | 42 | </tr> |
paulb@334 | 43 | <tr> |
paulb@334 | 44 | <th>Flexibility</th> |
paulb@334 | 45 | <td>Possibly inflexible user experience - users may only get the login |
paulb@334 | 46 | dialogue; probably no logout function.<br /> |
paulb@334 | 47 | HTTP-style authentication is well understood and supported when |
paulb@334 | 48 | automating client access.</td> |
paulb@334 | 49 | <td>The login and logout activities can be customised to suit the |
paulb@334 | 50 | appearance of the rest of the application.<br /> |
paulb@334 | 51 | Many applications can share the same login application, providing a |
paulb@334 | 52 | "single sign-on" experience and potentially reduced administrative |
paulb@334 | 53 | overhead.</td> |
paulb@334 | 54 | </tr> |
paulb@334 | 55 | </tbody> |
paulb@334 | 56 | </table> |
paulb@328 | 57 | </body> |
paulb@328 | 58 | </html> |