Because most web applications store authentication details in cookies, it is useful to have an option to remove them on logout.
PythonOption external-cookie-names /apache_openid/cookie/:openidcookie
Authentication is allowed only for certain users.
PythonOption authorized-users "%(authorized_users)s"
PythonOption authorized-users-list-url file:///tmp/apache_openid/examples/openid/openids.txt
Contents of openids.txt:
%(authorized_users_lines)s
The simple OpenID authentication use-cases have no OPs configured, so you can enter any OpenID URLs on authentication.
If only one OP is configured, the authentication mechanism automatically redirects the user to that OP, so the whole process will be faster.
PythonOption allowed-op-list-url file:///var/www/apache_openid/ops/op-launchpad.txtContents of op-launchpad.txt:
Launchpad=login.launchpad.net
As the first step of the authentication process, a drop-down box is shown, where you can select through which provider you'd like to authenticate.
PythonOption allowed-op-list-url file:///var/www/apache_openid/ops/op-list.txtContents of op-list.txt:
Launchpad=login.launchpad.net MyOpenID=myopenid.com
By default a static page is displayed after logging out. However, it's possible to configure an URL where the user will be redirected after logging out.
PythonOption external-logout-url http://www.ubuntu.com/
PythonOption authorized-teams "%(authorized_teams)s"
PythonOption authorized-teams-list-url file:///var/www/apache_openid/teams/teams.txt
Contents of teams.txt:
%(authorized_teams_lines)s
As apache-openid works with modpython, if the app its protecting works with modwsgi (or anything that isn't modpython!) you can't have the OpenID-related actions within the same directory you're protecting.
WSGIScriptAlias /examples/wsgi/ /tmp/examples/wsgi/simple.wsgi
<Location "/examples/wsgi">
PythonAccessHandler apache_openid::protect
PythonOption handler openidteams
PythonOption store-type file
PythonOption store-directory /tmp/apache_openid
PythonOption action-path /examples/wsgi/openid
PythonOption authorized-users "%(authorized_users)s"
</Location>
<Location "/examples/wsgi/openid">
SetHandler mod_python
PythonAccessHandler apache_openid::protect
PythonOption handler openidteams
PythonOption store-type file
PythonOption store-directory /tmp/apache_openid
PythonOption action-path /examples/wsgi/openid
PythonOption authorized-users "%(authorized_users)s"
</Location>
The important difference to notice is that the first location doesn't have a SetHandler mod_python option. Both locations share their handler, store-type, store-directory, and other apache-openid options and, this is important, they both have an action-path option pointing to the second location, where you will have a SetHandler mod_python option enabled. The configured action-path could be outside of the protected app's path altogether, on /openid/ for example.
When applying apache-openid protection to a whole site, if the protected app doesn't use modpython, you'll need to use an explicit action-path, as explained in the previous example. Doing this when you already have blanket protection for the whole site can mean trouble, as you'll effectively end up with two handlers for the actions paths, unless you avoid handling actions from your blanket handler. For that you can use the protect_noactions access handler:
<Location "/examples/blanket">
PythonAccessHandler apache_openid::protect_noactions
PythonOption action-path "/examples/blanket/openid"
PythonOption handler openidteams
PythonOption store-type file
PythonOption store-directory /tmp/apache_openid
PythonOption allowed-op-list-url file:///tmp/examples/ops/op-launchpad.txt
PythonOption authorized-teams "enter-your-favourite-team-here"
</Location>
<Location "/examples/blanket/openid/">
SetHandler mod_python
PythonHandler apache_openid::protect
</Location>
Notice how, on the bright side, you can skip most of the config options for the inner location, as it'll be inherited from the blanket handler.