django-cas-provider is a consumer for the Central Authentication Service. It supports CAS version 1.0. It allows remote services to authenticate users for the purposes of Single Sign-On (SSO). For example, a user logs into a CAS server (provided by django-cas-provider) and can then access other services (such as email, calendar, etc) without re-entering her password for each service. For more details, see the CAS wiki. It is meant to be used alongside django-cas-provider.
To install, run the following command from this directory:
python setup.py install
Or, put cas_consumer somewhere on your Python path.
INSTALLED_APPStuple in settings.py.
- In settings.py, set
- In settings.py, set the CAS_* settings (detailed below).
- In urls.py, put the following line:
AUTHENTICATION_BACKENDStuple in settings.py
- CAS_BASE: The base URL of the CAS provider. Example:
'http://provider.com/cas/'. No default.
- CAS_SERVICE: The "service" URL to report to the provider. Example:
'http://example.com/cas/login/'. No default.
- CAS_NEXT_DEFAULT: URL to redirect to after successful login. Example (default):
- CAS_COMPLETELY_LOGOUT: Boolean. If True, the CAS provider will be notified of logout. Default: True
- CAS_REDIRECT_ON_LOGOUT: URL to redirect to after logout. Example (default):
- CAS_EMAIL_CALLBACK (optional): Python callable that generates an initial email address from a username when creating new user instances (because email address is
NOT NULLin most Django DBs, and often constrained to be unique). Defaults to appending a nonsense email domain to the username.
- CAS_USERINFO_CALLBACK (optional): Python callable that retrieves full name, email, etc from an external source. Default: None
For non-standard CAS implementations, it's sometimes necessary to fudge on a few of the details. These settings allow you to do that.
- CAS_SERVICE_LABEL: Name of the GET variable carrying the service info. Defaults to
- CAS_TICKET_LABEL: Name of the GET variable carrying the ticket info. Defaults to
- CAS_EXTRA_LOGIN_PARAMS: Dictionary of extra params that need to be passed to the server on a login request.
- CAS_EXTRA_VALIDATION_PARAMS: Dictionary of extra params that need to be passed to the server on ticket validation.
- CAS_LOGIN_URL: The url, relative to the CAS_BASE, where login requests to the server should be made. Defaults to
login/(notice the lack of a leading slash)
- CAS_VALIDATE_URL: The url, relative to the CAS_BASE, where validation requests to the server should be made. Defaults to
validate/(notice the lack of a leading slash)
- CAS_URLENCODE_PARAMS: Whether or not to use url encoding when making requests to the server. This is to address server implementations that don't properly url encode their data and don't expect url-encoded data. Defaults to
Trueobviously, as not url-encoding breaks any data with special characters.
def getUserInfo(user): """ Calls getFirstName, getLastName, getEmail, which call a remote service to get that information. Their implementations are not important for this example. """ user.first_name = getFirstName(user.username) user.last_name = getLastName(user.username) user.email = getEmail(user.username) user.save()
from your_app.helpers import getUserInfo CAS_USERINFO_CALLBACK = getUserInfo
Servers requiring a specific ordering of parameters
Some CAS server implementations require that GET variables arrive in a specific order. In that case, the
CAS_EXTRA_VALIDATION_PARAMS dictionaries can be used to enforce that order by using ordered dictionary classes. For example, to enforce a specific ordering of parameters on the validation request to the server (along with adding an extra parameter), you could define the following in you
from odict import odict CAS_EXTRA_VALIDATION_PARAMS = odict(( ('cassvc', 'IU'), (CAS_TICKET_LABEL, None), (CAS_SERVICE_LABEL, None)))
odict package can be installed via pypi and can also be found via the [Plone Archetypes SVN repo](https://svn.plone.org/svn/archetypes/AGX/odict/). Any Class that implements both the
dict methods should work though.