kumi/django-cas-server
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

General editing of README.rst

Browse source
This commit is contained in:
Ken Whitesell 2020-05-28 16:44:14 -04:00 committed by Valentin Samir
parent f4b4428b94
commit 5f30d614e5
1 changed files with 83 additions and 82 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

165
README.rst
View file

@ -6,8 +6,8 @@ CAS Server
CAS Server is a Django application implementing the `CAS Protocol 3.0 Specification
<https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Specification.html>`_.
By default, the authentication process use django internal users but you can easily
use any sources (see the `Authentication backend`_ section and auth classes in the auth.py file)
By default, the authentication process uses django internal users but you can easily
use any source (see the `Authentication backend`_ section and auth classes in the auth.py file)
.. contents:: Table of Contents
@ -16,7 +16,7 @@ Features
* Support CAS version 1.0, 2.0, 3.0
* Support Single Sign Out
* Configuration of services via the django Admin application
* 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
@ -35,10 +35,10 @@ Dependencies
* lxml >= 3.4
* six >= 1.8
Minimal version of packages dependancy are just indicative and meens that ``django-cas-server`` has
Minimal version of package dependencies are just indicative and means that ``django-cas-server`` has
been tested with it. Previous versions of dependencies may or may not work.
Additionally, denpending of the `Authentication backend`_ you plan to use, you may need the following
Additionally, depending on the `Authentication backend`_ you plan to use, you may need the following
python packages:
* ldap3
@ -46,9 +46,9 @@ python packages:
* mysql-python
Here there is a table with the name of python packages and the corresponding packages providing
Here is a table with the name of python packages and the corresponding packages providing
them on debian like systems and centos like systems.
You should try as much as possible to use system packages as there are automatically updated then
You should try as much as possible to use system packages as they are automatically updated when
you update your system. You can then install Not Available (N/A)
packages on your system using pip inside a virtualenv as described in the `Installation`_ section.
For use with python3, just replace python(2) in the table by python3.
@ -126,7 +126,7 @@ The recommended installation mode is to use a virtualenv with ``--system-site-pa
`PYTHONPATH <https://docs.python.org/2/using/cmdline.html#envvar-PYTHONPATH>`_
(for instance by symlinking ``cas_server`` to the root of your django project).
7. Open ``cas_project/settings.py`` in you favourite editor and follow the quick start section.
7. Open ``cas_project/settings.py`` in your favourite editor and follow the quick start section.
Quick start
@ -166,15 +166,15 @@ Quick start
``cas_clean_tickets`` and ``cas_clean_sessions``.
* ``clearsessions``: please see `Clearing the session store <https://docs.djangoproject.com/en/stable/topics/http/sessions/#clearing-the-session-store>`_.
* ``cas_clean_tickets``: old tickets and timed-out tickets do not get purge from
* ``cas_clean_tickets``: old tickets and timed-out tickets do not get purged 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.
is a clean-up management command for this purpose. It sends SingleLogOut requests
to services with timed out tickets and deletes 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``
inactive more than ``SESSION_COOKIE_AGE``. The default value is ``1209600``
seconds (2 weeks). You probably should reduce it to something like ``86400`` seconds (1 day).
You could for example do as bellow::
You could, for example, do as below::
0 0 * * * cas-user /path/to/project/manage.py clearsessions
*/5 * * * * cas-user /path/to/project/manage.py cas_clean_tickets
@ -184,7 +184,7 @@ Quick start
6. Start the development server and visit http://127.0.0.1:8000/admin/
to add a first service allowed to authenticate user against the CAS
(you'll need the Admin app enabled). See the `Service Patterns`_ section bellow.
(you'll need the Admin app enabled). See the `Service Patterns`_ section below.
7. Visit http://127.0.0.1:8000/cas/ to login with your django users.
@ -200,12 +200,12 @@ All settings are optional. Add them to ``settings.py`` to customize ``django-cas
Template settings
-----------------
* ``CAS_LOGO_URL``: URL to the logo showed in the up left corner on the default
templates. Set it to ``False`` to disable it.
* ``CAS_LOGO_URL``: URL to the logo shown in the upper left corner on the default
template. Set it to ``False`` to disable it.
* ``CAS_FAVICON_URL``: URL to the favicon (shortcut icon) used by the default templates.
Default is a key icon. Set it to ``False`` to disable it.
* ``CAS_SHOW_POWERED``: Set it to ``False`` to hide the powered by footer. The default is ``True``.
* ``CAS_COMPONENT_URLS``: URLs to css and javascript external components. It is a dictionnary
* ``CAS_COMPONENT_URLS``: URLs to css and javascript external components. It is a dictionary
having the five following keys: ``"bootstrap3_css"``, ``"bootstrap3_js"``,
``bootstrap4_css``, ``bootstrap4_js``, ``"html5shiv"``, ``"respond"``, ``"jquery"``.
The default is::
@ -220,17 +220,17 @@ Template settings
"jquery": "//code.jquery.com/jquery.min.js",
}
if you omit some keys of the dictionnary, the default value for these keys is used.
if you omit some keys of the dictionary, the default value for these keys is used.
* ``CAS_SHOW_SERVICE_MESSAGES``: Messages displayed about the state of the service on the login page.
The default is ``True``.
* ``CAS_INFO_MESSAGES``: Messages displayed in info-boxes on the html pages of the default templates.
It is a dictionnary mapping message name to a message dict. A message dict has 3 keys:
It is a dictionary mapping message name to a message dict. A message dict has 3 keys:
* ``message``: A unicode message to display, potentially wrapped around ugettex_lazy
* ``discardable``: A boolean, specify if the users can close the message info-box
* ``type``: One of info, success, info, warning, danger. The type of the info-box.
* ``type``: One of info, success, warning, danger. The type of the info-box.
``CAS_INFO_MESSAGES`` contains by default one message, ``cas_explained``, which explain
``CAS_INFO_MESSAGES`` contains by default one message, ``cas_explained``, which explains
roughly the purpose of a CAS. The default is::
{
@ -241,20 +241,20 @@ Template settings
u"your session expires or you logout."
),
"discardable": True,
"type": "info", # one of info, success, info, warning, danger
"type": "info", # one of info, success, warning, danger
},
}
* ``CAS_INFO_MESSAGES_ORDER``: A list of message names. Order in which info-box messages are
displayed. Use an empty list to disable messages display. The default is ``[]``.
* ``CAS_LOGIN_TEMPLATE``: Path to the template showed on ``/login`` then the user
* ``CAS_LOGIN_TEMPLATE``: Path to the template shown on ``/login`` when the user
is not autenticated. The default is ``"cas_server/bs4/login.html"``.
* ``CAS_WARN_TEMPLATE``: Path to the template showed on ``/login?service=...`` then
* ``CAS_WARN_TEMPLATE``: Path to the template shown on ``/login?service=...`` when
the user is authenticated and has asked to be warned before being connected
to a service. The default is ``"cas_server/bs4/warn.html"``.
* ``CAS_LOGGED_TEMPLATE``: Path to the template showed on ``/login`` then to user is
* ``CAS_LOGGED_TEMPLATE``: Path to the template shown on ``/login`` when the user is
authenticated. The default is ``"cas_server/bs4/logged.html"``.
* ``CAS_LOGOUT_TEMPLATE``: Path to the template showed on ``/logout`` then to user
* ``CAS_LOGOUT_TEMPLATE``: Path to the template shown on ``/logout`` when the user
is being disconnected. The default is ``"cas_server/bs4/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``.
@ -270,23 +270,24 @@ Authentication settings
Available classes bundled with ``django-cas-server`` are listed below in the
`Authentication backend`_ section.
* ``SESSION_COOKIE_AGE``: This is a django settings. Here, it control the delay in seconds after
* ``SESSION_COOKIE_AGE``: This is a django setting. Here, it controls 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_TGT_VALIDITY``: Max time after with the user MUST reauthenticate. Let it to `None` for no
max time.This can be used to force refreshing cached informations only available upon user
* ``CAS_TGT_VALIDITY``: Max time after which the user MUST reauthenticate. Set it to `None` for no
max time. This can be used to force refreshing cached information only available upon user
authentication like the user attributes in federation mode or with the ldap auth in bind mode.
The default is ``None``.
* ``CAS_PROXY_CA_CERTIFICATE_PATH``: Path to certificate authorities 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.
tells requests to use its internal certificate authorities. Setting it to ``False`` should
disable all x509 certificate validation and MUST not be done in production.
x509 certificate validation is performed upon PGT issuance.
* ``CAS_SLO_MAX_PARALLEL_REQUESTS``: Maximum number of parallel single log out requests sent.
If more requests need to be sent, they are queued. The default is ``10``.
* ``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``.
@ -295,7 +296,7 @@ Federation settings
* ``CAS_FEDERATE``: A boolean for activating the federated mode (see the `Federation mode`_
section below). The default is ``False``.
* ``CAS_FEDERATE_REMEMBER_TIMEOUT``: Time after witch the cookie use for "remember my identity
* ``CAS_FEDERATE_REMEMBER_TIMEOUT``: Time after which the cookie used for "remember my identity
provider" expire. The default is ``604800``, one week. The cookie is called
``_remember_provider``.
@ -303,7 +304,7 @@ Federation settings
New version warnings settings
-----------------------------
* ``CAS_NEW_VERSION_HTML_WARNING``: A boolean for diplaying a warning on html pages then a new
* ``CAS_NEW_VERSION_HTML_WARNING``: A boolean for diplaying a warning on html pages that a new
version of the application is avaible. Once closed by a user, it is not displayed to this user
until the next new version. The default is ``True``.
* ``CAS_NEW_VERSION_EMAIL_WARNING``: A boolean for sending a email to ``settings.ADMINS`` when a new
@ -324,22 +325,22 @@ Tickets validity settings
Tickets miscellaneous settings
------------------------------
* ``CAS_TICKET_LEN``: Default ticket length. All CAS implementation MUST support ST and PT
* ``CAS_TICKET_LEN``: Default ticket length. All CAS implementations 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``.
to 256 chars are supported. 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``.
thus there are no length restrictions 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.
You may need to lower it 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``
This length should be the same as ``CAS_ST_LEN``. You may need to lower it 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
The CAS specification mandates 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 ``"PT"``.
* ``CAS_PROXY_GRANTING_TICKET_PREFIX``: Prefix of proxy granting ticket. The default is ``"PGT"``.
@ -349,7 +350,7 @@ Tickets miscellaneous settings
Mysql backend settings
----------------------
Deprecated, see the `Sql backend settings`_.
Only usefull if you are using the mysql authentication backend:
Only useful if you are using 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.
@ -363,12 +364,12 @@ Only usefull if you are using the mysql authentication backend:
* ``CAS_SQL_PASSWORD_CHECK``: The method used to check the user password. Must be one of the following:
* ``"crypt"`` (see <https://en.wikipedia.org/wiki/Crypt_(C)>), the password in the database
should begin this $
should begin with $
* ``"ldap"`` (see https://tools.ietf.org/id/draft-stroeder-hashed-userpassword-values-01.html)
the password in the database must begin with one of {MD5}, {SMD5}, {SHA}, {SSHA}, {SHA256},
{SSHA256}, {SHA384}, {SSHA384}, {SHA512}, {SSHA512}, {CRYPT}.
* ``"hex_HASH_NAME"`` with ``HASH_NAME`` in md5, sha1, sha224, sha256, sha384, sha512.
The hashed password in the database is compare to the hexadecimal digest of the clear
The hashed password in the database is compared to the hexadecimal digest of the clear
password hashed with the corresponding algorithm.
* ``"plain"``, the password in the database must be in clear.
@ -377,10 +378,10 @@ Only usefull if you are using the mysql authentication backend:
Sql backend settings
--------------------
Only usefull if you are using the sql authentication backend. You must add a ``"cas_server"``
Only useful if you are using the sql authentication backend. You must add a ``"cas_server"``
database to `settings.DATABASES <https://docs.djangoproject.com/en/stable/ref/settings/#std:setting-DATABASES>`__
as defined in the django documentation. It is then the database
use by the sql backend.
used by the sql backend.
* ``CAS_SQL_USER_QUERY``: The query performed upon user authentication.
The username must be in field ``username``, the password in ``password``,
@ -389,61 +390,61 @@ use by the sql backend.
* ``CAS_SQL_PASSWORD_CHECK``: The method used to check the user password. Must be one of the following:
* ``"crypt"`` (see <https://en.wikipedia.org/wiki/Crypt_(C)>), the password in the database
should begin this $
should begin with $
* ``"ldap"`` (see https://tools.ietf.org/id/draft-stroeder-hashed-userpassword-values-01.html)
the password in the database must begin with one of {MD5}, {SMD5}, {SHA}, {SSHA}, {SHA256},
{SSHA256}, {SHA384}, {SSHA384}, {SHA512}, {SSHA512}, {CRYPT}.
* ``"hex_HASH_NAME"`` with ``HASH_NAME`` in md5, sha1, sha224, sha256, sha384, sha512.
The hashed password in the database is compare to the hexadecimal digest of the clear
The hashed password in the database is compared to the hexadecimal digest of the clear
password hashed with the corresponding algorithm.
* ``"plain"``, the password in the database must be in clear.
The default is ``"crypt"``.
* ``CAS_SQL_PASSWORD_CHARSET``: Charset the SQL users passwords was hash with. This is needed to
encode the user sended password before hashing it for comparison. The default is ``"utf-8"``.
encode the user submitted password before hashing it for comparison. The default is ``"utf-8"``.
Ldap backend settings
---------------------
Only usefull if you are using the ldap authentication backend:
Only useful if you are using the ldap authentication backend:
* ``CAS_LDAP_SERVER``: Address of the LDAP server. The default is ``"localhost"``.
* ``CAS_LDAP_USER``: User bind address, for example ``"cn=admin,dc=crans,dc=org"`` for
connecting to the LDAP server.
* ``CAS_LDAP_PASSWORD``: Password for connecting to the LDAP server.
* ``CAS_LDAP_BASE_DN``: LDAP search base DN, for example ``"ou=data,dc=crans,dc=org"``.
* ``CAS_LDAP_USER_QUERY``: Search filter for searching user by username. User inputed usernames are
* ``CAS_LDAP_USER_QUERY``: Search filter for searching user by username. User entered usernames are
escaped using ``ldap3.utils.conv.escape_bytes``. The default is ``"(uid=%s)"``
* ``CAS_LDAP_USERNAME_ATTR``: Attribute used for users usernames. The default is ``"uid"``
* ``CAS_LDAP_PASSWORD_ATTR``: Attribute used for users passwords. The default is ``"userPassword"``
* ``CAS_LDAP_USERNAME_ATTR``: Attribute used for user's usernames. The default is ``"uid"``
* ``CAS_LDAP_PASSWORD_ATTR``: Attribute used for user's passwords. The default is ``"userPassword"``
* ``CAS_LDAP_PASSWORD_CHECK``: The method used to check the user password. Must be one of the following:
* ``"crypt"`` (see <https://en.wikipedia.org/wiki/Crypt_(C)>), the password in the database
should begin this $
should begin with $
* ``"ldap"`` (see https://tools.ietf.org/id/draft-stroeder-hashed-userpassword-values-01.html)
the password in the database must begin with one of {MD5}, {SMD5}, {SHA}, {SSHA}, {SHA256},
{SSHA256}, {SHA384}, {SSHA384}, {SHA512}, {SSHA512}, {CRYPT}.
* ``"hex_HASH_NAME"`` with ``HASH_NAME`` in md5, sha1, sha224, sha256, sha384, sha512.
The hashed password in the database is compare to the hexadecimal digest of the clear
The hashed password in the database is compared to the hexadecimal digest of the clear
password hashed with the corresponding algorithm.
* ``"plain"``, the password in the database must be in clear.
* ``"bind``, the user credentials are used to bind to the ldap database and retreive the user
attribute. In this mode, the settings ``CAS_LDAP_PASSWORD_ATTR`` and ``CAS_LDAP_PASSWORD_CHARSET``
are ignored, and it is the ldap server that perform password check. The counterpart is that
are ignored, and it is the ldap server that performs the password check. The counterpart is that
the user attributes are only available upon user password check and so are cached for later
use. All the other modes directly fetch the user attributes from the database whenever there
are needed. This mean that is you use this mode, they can be some difference between the
attributes in database and the cached ones if changes happend in the database after the user
authentiate. See the parameter ``CAS_TGT_VALIDITY`` to force user to reauthenticate periodically.
use. All the other modes directly fetch the user attributes from the database whenever they
are needed. This mean that is you use this mode, there can be some differences between the
attributes in database and the cached ones if changes happen in the database after the user
authentiates. See the parameter ``CAS_TGT_VALIDITY`` to force user to reauthenticate periodically.
The default is ``"ldap"``.
* ``CAS_LDAP_PASSWORD_CHARSET``: Charset the LDAP users passwords was hash with. This is needed to
encode the user sended password before hashing it for comparison. The default is ``"utf-8"``.
* ``CAS_LDAP_PASSWORD_CHARSET``: Charset the LDAP users passwords was hashed with. This is needed to
encode the user submitted password before hashing it for comparison. The default is ``"utf-8"``.
Test backend settings
---------------------
Only usefull if you are using the test authentication backend:
Only useful if you are using the test authentication backend:
* ``CAS_TEST_USER``: Username of the test user. The default is ``"test"``.
* ``CAS_TEST_PASSWORD``: Password of the test user. The default is ``"test"``.
@ -457,19 +458,19 @@ Authentication backend
``django-cas-server`` comes with some authentication backends:
* dummy backend ``cas_server.auth.DummyAuthUser``: all authentication attempt fails.
* dummy backend ``cas_server.auth.DummyAuthUser``: all authentication attempts fail.
* test backend ``cas_server.auth.TestAuthUser``: username, password and returned attributes
for the user are defined by the ``CAS_TEST_*`` settings.
* django backend ``cas_server.auth.DjangoAuthUser``: Users are authenticated against 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``: Deprecated, use the sql backend instead.
see the `Mysql backend settings`_ section. The returned attributes are those return by sql query
see the `Mysql backend settings`_ section. The returned attributes are those returned by sql query
``CAS_SQL_USER_QUERY``.
* sql backend ``cas_server.auth.SqlAuthUser``: see the `Sql backend settings`_ section.
The returned attributes are those return by sql query ``CAS_SQL_USER_QUERY``.
The returned attributes are those returned by sql query ``CAS_SQL_USER_QUERY``.
* ldap backend ``cas_server.auth.LdapAuthUser``: see the `Ldap backend settings`_ section.
The returned attributes are those of the ldap node returned by the query filter ``CAS_LDAP_USER_QUERY``.
* federated backend ``cas_server.auth.CASFederateAuth``: It is automatically used then ``CAS_FEDERATE`` is ``True``.
* federated backend ``cas_server.auth.CASFederateAuth``: It is automatically used when ``CAS_FEDERATE`` is ``True``.
You should not set it manually without setting ``CAS_FEDERATE`` to ``True``.
@ -547,7 +548,7 @@ Service Patterns
In a CAS context, ``Service`` refers to the application the client is trying to access.
By extension we use ``service`` for the URL of such an application.
By default, ``django-cas-server`` do not allow any service to use the CAS to authenticate users.
By default, ``django-cas-server`` does not allow any service to use the CAS to authenticate users.
In order to allow services, you need to connect to the django admin interface using a django
superuser, and add a first service pattern.
@ -560,7 +561,7 @@ A service pattern comes with 9 fields:
* ``Pattern``: a regular expression used to match services.
* ``User field``: the user attribute to use as username for services matching this service pattern.
Leave it empty to use the login name.
* ``Restrict username``: if checked, only login name defined below are allowed to get tickets
* ``Restrict username``: if checked, only login names defined below are allowed to get tickets
for services matching this service pattern.
* ``Proxy``: if checked, allow the creation of Proxy Ticket for services matching this
service pattern. Otherwise, only Service Ticket will be created.
@ -569,25 +570,25 @@ A service pattern comes with 9 fields:
Hence you must only check this for trusted services that need it. (For instance, a webmail needs
Proxy Ticket to authenticate himself as the user to the imap server).
* ``Single log out``: Check it to send Single Log Out requests to authenticated services matching
this service pattern. SLO requests are send to all services the user is authenticated to then
the user disconnect.
this service pattern. SLO requests are sent to all services the user is authenticated to when
the user disconnects.
* ``Single log out callback``: The http(s) URL to POST the SLO requests. If empty, the service URL
is used. This field is useful to allow non http services (imap, smtp, ftp) to handle SLO requests.
A service pattern has 4 associated models:
* ``Usernames``: a list of username associated with the ``Restrict username`` field
* ``Replace attribut names``: a list of user attributes to send to the service. Choose the name
used for sending the attribute by setting ``Remplacement`` or leave it empty to leave it unchanged.
* ``Replace attribut values``: a list of sent user attributes for which value needs to be tweak.
* ``Replace attribute names``: a list of user attributes to send to the service. Choose the name
used for sending the attribute by setting ``Replacement`` or leave it empty to leave it unchanged.
* ``Replace attribute values``: a list of sent user attributes for which value needs to be tweaked.
Replace the attribute value by the string obtained by replacing the leftmost non-overlapping
occurrences of ``pattern`` in string by ``replace``. In ``replace`` backslash escapes are processed.
Matched groups are captures by \1, \2, etc.
* ``Filter attribut values``: a list of user attributes for which value needs to match a regular
Matched groups are captured by \1, \2, etc.
* ``Filter attribute values``: a list of user attributes for which value needs to match a regular
expression. For instance, service A may need an email address, and you only want user with
an email address to connect to it. To do so, put ``email`` in ``Attribute`` and ``.*`` in ``pattern``.
Then a user ask a ticket for a service, the service URL is compare against each service patterns
When a user asks for a ticket for a service, the service URL is compared against each service pattern
sorted by ``position``. The first service pattern that matches the service URL is chosen.
Hence, you should give low ``position`` to very specific patterns like
``^https://www\.example\.com(/.*)?$`` and higher ``position`` to generic patterns like ``^https://.*``.
@ -598,9 +599,9 @@ So the service URL ``https://www.examle.com`` will use the service pattern for
Federation mode
===============
``django-cas-server`` comes with a federation mode. Then ``CAS_FEDERATE`` is ``True``,
user are invited to choose an identity provider on the login page, then, they are redirected
to the provider CAS to authenticate. This provider transmit to ``django-cas-server`` the user
``django-cas-server`` comes with a federation mode. When ``CAS_FEDERATE`` is ``True``,
users are invited to choose an identity provider on the login page, then, they are redirected
to the provider CAS to authenticate. This provider transmits to ``django-cas-server`` the user
username and attributes. The user is now logged in on ``django-cas-server`` and can use
services using ``django-cas-server`` as CAS.
@ -640,7 +641,7 @@ Then using federate mode, you should add one command to a daily crontab: ``cas_c
This command clean the local cache of federated user from old unused users.
You could for example do as bellow::
You could for example do as below::
10 0 * * * cas-user /path/to/project/manage.py cas_clean_federate