How to Set Up SAML2 SSO for Moodle or Totara

Summary: This guide covers a practical SAML2 SSO setup for Moodle or Totara, including plugin setup, metadata exchange, attribute mapping, testing, and production rollout.

This is the concrete admin procedure for wiring Moodle or Totara to an external SAML2 identity provider such as Active Directory Federation Services, Azure-related SAML setups, or another enterprise IdP.

What you need before starting

• administrator access to Moodle or Totara
• someone on the customer side who can manage the IdP
• the IdP metadata XML file or metadata URL
• a fallback local admin account that does not depend on SSO

Do not begin without the fallback admin account. A mapping mistake can lock you out immediately.

Understand the SAML roles

• Service Provider (SP): Moodle or Totara
• Identity Provider (IdP): the customer authentication system
• Claims / attributes: values such as username, email, or profile identifiers sent by the IdP

If the two sides are not using the same vocabulary, configuration errors tend to appear early.

Step 1: Install and enable the SAML2 plugin

Install the SAML2 authentication plugin and enable it in the authentication manager. Do not disable your local fallback authentication methods during the first setup.

On a production site, this should be tested on staging first wherever possible.

Step 2: Exchange metadata with the customer

The minimum clean setup is:

1. Get the IdP metadata XML or public metadata URL from the customer.
2. Generate or retrieve the SP metadata from Moodle or Totara.
3. Provide the SP metadata back to the customer so they can complete the relying-party or enterprise app configuration.

This step needs to be exact. Wrong certificates, wrong entity IDs, or wrong endpoints will break the login before you reach the user-mapping stage.

Step 3: Configure the SAML2 connection in Moodle or Totara

In the SAML2 plugin settings, configure the IdP metadata and then review:

• entity ID
• SSO endpoint
• certificate
• logout behavior if you plan to use SLO

Do not mix staging and production metadata values. That is one of the most common failure modes.

Step 4: Map the login identifier correctly

This is where many SAML projects fail. Decide which IdP attribute identifies the local account. The SOP explicitly calls out values such as:

• uid
• upn
• objectidentifier

You need the attribute that is stable and matches the local user-matching strategy. Do not guess this based on another customer environment.

Step 5: Map user profile fields intentionally

At minimum, map the attributes you need for:

• username matching
• first name
• last name
• email

If the site uses custom profile fields, map those only when they are genuinely needed. Every extra field is another place for the assertion to drift from your assumptions.

Step 6: Test the login flow on staging first

Before moving to production, test:

• new user creation
• existing user matching
• logout behavior
• role-appropriate access
• fallback admin login

The SOP also references samltest.id as a useful test IdP for troubleshooting. That can help isolate whether the problem is in the plugin configuration or in the customer IdP configuration.

Step 7: Roll out to production carefully

Once staging works, repeat the configuration on production using production metadata only. Keep a fallback login path available until you have completed a real production login test successfully.

Common SAML2 problems

• wrong username attribute mapping
• missing claims in the assertion
• staging metadata used on production
• certificate mismatch
• plugin errors that only appear when a real assertion is processed

If the user reaches the IdP but cannot complete the login, inspect the assertion values before changing random plugin settings.

---

Solin specializes in Moodle and Totara SSO implementations, including SAML2 and enterprise identity integrations. Need help? Contact us.