paulb@333 | 1 | <?xml version="1.0" encoding="iso-8859-1"?> |
paulb@333 | 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@333 | 4 | <html xmlns="http://www.w3.org/1999/xhtml"> |
paulb@333 | 5 | <head> |
paulb@333 | 6 | <title>Application-Wide Authenticators</title> |
paulb@333 | 7 | <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" /> |
paulb@333 | 8 | <link href="styles.css" rel="stylesheet" type="text/css" /> |
paulb@333 | 9 | </head> |
paulb@333 | 10 | |
paulb@333 | 11 | <body> |
paulb@333 | 12 | <h1>Application-Wide Authenticators</h1> |
paulb@333 | 13 | |
paulb@333 | 14 | <p>Authenticators are special classes which can, in conjunction with |
paulb@333 | 15 | mechanisms in the server environment, judge whether a user of an application |
paulb@333 | 16 | is recognised or not. The process of using authenticators is as follows:</p> |
paulb@333 | 17 | <ol> |
paulb@333 | 18 | <li>Set up authentication in the server environment or framework in which |
paulb@333 | 19 | the application is to be deployed.</li> |
paulb@333 | 20 | <li>Introduce an authenticator class in the application.</li> |
paulb@333 | 21 | </ol> |
paulb@333 | 22 | |
paulb@333 | 23 | <h2>Setting Up Authentication</h2> |
paulb@333 | 24 | |
paulb@333 | 25 | <p>The exact details of configuring authentication mechanisms in each server |
paulb@333 | 26 | environment may vary substantially. For example, Apache environments require |
paulb@333 | 27 | that <code>Auth</code> directives be specified in the Apache configuration |
paulb@333 | 28 | files (see <code>docs/ModPython/NOTES.txt</code>); in Zope environments, |
paulb@333 | 29 | protected folders can be defined to hold the application when deployed (see |
paulb@333 | 30 | <code>docs/Zope/NOTES.txt</code>).</p> |
paulb@333 | 31 | |
paulb@333 | 32 | <h2>Defining an Authenticator</h2> |
paulb@333 | 33 | |
paulb@333 | 34 | <p>An authenticator must be defined within your application in order to make |
paulb@333 | 35 | decisions about users who have presented their credentials; this |
paulb@333 | 36 | authenticator will respond with a decision when prompted by the server or |
paulb@333 | 37 | underlying framework, either allowing or denying access for the user whose |
paulb@333 | 38 | identity has been presented to the server/framework.</p> |
paulb@333 | 39 | |
paulb@333 | 40 | <p>The code for an authenticator usually looks like this:</p> |
paulb@333 | 41 | <pre>class MyAuthenticator: |
paulb@333 | 42 | |
paulb@333 | 43 | "This is an authenticator - something which decides whether a user is known to the application." |
paulb@333 | 44 | |
paulb@333 | 45 | def authenticate(self, trans): |
paulb@333 | 46 | user = trans.get_user() |
paulb@333 | 47 | [Make a decision about the validity of the user.] |
paulb@333 | 48 | [Return a true value if the user is allowed to access the application.] |
paulb@333 | 49 | [Return a false value if the user is not recognised or allowed to access the application.] |
paulb@333 | 50 | |
paulb@333 | 51 | def get_auth_type(self): |
paulb@333 | 52 | "This method returns 'Basic' in most deployments." |
paulb@333 | 53 | return "Basic" |
paulb@333 | 54 | |
paulb@333 | 55 | def get_realm(self): |
paulb@333 | 56 | "This method returns something to distinguish this authentication mechanism from others." |
paulb@333 | 57 | return "MyRealm"</pre> |
paulb@333 | 58 | |
paulb@333 | 59 | <p>In this mechanism, authenticators rely on authentication information from |
paulb@333 | 60 | the server/framework and have a "global" effect on access to the application. |
paulb@333 | 61 | However, it is always possible to test the user identity later on and to |
paulb@333 | 62 | change the way an application behaves accordingly.</p> |
paulb@333 | 63 | |
paulb@333 | 64 | <div class="WebStack"> |
paulb@333 | 65 | <h3>WebStack API - User Identity</h3> |
paulb@333 | 66 | |
paulb@333 | 67 | <p>Transaction objects have the following methods for inspecting and |
paulb@333 | 68 | redefining the identity of users:</p> |
paulb@333 | 69 | <dl> |
paulb@333 | 70 | <dt><code>get_user</code></dt> |
paulb@333 | 71 | <dd>This gets the name of the user attempting to access the |
paulb@333 | 72 | application.</dd> |
paulb@333 | 73 | <dt><code>set_user</code></dt> |
paulb@333 | 74 | <dd>This sets the name of the user, thus affecting subsequent calls to |
paulb@333 | 75 | <code>get_user</code>, allowing certain parts of an application to view |
paulb@333 | 76 | users according to other criteria than their basic username - for |
paulb@333 | 77 | example, one might use <code>set_user</code> to redefine each user's |
paulb@333 | 78 | identity in terms of the role that user may have in an application.</dd> |
paulb@333 | 79 | </dl> |
paulb@333 | 80 | </div> |
paulb@333 | 81 | |
paulb@333 | 82 | <h2>Introducing an Authenticator</h2> |
paulb@333 | 83 | |
paulb@333 | 84 | <p>Authenticator objects are created in the adapter code - see <a |
paulb@333 | 85 | href="writing-adapters.html">"Writing Adapters"</a> for more information.</p> |
paulb@333 | 86 | |
paulb@333 | 87 | <h2>Anonymous Access</h2> |
paulb@333 | 88 | |
paulb@333 | 89 | <p>With application-wide authenticators, anonymous access to resources and |
paulb@333 | 90 | applications can be difficult to permit alongside access by specific users, |
paulb@333 | 91 | mostly because servers and frameworks which employ HTTP authentication |
paulb@333 | 92 | schemes do so globally for a given application.</p> |
paulb@333 | 93 | |
paulb@333 | 94 | <h2>Logout Functions</h2> |
paulb@333 | 95 | |
paulb@333 | 96 | <p>With application-wide authenticators, a logout function may not be |
paulb@333 | 97 | available if the server/framework has been configured to use HTTP |
paulb@333 | 98 | authentication schemes, mainly because no logout mechanism generally exists |
paulb@333 | 99 | for such schemes.</p> |
paulb@333 | 100 | </body> |
paulb@333 | 101 | </html> |