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@141 | 10 | * Use of the LoginRedirect and Login resources.
|
paulb@141 | 11 |
|
paulb@141 | 12 | Application-wide Authenticators
|
paulb@141 | 13 | -------------------------------
|
paulb@141 | 14 |
|
paulb@141 | 15 | First, set up the usage of such authentication mechanisms in the
|
paulb@141 | 16 | server/framework environment. For example, introduce Auth directives in your
|
paulb@141 | 17 | Apache configuration (see docs/ModPython/NOTES.txt).
|
paulb@141 | 18 |
|
paulb@141 | 19 | Then, define an authenticator when deploying your application; this
|
paulb@141 | 20 | authenticator will respond with a decision when prompted by the server or
|
paulb@141 | 21 | underlying framework, either allowing or denying access for the user whose
|
paulb@141 | 22 | identity has been presented to the server/framework.
|
paulb@141 | 23 |
|
paulb@141 | 24 | In this mechanism, authenticators rely on authentication information from the
|
paulb@141 | 25 | server/framework and have a "global" effect on access to the application.
|
paulb@141 | 26 |
|
paulb@141 | 27 | LoginRedirect and Login Resources
|
paulb@141 | 28 | ---------------------------------
|
paulb@141 | 29 |
|
paulb@141 | 30 | The LoginRedirect and Login resources provide a single sign-on environment for
|
paulb@141 | 31 | WebStack applications. Unlike the authenticator-only approach, each application
|
paulb@141 | 32 | or part of an application utilising this mechanism must be wrapped inside a
|
paulb@141 | 33 | LoginRedirect resource which determines whether a given transaction contains
|
paulb@141 | 34 | information identifying the application's user.
|
paulb@141 | 35 |
|
paulb@141 | 36 | Should sufficient information be present in the transaction, the user is allowed
|
paulb@141 | 37 | to access the application and is identified in the normal way (ie. the
|
paulb@141 | 38 | Transaction object's get_user method). Otherwise, a redirect occurs to the Login
|
paulb@141 | 39 | resource which then presents a login form to be completed by the user.
|
paulb@141 | 40 |
|
paulb@141 | 41 | The Login resource verifies the identity of the user, testing the supplied
|
paulb@141 | 42 | credentials against the credentials database specified in the deployment of the
|
paulb@141 | 43 | resource. Upon successful authentication, the user is redirected back to the
|
paulb@141 | 44 | application, which should let the user gain access.
|
paulb@141 | 45 |
|
paulb@141 | 46 | Some server/framework environments do not permit automatic redirection back to
|
paulb@141 | 47 | the application, notably Apache/mod_python. In such cases, a success screen is
|
paulb@141 | 48 | presented to the user with a link to the application they were attempting to
|
paulb@141 | 49 | access.
|
paulb@141 | 50 |
|
paulb@141 | 51 | In this mechanism, authenticators are employed, but only in the Login resource
|
paulb@141 | 52 | in order to verify the credentials of users. The LoginRedirector is the actual
|
paulb@141 | 53 | component that determines access to the application by testing whether the
|
paulb@141 | 54 | supplied authentication information is valid and redirecting them to the Login
|
paulb@141 | 55 | resource if this is not the case.
|