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