paulb@360 | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
paulb@333 | 2 | <html xmlns="http://www.w3.org/1999/xhtml"> |
paulb@333 | 3 | <head> |
paulb@333 | 4 | <title>Application-Wide Authenticators</title> |
paulb@360 | 5 | <meta name="generator" |
paulb@360 | 6 | content="amaya 8.1a, see http://www.w3.org/Amaya/" /> |
paulb@333 | 7 | <link href="styles.css" rel="stylesheet" type="text/css" /> |
paulb@333 | 8 | </head> |
paulb@333 | 9 | <body> |
paulb@333 | 10 | <h1>Application-Wide Authenticators</h1> |
paulb@333 | 11 | <p>Authenticators are special classes which can, in conjunction with |
paulb@360 | 12 | mechanisms in the server environment, judge whether a user of an |
paulb@360 | 13 | application |
paulb@333 | 14 | is recognised or not. The process of using authenticators is as follows:</p> |
paulb@333 | 15 | <ol> |
paulb@360 | 16 | <li>Set up authentication in the server environment or framework in |
paulb@360 | 17 | which the application is to be deployed.</li> |
paulb@333 | 18 | <li>Introduce an authenticator class in the application.</li> |
paulb@333 | 19 | </ol> |
paulb@333 | 20 | <h2>Setting Up Authentication</h2> |
paulb@360 | 21 | <p>The exact details of configuring authentication mechanisms in each |
paulb@360 | 22 | server |
paulb@360 | 23 | environment may vary substantially. For example, Apache environments |
paulb@360 | 24 | require |
paulb@360 | 25 | that <code>Auth</code> directives be specified in the Apache |
paulb@360 | 26 | configuration |
paulb@360 | 27 | files (see <code>docs/ModPython/NOTES.txt</code>); in Zope |
paulb@360 | 28 | environments, |
paulb@360 | 29 | protected folders can be defined to hold the application when deployed |
paulb@360 | 30 | (see |
paulb@333 | 31 | <code>docs/Zope/NOTES.txt</code>).</p> |
paulb@333 | 32 | <h2>Defining an Authenticator</h2> |
paulb@360 | 33 | <p>An authenticator must be defined within your application in order to |
paulb@360 | 34 | make |
paulb@333 | 35 | decisions about users who have presented their credentials; this |
paulb@360 | 36 | authenticator will respond with a decision when prompted by the server |
paulb@360 | 37 | or |
paulb@360 | 38 | underlying framework, either allowing or denying access for the user |
paulb@360 | 39 | whose |
paulb@333 | 40 | identity has been presented to the server/framework.</p> |
paulb@333 | 41 | <p>The code for an authenticator usually looks like this:</p> |
paulb@360 | 42 | <pre>class MyAuthenticator:<br /><br /> "This is an authenticator - something which decides whether a user is known to the application."<br /><br /> def authenticate(self, trans):<br /> user = trans.get_user()<br /> [Make a decision about the validity of the user.]<br /> [Return a true value if the user is allowed to access the application.]<br /> [Return a false value if the user is not recognised or allowed to access the application.]<br /><br /> def get_auth_type(self):<br /> "This method returns 'Basic' in most deployments."<br /> return "Basic"<br /><br /> def get_realm(self):<br /> "This method returns something to distinguish this authentication mechanism from others."<br /> return "MyRealm"</pre> |
paulb@360 | 43 | <p>In this mechanism, authenticators rely on authentication information |
paulb@360 | 44 | from |
paulb@360 | 45 | the server environment and have a "global" effect on access to the |
paulb@360 | 46 | application. |
paulb@360 | 47 | However, it is always possible to test the user identity later on and |
paulb@360 | 48 | to |
paulb@360 | 49 | change the way an application behaves accordingly - see <a |
paulb@360 | 50 | href="users.html">"Users and Authentication"</a> for more information.</p> |
paulb@333 | 51 | <h2>Introducing an Authenticator</h2> |
paulb@333 | 52 | <p>Authenticator objects are created in the adapter code - see <a |
paulb@360 | 53 | href="writing-adapters.html">"Writing Adapters"</a> for more |
paulb@360 | 54 | information.</p> |
paulb@333 | 55 | <h2>Anonymous Access</h2> |
paulb@360 | 56 | <p>With application-wide authenticators, anonymous access to resources |
paulb@360 | 57 | and |
paulb@360 | 58 | applications can be difficult to permit alongside access by specific |
paulb@360 | 59 | users, |
paulb@333 | 60 | mostly because servers and frameworks which employ HTTP authentication |
paulb@333 | 61 | schemes do so globally for a given application.</p> |
paulb@333 | 62 | <h2>Logout Functions</h2> |
paulb@333 | 63 | <p>With application-wide authenticators, a logout function may not be |
paulb@333 | 64 | available if the server/framework has been configured to use HTTP |
paulb@360 | 65 | authentication schemes, mainly because no logout mechanism generally |
paulb@360 | 66 | exists |
paulb@333 | 67 | for such schemes.</p> |
paulb@333 | 68 | </body> |
paulb@333 | 69 | </html> |