Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
en:2.0:single_sign_on:saml_moodle [2025/05/16 23:58] – [Configuring the Service Provider (Moodle)] kainhoferen:2.0:single_sign_on:saml_moodle [2026/09/05 00:31] (current) – [Quick Overview] kainhofer
Line 12: Line 12:
 Throughout the document we will assume you have both Admidio and Moodle already set up properly at https://admidio.local/ and https://moodle.local/. Please modify these URLs to your actual installation. Throughout the document we will assume you have both Admidio and Moodle already set up properly at https://admidio.local/ and https://moodle.local/. Please modify these URLs to your actual installation.
    
-As a first step, one needs to **configure Admidio to act as an SAML 2.0 Identity Provider** (IdP). This has to be done once and is not specific to any client. Please follow this guide: [[en:2.0:single_sign_on|#a_basic_setup_for_admidio_as_a_saml_id_provider]]+ 
 +As a first step, one needs to **configure Admidio to act as an SAML 2.0 Identity Provider** (IdP). This has to be done once and is not specific to Moodle. Please  [[en:2.0:single_sign_on#a_basic_setup_for_admidio_as_a_saml_id_provider|follow this guide]]. 
 {{ :en:2.0:sso:sso_saml_01-05_setup_admidio_preferences.png?direct&600 |}} {{ :en:2.0:sso:sso_saml_01-05_setup_admidio_preferences.png?direct&600 |}}
  
-Basically, one (1) needs to **create a cryptographic key** to sign message and **choose a unique EntityID**. +Basically, one needs to enable SAML 2.0 and **choose a unique EntityID**. 
-The page preferences https://admidio.local/modules/preferences.php?panel=sso also provides the link to the metadata xml, and the individual settings in case a client does not support auto-configuration via metadata.+ 
 +The page https://admidio.local/adm_program/modules/preferences.php?panel=sso provides the link to the metadata xml, and the individual settings in case a client does not support auto-configuration via metadata.
  
 ===== Quick Overview ===== ===== Quick Overview =====
  
-Setting up a client (SAML "Service Provider" - short SP) to use Admidio's user accounts for logging in consists of two steps. If both the IdP (Admidio in our case) and the SP (Moodle in this document) support metadata loading, the setup is very straightforward and easy. Otherwise, one has to copy URLs manually to the client, but Admidio already provides these in a single place, so this situation is not as bad, either.+Setting up a client (SAML "Service Provider" = "SP") to use Admidio's user accounts for log-in consists of two steps. If both the IdP (Admidio in our case) and the SP (Moodle in this document) support metadata loading, the setup is very straightforward and easy. Otherwise, one has to copy URLs manually to the client, but Admidio already provides these in a single place, so this case is also straightforward.
  
   * At the **Service Provider (SP)** - Moodle in our case - **install the extension** to support SAML login.   * At the **Service Provider (SP)** - Moodle in our case - **install the extension** to support SAML login.
-  * Configure it either with Admidio's **XML metadata file**, or enter the EntityID, the Single-Sign-On Endpoint, the SLO Endpoint and the public certificate manually (Admidio provides a simple table to copy these values from).+  * Configure it either with Admidio's link to the **metadata file**, or enter the EntityID, the Single-Sign-On Endpoint, the SLO Endpoint and the public certificate manually (Admidio provides a simple table to copy these values from).
   * Choose whether sent messages **should be signed and/or encrypted** (these features require an additional private key and certificate for the SP!), and whether received messages are checked for signatures or encryption is expected.    * Choose whether sent messages **should be signed and/or encrypted** (these features require an additional private key and certificate for the SP!), and whether received messages are checked for signatures or encryption is expected. 
   * In **Admidio**, **create a new SAML client**. If the SP provides a **metadata URL**, paste it and let Admidio automatically load the configuration from the SP. One can also manually paste these settings.   * In **Admidio**, **create a new SAML client**. If the SP provides a **metadata URL**, paste it and let Admidio automatically load the configuration from the SP. One can also manually paste these settings.
-    * Choose an easily understood **label for the client** (only used in Admidio's list of clients, but has no technical use)+    * Choose an easily understood **label for the client** (only used in Admidio's list of clients as visual identifier, but has no technical use)
     * Enter the **ClientID from the SP**, as well as the ACS URL and the SLO response URL. These values must be provided by the client.     * Enter the **ClientID from the SP**, as well as the ACS URL and the SLO response URL. These values must be provided by the client.
   * In Admidio, also choose whether sent messages should be **signed or encrypted**. The crypto key generated in the general SAML setup will be used.   * In Admidio, also choose whether sent messages should be **signed or encrypted**. The crypto key generated in the general SAML setup will be used.
Line 77: Line 80:
  
 Towards the end of the configuration screen, a whole section "Data mapping" is dedicated to fields mapping. Each profile field has four settings: "Data mapping" (SAML attribute from Admidio), "Update local", "Update external" and "Lock value". None of these values is required, but if they are mapped, Admidio's profile data is properly imported into Moodle's profile. Towards the end of the configuration screen, a whole section "Data mapping" is dedicated to fields mapping. Each profile field has four settings: "Data mapping" (SAML attribute from Admidio), "Update local", "Update external" and "Lock value". None of these values is required, but if they are mapped, Admidio's profile data is properly imported into Moodle's profile.
-{{ :en:2.0:sso:sso_moodle_saml_09_plugin_settings_mapping.png?direct&800 |}}+{{ :en:2.0:sso:sso_moodle_saml_09_plugin_settings_mapping.png?direct&900 |}}
  
  
  
 The last section would allow Moodle to act as a SAML IdP, which is not relevant in our case. Enabling IDP means that Moodle's user accounts can be used by other applications. This, however, is not our scope in this tutorial. The last section would allow Moodle to act as a SAML IdP, which is not relevant in our case. Enabling IDP means that Moodle's user accounts can be used by other applications. This, however, is not our scope in this tutorial.
-{{ :en:2.0:sso:sso_moodle_saml_10_plugin_idp.png?direct&200 |}}+{{ :en:2.0:sso:sso_moodle_saml_10_plugin_idp.png?direct&600 |}}
  
  
Line 89: Line 92:
  
 Admidio and Moodle should now be set up to use Admidio for logging in to Moodle. The SAML plugin even provides a way to test the plugin configuration: Return to Moodle's plugin list (see above), which shows a "Test settings" next to the "Settings" link for the plugin: Admidio and Moodle should now be set up to use Admidio for logging in to Moodle. The SAML plugin even provides a way to test the plugin configuration: Return to Moodle's plugin list (see above), which shows a "Test settings" next to the "Settings" link for the plugin:
-{{ :en:2.0:sso:sso_moodle_03_pluginlist.png?direct&400 |}}+{{ :en:2.0:sso:sso_moodle_03_pluginlist.png?direct&600 |}}
  
 The test settings page allows a test login from Moodle to Admidio without influencing the current session Moodle. If login is successful, the profile data provided by Admidio is displayed. The test settings page allows a test login from Moodle to Admidio without influencing the current session Moodle. If login is successful, the profile data provided by Admidio is displayed.
-{{:en:2.0:sso:sso_moodle_saml_11_plugin_test.png?direct&600|}}{{:en:2.0:sso:sso_moodle_saml_12_plugin_testresults.png?direct&200|}}+ 
 +{{:en:2.0:sso:sso_moodle_saml_11_plugin_test.png?direct&600|}}{{:en:2.0:sso:sso_moodle_saml_12_plugin_testresults.png?direct&400|}}
  
 Once, this dry run is successful, one can attempt a real login through SAML. Once, this dry run is successful, one can attempt a real login through SAML.
Line 98: Line 102:
  
 If you log out of Moodle (or open Moodle in an incognito browser window) and go to the Moodle admin location, you should see the login screen with the choice of logging in with password or via SAML. If you log out of Moodle (or open Moodle in an incognito browser window) and go to the Moodle admin location, you should see the login screen with the choice of logging in with password or via SAML.
 +
 {{:en:2.0:sso:sso_moodle_13_moodle_loginform.png?direct&400|}}{{:en:2.0:sso:sso_moodle_saml_14_admidio_loginform.png?direct&400|}} {{:en:2.0:sso:sso_moodle_13_moodle_loginform.png?direct&400|}}{{:en:2.0:sso:sso_moodle_saml_14_admidio_loginform.png?direct&400|}}
  
  
 After choosing SAML login and loggin in with a user from Admidio, you should be logged in to Moodle. After choosing SAML login and loggin in with a user from Admidio, you should be logged in to Moodle.
-{{ :en:2.0:sso:sso_moodle_saml_16_loginsuccess.png?direct&400 |}}+{{ :en:2.0:sso:sso_moodle_saml_16_loginsuccess.png?direct&600 |}}
  
  
Line 108: Line 113:
 ==== Caveats and Things to Consider ==== ==== Caveats and Things to Consider ====
  
-  * Transferring the country profile field from Admidio into Moodle's country field does not work, because Moodle appears to expect a particular format, which Admidio does not provide. The error message might look overwhelming, but it gives a good indication.{{ :en:2.0:sso:sso_moodle_saml_99_countrymapping.png?direct&400 |}} +  * Transferring the country profile field from Admidio into Moodle's country field does not work, because Moodle appears to expect a particular format, which Admidio does not provide. The error message might look overwhelming, but it gives a good indication.{{ :en:2.0:sso:sso_moodle_saml_99_countrymapping.png?direct&600 |}} 
-  * If you have user accounts from different backends (e.g. local accounts, OpenID Connect login, SAML login) and an account for a user was already created, Moodle tries to match accounts by username (the field selected in the plugin config). However, if the other account has the same email address, but a different user ID through the OIDC or local backend, Moodle will try to create a new account with the SAML user ID, but fails since another account with the same email already exists.{{ :en:2.0:sso:sso_moodle_saml_15_login_duplicateemail.png?direct&400 |}}+  * If you have user accounts from different backends (e.g. local accounts, OpenID Connect login, SAML login) and an account for a user was already created, Moodle tries to match accounts by username (the field selected in the plugin config). However, if the other account has the same email address, but a different user ID through the OIDC or local backend, Moodle will try to create a new account with the SAML user ID, but fails since another account with the same email already exists.{{ :en:2.0:sso:sso_moodle_saml_15_login_duplicateemail.png?direct&600 |}}
  • en/2.0/single_sign_on/saml_moodle.1747432703.txt.gz
  • Last modified: 2025/05/16 23:58
  • by kainhofer