paulb@141 | 1 | Authentication in WebStack
|
paulb@141 | 2 | --------------------------
|
paulb@141 | 3 |
|
paulb@141 | 4 | There are two principal methods of introducing authentication and applying
|
paulb@141 | 5 | access control to WebStack applications:
|
paulb@141 | 6 |
|
paulb@141 | 7 | * Use of authenticators, where the "remote user" is set in the
|
paulb@141 | 8 | server/framework environment and tested in the application.
|
paulb@141 | 9 |
|
paulb@158 | 10 | * Use of the WebStack.Resources.LoginRedirect and WebStack.Resources.Login
|
paulb@158 | 11 | modules.
|
paulb@141 | 12 |
|
paulb@141 | 13 | Application-wide Authenticators
|
paulb@141 | 14 | -------------------------------
|
paulb@141 | 15 |
|
paulb@141 | 16 | First, set up the usage of such authentication mechanisms in the
|
paulb@141 | 17 | server/framework environment. For example, introduce Auth directives in your
|
paulb@141 | 18 | Apache configuration (see docs/ModPython/NOTES.txt).
|
paulb@141 | 19 |
|
paulb@141 | 20 | Then, define an authenticator when deploying your application; this
|
paulb@141 | 21 | authenticator will respond with a decision when prompted by the server or
|
paulb@141 | 22 | underlying framework, either allowing or denying access for the user whose
|
paulb@141 | 23 | identity has been presented to the server/framework.
|
paulb@141 | 24 |
|
paulb@141 | 25 | In this mechanism, authenticators rely on authentication information from the
|
paulb@141 | 26 | server/framework and have a "global" effect on access to the application.
|
paulb@141 | 27 |
|
paulb@158 | 28 | LoginRedirect and Login Modules
|
paulb@158 | 29 | -------------------------------
|
paulb@141 | 30 |
|
paulb@158 | 31 | The LoginRedirect and Login modules provide a single sign-on environment for
|
paulb@158 | 32 | WebStack applications. Unlike the authenticator-only approach, each
|
paulb@158 | 33 | application or part of an application utilising this mechanism must be wrapped
|
paulb@158 | 34 | inside a LoginRedirectResource object which determines whether a given
|
paulb@158 | 35 | transaction contains information identifying the application's user.
|
paulb@141 | 36 |
|
paulb@158 | 37 | Should sufficient information be present in the transaction, the user is
|
paulb@158 | 38 | allowed to access the application and is identified in the normal way (ie. the
|
paulb@158 | 39 | Transaction object's get_user method). Otherwise, a redirect occurs to a login
|
paulb@158 | 40 | screen provided by a LoginResource object which then presents a login form to
|
paulb@158 | 41 | be completed by the user.
|
paulb@141 | 42 |
|
paulb@158 | 43 | The LoginResource object verifies the identity of the user, testing the
|
paulb@158 | 44 | supplied credentials against the credentials database specified in the
|
paulb@158 | 45 | deployment of the resource. Upon successful authentication, the user is
|
paulb@158 | 46 | redirected back to the application, which should let the user gain access.
|
paulb@141 | 47 |
|
paulb@141 | 48 | Some server/framework environments do not permit automatic redirection back to
|
paulb@141 | 49 | the application, notably Apache/mod_python. In such cases, a success screen is
|
paulb@141 | 50 | presented to the user with a link to the application they were attempting to
|
paulb@141 | 51 | access.
|
paulb@141 | 52 |
|
paulb@158 | 53 | In this mechanism, authenticators are employed, but only to verify the
|
paulb@158 | 54 | credentials of users when LoginResource or LoginRedirectResource objects are
|
paulb@158 | 55 | accessed.
|
paulb@158 | 56 |
|
paulb@158 | 57 | Anonymous Access
|
paulb@158 | 58 | ----------------
|
paulb@158 | 59 |
|
paulb@158 | 60 | With application-wide authenticators, anonymous access to resources and
|
paulb@158 | 61 | applications can be difficult to permit alongside access by specific users,
|
paulb@158 | 62 | mostly because servers and frameworks which employ HTTP authentication schemes
|
paulb@158 | 63 | do so globally for a given application.
|
paulb@158 | 64 |
|
paulb@158 | 65 | With the LoginRedirect and Login modules, it is possible to declare a
|
paulb@158 | 66 | particular request parameter which must be present in the URL used to access a
|
paulb@158 | 67 | particular application for the client to be given anonymous access.
|
paulb@158 | 68 | Consequently, anonymous users are then identified specially with a special
|
paulb@158 | 69 | username that can also be configured.
|
paulb@158 | 70 |
|
paulb@158 | 71 | Logout Functions
|
paulb@158 | 72 | ----------------
|
paulb@158 | 73 |
|
paulb@158 | 74 | With application-wide authenticators, a logout function may not be available
|
paulb@158 | 75 | if the server/framework has been configured to use HTTP authentication
|
paulb@158 | 76 | schemes, since no such function is defined for such schemes.
|
paulb@158 | 77 |
|
paulb@158 | 78 | With the LoginRedirect and Login modules, it is possible to declare a
|
paulb@158 | 79 | particular request parameter which must be present in the URL used to access a
|
paulb@158 | 80 | particular application for the client to be logged out. A special logout
|
paulb@158 | 81 | confirmation URL may also be configured.
|