How should an application interact with repoze.who? There are three main scenarios:
Examples of using the repoze.who middleware, without explicitly using its API.
This application expects the REMOTE_USER variable to be set by the middleware for authenticated requests. It allows the middleware to handle challenging the user when needed.
In protected views, such as those which allow creating or following up to bug reports:
Note that the application here doesn’t depend on repoze.who at all: it would work identically if run behind Apache’s mod_auth. The Trac application works exactly this way.
The middleware can be configured to suit the policy required for the site, e.g.:
This application use the repoze.who.identity variable set in the WSGI environment by the middleware for authenticated requests. The application still allows the middleware to handle challenging the user when needed.
The only difference from the previous example is that protected views, such as those which allow adding or editing wiki pages, can use the extra metadata stored inside environ['repoze.who.identity'] (a mapping) to make authorization decisions: such metadata might include groups or roles mapped by the middleware onto the user.
Examples of using the repoze.who API without its middleware.
This application uses the repoze.who API to compute the authenticated user, as well as using its remember API to set headers for cookie-based authentication.
In each view:
In protected views, such as those which allow adding or editing wiki pages:
In the login view:
In the logout view:
In this scenario, authentication is “federated” across multiple applications, which delegate to a central “login application.” This application verifies credentials from the user, and then uses headers or other tokens to communicate the verified identity to the delegating application.
In the login application:
In the non-login applications:
Examples of using the repoze.who API in conjuntion with its middleware.
This example extends the previous one, but adds into the mix the requirement that one or more of the non-login applications (e.g., Trac) be used “off the shelf,” without modifying them. Such applications can be plugged into the same SSO regime, with the addition of the :mod:repoze.who middleware as an adapter to bridge the gap (e.g., to turn the SSO tokens into the REMOTE_USER required by Trac).
In this scenario, the middleware would be configured identically to the API used in applications which do not need the middleware shim.