Note: You are currently viewing documentation for Moodle 3.7. Up-to-date documentation for the latest stable version of Moodle may be available here: CAS server (SSO) authentication.

CAS server (SSO) authentication: Difference between revisions

From MoodleDocs
No edit summary
(page rewrite, new features template (MDL-51824))
Line 1: Line 1:
{{Authentication}}
{{Authentication}}
Location: Settings link in ''Settings > Site administration > Plugins > Authentication > Manage authentication''
The [https://en.wikipedia.org/wiki/Central_Authentication_Service Central Authentication Service] (CAS) is a single sign-on protocol for the web.


== Overview ==
CAS is very beneficial in environments where a number of different web applications share a set of common users.  If all the web applications were <em>"CASified"</em> a user would log in once and would then be able to move between the various web applications without ever having to present authentication credentials again.  CAS is similar to the [[Shibboleth]] authentication mechanism, but it is vastly simpler to set up and lacks a number of broader features like federated trust and authorization infrastructure.


CAS is "Single Sign-on for the Web" and is developed by [http://www.ja-sig.org/products/cas/ JA-SIG] in an open-source, collaborative manner.  CAS is very beneficial in environments where a number of different web applications share a set of common usersIf all the web applications were <em>"CASified"</em> a user would log in once and would then be able to move between the various web applications without ever having to present authentication credentials again.  CAS is similar to the [[Shibboleth]] authentication mechanism, but it is vastly simpler to set up and lacks a number of broader features like federated trust and authorization infrastructure.
CAS essentially works by configuring a Moodle site to not do authentication itself, but to instead forward unauthenticated users to a CAS server which will then return an authentication token to the Moodle siteMoodle can extract the username from the token and then use its internal authorization mechanisms (roles, enrollments, capabilities) and user attributes (name, picture, etc.).  The advantage is that the Moodle site never has to handle passwords and that users, once they've authenticated the first time, can move seamlessly to another web application without having to present their credentials again.


The details for how CAS works are [http://www.jasig.org/cas/cas2-architecture well documented], but CAS essentially works by configuring a web application (moodle.example.com) to not do authentication itself, but to instead forward unauthenticated users to a <em>"CAS Server"</em> (cas.example.com) which will then return an authentication token to the original web application (moodle.example.com).  Moodle can extract the username from the token and then use its internal authorization mechanisms (roles, enrollments, capabilities) and user attributes (name, picture, etc.).  The advantage is that the moodle.example.com service never has to handle passwords and that users, once they've authenticated the first time, can move seamlessly to another web application without having to present their credentials again.
==Enabling CAS server authentication==


== Configuration ==
An administrator can enable CAS server authentication as follows:


Assuming that you already have a working CAS server, configuration is fairly straightforward through the web interface.
# Go to ''Site administration > Plugins > Authentication > Manage authentication'' and click the eye icon opposite CAS server (SSO). When enabled, it will no longer be greyed out.
# Click the settings link, configure as required, then click the 'Save changes' button.


One caveat for those converting from LDAP or other authentication mechanisms:
One caveat for those converting from LDAP or other authentication mechanisms:


* For any user that you wish to authenticate with CAS but which already has been using Moodle, and thus has an entry in the Moodle database, you will need to change the value of the "auth" field for the user in the mdl_user table.  So, if they used LDAP before, but now you wish for them to use CAS and their username is "foobar" you'll need to edit the database with some SQL something like: <code>UPDATE mdl_user SET auth='cas' where auth='ldap' and username='foobar';</code>  Without this change the user will constantly be presented with a failed login message, but otherwise no clue as to why login failed even though their credentials were accepted by the CAS server.
For any user that you wish to authenticate with CAS but which already has been using Moodle, and thus has an entry in the Moodle database, you will need to change the value of the "auth" field for the user in the mdl_user table.  So, if they used LDAP before, but now you wish for them to use CAS and their username is "foobar" you'll need to edit the database with some SQL something like: <code>UPDATE mdl_user SET auth='cas' where auth='ldap' and username='foobar';</code>  Without this change the user will constantly be presented with a failed login message, but otherwise no clue as to why login failed even though their credentials were accepted by the CAS server.


===Setting up regular automatic synchronisation using schedule task===
==Enabling CAS accounts syncronisation==
There is a default scheduled task to synchronize your moodle with a CAS server. The task '''CAS users sync job (\auth_cas\task\sync_task)'''  is responsible for create, update user information, suspend and delete all CAS accounts automatically.
The scheduled task can be enabled and configured on Site Administration > Server > Scheduled tasks by clicking on the gear icon. Select the desired frequency of running and enable the task, un-checking the Disabled checkbox.
It is important, however, to make sure that all of the above CAS settings are working properly before you try this, as well as backing up your database and moodledata folders. Poor CAS configuration could lead to users being wrongly deleted.


{{New features}}The CAS users sync job (''\auth_cas\task\sync_task'') [[Scheduled tasks|scheduled task]] (new in Moodle 3.0; previously there was a CLI script)  is responsible for creating and updating user information, and suspending and deleting CAS accounts.
After enabling CAS server authentication, an administrator need to enable and configure the CAS users sync job as follows:
# Go to ''Site administration > Server > Scheduled tasks'' and click the gear icon opposite CAS users sync job.
# Select the desired frequency of running and enable the task by un-ticking the disabled checkbox.
{{warning|It is important to make sure that all CAS settings are working properly before enabling the CAS users sync job (as well as backing up your database and moodledata folders), since incorrect CAS configuration can result in users being wrongly deleted!}}
==Any questions?==
Please post in the [http://moodle.org/mod/forum/view.php?id=42 Authentication forum] on moodle.org


[[fr:Utiliser un serveur CAS (SSO)]]
[[fr:Utiliser un serveur CAS (SSO)]]
[[de:CAS-Server]]
[[de:CAS-Server]]
[[es:Servidor CAS (SSO)]]
[[es:Servidor CAS (SSO)]]

Revision as of 08:23, 27 November 2015

The Central Authentication Service (CAS) is a single sign-on protocol for the web.

CAS is very beneficial in environments where a number of different web applications share a set of common users. If all the web applications were "CASified" a user would log in once and would then be able to move between the various web applications without ever having to present authentication credentials again. CAS is similar to the Shibboleth authentication mechanism, but it is vastly simpler to set up and lacks a number of broader features like federated trust and authorization infrastructure.

CAS essentially works by configuring a Moodle site to not do authentication itself, but to instead forward unauthenticated users to a CAS server which will then return an authentication token to the Moodle site. Moodle can extract the username from the token and then use its internal authorization mechanisms (roles, enrollments, capabilities) and user attributes (name, picture, etc.). The advantage is that the Moodle site never has to handle passwords and that users, once they've authenticated the first time, can move seamlessly to another web application without having to present their credentials again.

Enabling CAS server authentication

An administrator can enable CAS server authentication as follows:

  1. Go to Site administration > Plugins > Authentication > Manage authentication and click the eye icon opposite CAS server (SSO). When enabled, it will no longer be greyed out.
  2. Click the settings link, configure as required, then click the 'Save changes' button.

One caveat for those converting from LDAP or other authentication mechanisms:

For any user that you wish to authenticate with CAS but which already has been using Moodle, and thus has an entry in the Moodle database, you will need to change the value of the "auth" field for the user in the mdl_user table. So, if they used LDAP before, but now you wish for them to use CAS and their username is "foobar" you'll need to edit the database with some SQL something like: UPDATE mdl_user SET auth='cas' where auth='ldap' and username='foobar'; Without this change the user will constantly be presented with a failed login message, but otherwise no clue as to why login failed even though their credentials were accepted by the CAS server.

Enabling CAS accounts syncronisation

New feature
in Moodle 3.7!
The CAS users sync job (\auth_cas\task\sync_task) scheduled task (new in Moodle 3.0; previously there was a CLI script) is responsible for creating and updating user information, and suspending and deleting CAS accounts.

After enabling CAS server authentication, an administrator need to enable and configure the CAS users sync job as follows:

  1. Go to Site administration > Server > Scheduled tasks and click the gear icon opposite CAS users sync job.
  2. Select the desired frequency of running and enable the task by un-ticking the disabled checkbox.
warning.png Warning: It is important to make sure that all CAS settings are working properly before enabling the CAS users sync job (as well as backing up your database and moodledata folders), since incorrect CAS configuration can result in users being wrongly deleted!

Any questions?

Please post in the Authentication forum on moodle.org