| paulb@360 | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| paulb@328 | 2 | <html xmlns="http://www.w3.org/1999/xhtml"> |
| paulb@328 | 3 | <head> |
| paulb@328 | 4 | <title>Securing a WebStack Application</title> |
| paulb@360 | 5 | <meta name="generator" |
| paulb@360 | 6 | content="amaya 8.1a, see http://www.w3.org/Amaya/" /> |
| paulb@328 | 7 | <link href="styles.css" rel="stylesheet" type="text/css" /> |
| paulb@328 | 8 | </head> |
| paulb@328 | 9 | <body> |
| paulb@328 | 10 | <h1>Securing a WebStack Application</h1> |
| paulb@360 | 11 | <p>Making sure that Web applications are "secure" involves many |
| paulb@360 | 12 | different |
| paulb@360 | 13 | aspects of application design, deployment and administration. This |
| paulb@360 | 14 | guide currently only covers the usage of the authentication features of |
| paulb@360 | 15 | the WebStack API.</p> |
| paulb@328 | 16 | <h2>Authentication in WebStack</h2> |
| paulb@360 | 17 | <p>There are two principal methods of introducing authentication and |
| paulb@360 | 18 | applying |
| paulb@328 | 19 | access control to WebStack applications:</p> |
| paulb@328 | 20 | <ul> |
| paulb@333 | 21 | <li><a href="authenticators.html">Application-Wide Authenticators</a></li> |
| paulb@333 | 22 | <li><a href="login-redirect.html">LoginRedirect and Login Modules</a></li> |
| paulb@333 | 23 | </ul> |
| paulb@334 | 24 | <p>Here is a comparison of the features of these mechanisms:</p> |
| paulb@360 | 25 | <table border="1" cellpadding="5" cellspacing="0"> |
| paulb@334 | 26 | <tbody> |
| paulb@334 | 27 | <tr> |
| paulb@334 | 28 | <td></td> |
| paulb@334 | 29 | <th>Application-Wide Authenticators</th> |
| paulb@334 | 30 | <th>LoginRedirect and Login Modules</th> |
| paulb@334 | 31 | </tr> |
| paulb@334 | 32 | <tr> |
| paulb@334 | 33 | <th>Deployment</th> |
| paulb@360 | 34 | <td> |
| paulb@360 | 35 | <ul> |
| paulb@360 | 36 | <li>Some Web server configuration required.</li> |
| paulb@360 | 37 | <li>The application only requires an additional object to be |
| paulb@360 | 38 | instantiated to support authentication.</li> |
| paulb@360 | 39 | </ul> |
| paulb@360 | 40 | </td> |
| paulb@360 | 41 | <td> |
| paulb@360 | 42 | <ul> |
| paulb@360 | 43 | <li>An additional login application or resource must be |
| paulb@360 | 44 | deployed.</li> |
| paulb@360 | 45 | </ul> |
| paulb@360 | 46 | </td> |
| paulb@334 | 47 | </tr> |
| paulb@334 | 48 | <tr> |
| paulb@334 | 49 | <th>Flexibility</th> |
| paulb@360 | 50 | <td> |
| paulb@360 | 51 | <ul> |
| paulb@360 | 52 | <li>The user experience may seem too inflexible or unfriendly - |
| paulb@360 | 53 | users may only get the login dialogue.</li> |
| paulb@360 | 54 | <li>There is also probably no logout function, since it |
| paulb@360 | 55 | requires browser support.</li> |
| paulb@360 | 56 | <li> HTTP-style authentication is well understood and supported |
| paulb@360 | 57 | when automating client access.</li> |
| paulb@360 | 58 | </ul> |
| paulb@360 | 59 | </td> |
| paulb@360 | 60 | <td> |
| paulb@360 | 61 | <ul> |
| paulb@360 | 62 | <li>The login and logout activities can be customised to suit |
| paulb@360 | 63 | the appearance of the rest of the application.</li> |
| paulb@360 | 64 | <li> Many applications can share the same login application, |
| paulb@360 | 65 | providing a "single sign-on" experience and potentially reduced |
| paulb@360 | 66 | administrative overhead.</li> |
| paulb@360 | 67 | </ul> |
| paulb@360 | 68 | </td> |
| paulb@334 | 69 | </tr> |
| paulb@334 | 70 | </tbody> |
| paulb@334 | 71 | </table> |
| paulb@328 | 72 | </body> |
| paulb@328 | 73 | </html> |
