Configuration

In order for your project to use django-cas-ng, you’ll need to configure certain settings, add URL mappings, and sync your database.

Here is a post on guide to create a demo integration project.

You can also try live demo.

Settings

Now add it to the middleware, authentication backends and installed apps in your settings. Make sure you also have the authentication middleware installed. Here’s an example:

INSTALLED_APPS = (
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django_cas_ng',
    ...
)

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django_cas_ng.middleware.CASMiddleware',
    ...
)

AUTHENTICATION_BACKENDS = (
    'django.contrib.auth.backends.ModelBackend',
    'django_cas_ng.backends.CASBackend',
)

Set the following required setting in settings.py:

CAS_SERVER_URL [Required]

This is the only setting you must explicitly define. Set it to the base URL of your CAS source (e.g. https://account.example.com/cas/).

CAS_ADMIN_REDIRECT [Optional]

If True, django-cas-ng will also take over the Django administration site. If you use a mix of CAS accounts and local Django accounts, and want to use the latter to log in to the administration site, you should set it to False.

The default is True.

CAS_ADMIN_PREFIX [Optional]

The URL prefix of the Django administration site. If undefined, the CAS middleware will check the view being rendered to see if it lives in django.contrib.admin.views.

If CAS_ADMIN_REDIRECT is False, this option will be ignored.

The default is None.

CAS_CREATE_USER [Optional]

Create a user when the CAS authentication is successful.

The default is True.

CAS_CREATE_USER_WITH_ID [Optional]

Create a user using the id field provided by the attributes returned by the CAS provider. Raises ImproperlyConfigured exception if attributes are not provided or do not contain the field id.

The default is False.

CAS_LOGIN_MSG [Optional]

Welcome message send via the messages framework upon successful authentication. Take the user login as formatting argument.

You can disable it by setting this parameter to None

The default is "Login succeeded. Welcome, %s." or some translation of it if you have enabled django internationalization (USE_I18N = True)

CAS_LOGGED_MSG [Optional]

Welcome message send via the messages framework upon authentication attempt if the user is already authenticated. Take the user login as formatting argument.

You can disable it by setting this parameter to None

The default is "You are logged in as %s." or some translation of it if you have enabled django internationalization (USE_I18N = True)

CAS_LOGIN_URL_NAME [Optional]

Name of the login url.

This is only necessary if you use the middleware and want to use some other name for the login url (e.g. 'my_app:cas_login').

The default is 'cas_ng_login'.

CAS_LOGOUT_URL_NAME [Optional]

Name of the logout url.

This is only necessary if you use the middleware and want to use some other name for the logout url (e.g. 'my_app:cas_logout').

The default is 'cas_ng_logout'.

CAS_EXTRA_LOGIN_PARAMS [Optional]

Extra URL parameters to add to the login URL when redirecting the user. Example:

CAS_EXTRA_LOGIN_PARAMS = {'renew': true}

If you need these parameters to be dynamic, then we recommend to implement a wrapper for our default login view (the same can be done in case of the logout view). See an example in the section below.

The default is None.

CAS_RENEW [Optional]

Whether pass renew parameter on login and verification of ticket to enforce that the login is made with a fresh username and password verification in the CAS server.

The default is False.

CAS_IGNORE_REFERER [Optional]

If True, logging out of the application will always send the user to the URL specified by CAS_REDIRECT_URL.

The default is False.

CAS_LOGOUT_COMPLETELY [Optional]

If False, logging out of the application won’t log the user out of CAS as well.

The default is True.

CAS_REDIRECT_URL [Optional]

Where to send a user after logging in or out if there is no referrer and no next page set. This setting also accepts named URL patterns.

The default is /.

CAS_RETRY_LOGIN [Optional]

If True and an unknown or invalid ticket is received, the user is redirected back to the login page.

The default is False.

CAS_STORE_NEXT [Optional]

If True, the page to redirect to following login will be stored as a session variable, which can avoid encoding errors depending on the CAS implementation.

The default is False.

CAS_VERSION [Optional]

The CAS protocol version to use. The following version are supported:

  • '1'

  • '2'

  • '3'

  • 'CAS_2_SAML_1_0'

The default is '2'.

CAS_USERNAME_ATTRIBUTE [Optional]

The CAS user name attribute from response. The default behaviour is to map the cas:user value to the django username. This attribute allows one to override this behaviour and map a different attribute to the username e.g. mail, cn or uid. This feature is not available when CAS_VERSION is 'CAS_2_SAML_1_0'. Note that the attribute is checked before CAS_RENAME_ATTRIBUTES is applied.

The default is cas:user.

CAS_PROXY_CALLBACK [Optional]

The full URL to the callback view if you want to retrieve a Proxy Granting Ticket.

The defaults is None.

CAS_ROOT_PROXIED_AS [Optional]

Useful if behind a proxy server. If host is listening on http://foo.bar:8080 but request is https://foo.bar:8443. Add CAS_ROOT_PROXIED_AS = ‘https://foo.bar:8443’ to your settings.

CAS_FORCE_CHANGE_USERNAME_CASE [Optional]

If lower, usernames returned from CAS are lowercased before we check whether their account already exists. Allows user Joe to log in to CAS either as joe or JOE without duplicate accounts being created by Django (since Django allows case-sensitive duplicates). If upper, the submitted username will be uppercased.

The default is False.

CAS_APPLY_ATTRIBUTES_TO_USER [Optional]

If True any attributes returned by the CAS provider included in the ticket will be applied to the User model returned by authentication. This is useful if your provider is including details about the User which should be reflected in your model.

The default is False.

CAS_RENAME_ATTRIBUTES [Optional]

A dict used to rename the (key of the) attributes that the CAS server may retrun. For example, if CAS_RENAME_ATTRIBUTES = {'ln':'last_name'} the ln attribute returned by the cas server will be renamed as last_name. Used with CAS_APPLY_ATTRIBUTES_TO_USER = True, this provides an easy way to fill in Django Users’ info independently from the attributes’ keys returned by the CAS server.

CAS_VERIFY_SSL_CERTIFICATE [Optional]

If False CAS server certificate won’t be verified. This is useful when using a CAS test server with a self-signed certificate in a development environment.

Warning

If CAS_VERIFY_SSL_CERTIFICATE is disabled (False), meaning that SSL certificates are not being verified by a certificate authority. This can expose your system to various attacks and should never be disabled in a production environment.

The default is True.

CAS_LOCAL_NAME_FIELD [Optional]

If set, will make user lookup against this field and not model’s natural key. This allows you to authenticate arbitrary users.

CAS_FORCE_SSL_SERVICE_URL [Optional]

Available in 4.1.0.

Force the service url to always target HTTPS by setting CAS_FORCE_SSL_SERVICE_URL to True.

The default is False.

CAS_CHECK_NEXT [Optional]

Available in 4.1.2.

The URL provided by ?next is validated so that only local URLs are allowed. This check can be disabled by turning this setting to False (e.g. for local development).

The default is True.

CAS_SESSION_FACTORY [Optional]

Available in 4.2.2.

Can be a callable that returns a requests.Session instance. This can be used to to change behaviors when doing HTTP requests via the underlying requests library, such as HTTP headers, proxies, hooks and more. See requests library documentation for more details.

The default is None.

Example usage:

from requests import Session

def cas_get_session():
    session = Session()
    session.proxies["https"] = "http://proxy.example.org:3128"
    return session

CAS_SESSION_FACTORY = cas_get_session

CAS_MAP_AFFILIATIONS [Optional]

If True, django-cas-ng will create a Django group for each affiliation that the CAS server associates with the user, during the authentication process.

The default is False.

CAS_AFFILIATIONS_HANDLERS [Optional]

This is an optional list of functions to apply to the user’s CAS affiliations. The callback is: handler(user, affils).

The default is [].

CAS_LOGIN_NEXT_PAGE [Optional]

The relative path where to send a user after logging in. It may be different than CAS_REDIRECT_URL, for example if you want to use a specific callback function.

The default is None.

CAS_LOGOUT_NEXT_PAGE [Optional]

The relative path where to send a user after logging out. It may be different than CAS_REDIRECT_URL, for example if you want to use a specific callback function.

The default is None.

URL dispatcher

Make sure your project knows how to log users in and out by adding these to your URL mappings:

from django.urls import path
import django_cas_ng.views

urlpatterns = [
    # ...
    path('accounts/login', django_cas_ng.views.LoginView.as_view(), name='cas_ng_login'),
    path('accounts/logout', django_cas_ng.views.LogoutView.as_view(), name='cas_ng_logout'),
]

If you use the middleware, the login and logout url must be given the name cas_ng_login and cas_ng_logout or it will create redirection issues, unless you set the CAS_LOGIN_URL_NAME and CAS_LOGOUT_URL_NAME setting.

You should also add an URL mapping for the CAS_PROXY_CALLBACK setting, if you have this configured:

path('accounts/callback', django_cas_ng.views.CallbackView.as_view(), name='cas_ng_proxy_callback'),

Database

Run ./manage.py syncdb (or ./manage.py migrate for Django 1.7+) to create Single Sign On and Proxy Granting Ticket tables. On update you can just delete the django_cas_ng_sessionticket table and the django_cas_ng_proxygrantingticket before calling ./manage.py syncdb.

Consider running the command ./manage.py django_cas_ng_clean_sessions on a regular basis right after the command ./manage.py clearsessions cf clearsessions. It could be a good idea to put it in the crontab.

Users should now be able to log into your site using CAS.