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