Skip to main content

A Django Central Authentication Service server implementing the CAS Protocol 3.0 Specification

Project description

CAS Server is a Django application implementing the CAS Protocol 3.0 Specification.

By defaut, the authentication process use django internal users but you can easily use any sources (see auth classes in the file)

The defaut login/logout template use django-bootstrap3 but you can use your own templates using settings variables.

Note that for Django 1.7 compatibility, you need a version of django-bootstrap3 < 7.0.0 like the 6.2.2 version.


  • Support CAS version 1.0, 2.0, 3.0

  • Support Single Sign Out

  • Configuration of services via the django Admin application

  • Fine control on which user’s attributes are passed to which service

  • Possibility to rename/rewrite attributes per service

  • Possibility to require some attribute values per service

  • Supports Django 1.7, 1.8 and 1.9

  • Supports Python 2.7, 3.x

Quick start

  1. Add “cas_server” to your INSTALLED_APPS setting like this:


    For internatinalization support, add “django.middleware.locale.LocaleMiddleware” to your MIDDLEWARE_CLASSES setting like this:

  2. Include the cas_server URLconf in your project like this:

    urlpatterns = [
        url(r'^cas/', include('cas_server.urls', namespace="cas_server")),
  3. Run python migrate to create the cas_server models.

  4. You should add some management commands to a crontab: clearsessions, cas_clean_tickets and cas_clean_sessions.

  • clearsessions: please see Clearing the session store.

  • cas_clean_tickets: old tickets and timed-out tickets do not get purge from the database automatically. They are just marked as invalid. cas_clean_tickets is a clean-up management command for this purpose. It send SingleLogOut request to services with timed out tickets and delete them.

  • cas_clean_sessions: Logout and purge users (sending SLO requests) that are inactive since more than SESSION_COOKIE_AGE. The default value for is 1209600 seconds (2 weeks). You probably should reduce it to something like 86400 seconds (1 day).

You could for example do as bellow :

0   0  * * * cas-user /path/to/project/ clearsessions
*/5 *  * * * cas-user /path/to/project/ cas_clean_tickets
5   0  * * * cas-user /path/to/project/ cas_clean_sessions
  1. Start the development server and visit to add a first service allowed to authenticate user agains the CAS (you’ll need the Admin app enabled).

  2. Visit to login with your django users.


All settings are optional. Add them to to customize django-cas-server:

Template settings:

  • CAS_LOGIN_TEMPLATE: Path to the template showed on /login then the user is not autenticated. The default is "cas_server/login.html".

  • CAS_WARN_TEMPLATE: Path to the template showed on /login?service=... then the user is authenticated and has asked to be warned before beeing connected to a service. The default is "cas_server/warn.html".

  • CAS_LOGGED_TEMPLATE: Path to the template showed on /login then to user is authenticated. The default is "cas_server/logged.html".

  • CAS_LOGOUT_TEMPLATE: Path to the template showed on /logout then to user is being disconnected. The default is "cas_server/logout.html"

  • CAS_REDIRECT_TO_LOGIN_AFTER_LOGOUT: Should we redirect users to /login after they logged out instead of displaying CAS_LOGOUT_TEMPLATE. The default is False.

Authentication settings:

  • CAS_AUTH_CLASS: A dotted path to a class implementing cas_server.auth.AuthUser. The default is "cas_server.auth.DjangoAuthUser"

  • SESSION_COOKIE_AGE: This is a django settings. Here, it control the delay in seconds after which inactive users are logged out. The default is 1209600 (2 weeks). You probably should reduce it to something like 86400 seconds (1 day).

  • CAS_PROXY_CA_CERTIFICATE_PATH: Path to certificates authority file. Usually on linux the local CAs are in /etc/ssl/certs/ca-certificates.crt. The default is True which tell requests to use its internal certificat authorities. Settings it to False should disable all x509 certificates validation and MUST not be done in production. x509 certificate validation is perform upon PGT issuance.

  • CAS_SLO_MAX_PARALLEL_REQUESTS: Maximum number of parallel single log out requests send. If more requests need to be send, there are queued. The default is 10.

  • CAS_SLO_TIMEOUT: Timeout for a single SLO request in seconds. The default is 5.

Tickets validity settings:

  • CAS_TICKET_VALIDITY: Number of seconds the service tickets and proxy tickets are valid. This is the maximal time between ticket issuance by the CAS and ticket validation by an application. The default is 60.

  • CAS_PGT_VALIDITY: Number of seconds the proxy granting tickets are valid. The default is 3600 (1 hour).

  • CAS_TICKET_TIMEOUT: Number of seconds a ticket is kept is the database before sending Single Log Out request and being cleared. The default is 86400 (24 hours).

Tickets miscellaneous settings:

  • CAS_TICKET_LEN: Default ticket length. All CAS implementation MUST support ST and PT up to 32 chars, PGT and PGTIOU up to 64 chars and it is RECOMMENDED that all tickets up to 256 chars are supports. Here the default is 64.

  • CAS_LT_LEN: Length of the login tickets. Login tickets are only processed by django-cas-server thus there is no length restriction on it. The default is CAS_TICKET_LEN.

  • CAS_ST_LEN: Length of the service tickets. The default is CAS_TICKET_LEN. You may need to lower is to 32 if you use some old clients.

  • CAS_PT_LEN: Length of the proxy tickets. The default is CAS_TICKET_LEN. This length should be the same as CAS_ST_LEN. You may need to lower is to 32 if you use some old clients.

  • CAS_PGT_LEN: Length of the proxy granting tickets. The default is CAS_TICKET_LEN.

  • CAS_PGTIOU_LEN: Length of the proxy granting tickets IOU. The default is CAS_TICKET_LEN.

  • CAS_LOGIN_TICKET_PREFIX: Prefix of login tickets. The default is "LT".

  • CAS_SERVICE_TICKET_PREFIX: Prefix of service tickets. The default is "ST". The CAS specification mandate that service tickets MUST begin with the characters ST so you should not change this.

  • CAS_PROXY_TICKET_PREFIX: Prefix of proxy ticket. The default is "ST".

  • CAS_PROXY_GRANTING_TICKET_PREFIX: Prefix of proxy granting ticket. The default is "PGT".

  • CAS_PROXY_GRANTING_TICKET_IOU_PREFIX: Prefix of proxy granting ticket IOU. The default is "PGTIOU".

Mysql backend settings. Only usefull is you use the mysql authentication backend:

  • CAS_SQL_HOST: Host for the SQL server. The default is "localhost".

  • CAS_SQL_USERNAME: Username for connecting to the SQL server.

  • CAS_SQL_PASSWORD: Password for connecting to the SQL server.

  • CAS_SQL_DBNAME: Database name.

  • CAS_SQL_DBCHARSET: Database charset. The default is "utf8"

  • CAS_SQL_USER_QUERY: The query performed upon user authentication. The username must be in field username, the password in password, additional fields are used as the user attributes. The default is "SELECT user AS usersame, pass AS password, users.* FROM users WHERE user = %s"

  • CAS_SQL_PASSWORD_CHECK: The method used to check the user password. Must be "crypt" or "plain”. The default is "crypt".

Authentication backend

django-cas-server comes with some authentication backends:

  • dummy backend cas_server.auth.DummyAuthUser: all authentication attempt fails.

  • test backend cas_server.auth.TestAuthUser: username is test and password is test the returned attributes for the user are: {'nom': 'Nymous', 'prenom': 'Ano', 'email': ''}

  • django backend cas_server.auth.DjangoAuthUser: Users are authenticated agains django users system. This is the default backend. The returned attributes are the fields available on the user model.

  • mysql backend cas_server.auth.MysqlAuthUser: see the ‘Mysql backend settings’ section. The returned attributes are those return by sql query CAS_SQL_USER_QUERY.


django-cas-server logs most of its actions. To enable login, you must set the LOGGING ( variable is

Users successful actions (login, logout) are logged with the level INFO, failures are logged with the level WARNING and user attributes transmitted to a service are logged with the level DEBUG.

For exemple to log to syslog you can use :

    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'cas_syslog': {
            'format': 'cas: %(levelname)s %(message)s'
    'handlers': {
        'cas_syslog': {
            'level': 'INFO',
            'class': 'logging.handlers.SysLogHandler',
            'address': '/dev/log',
            'formatter': 'cas_syslog',
    'loggers': {
        'cas_server': {
            'handlers': ['cas_syslog'],
            'level': 'INFO',
            'propagate': True,

Or to log to a file:

    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'cas_file': {
            'format': '%(asctime)s %(levelname)s %(message)s'
    'handlers': {
        'cas_file': {
            'level': 'INFO',
            'class': 'logging.FileHandler',
            'filename': '/tmp/cas_server.log',
            'formatter': 'cas_file',
    'loggers': {
        'cas_server': {
            'handlers': ['cas_file'],
            'level': 'INFO',
            'propagate': True,

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

django-cas-server-0.4.4.tar.gz (53.9 kB view hashes)

Uploaded Source

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page