-
Notifications
You must be signed in to change notification settings - Fork 135
Quick start Guide
This will be a public url which is an xml that allows auto configuration of the IdP from Moodle. It will look something like: https://sso.client.edu/idp/metadata.xml Sometimes there will not be a URL, and instead there is an XML file. This is ok, just copy the whole xml exactly into the same box where the url would go. In some cases, there may be no XML information supplied from the IdP, and there may need to be some reverse engineering to manually construct the XML. This often occurs when they have a home grown IdP.
SP = Service Provider - Moodle. This is available from the saml admin settings page and is the counterpart to above in the other direction. The IdP host will need to ingest this xml into their IdP. Similar to above, a good IdP will accept a url, or it may need the xml manually cut and paste.Other IdPs will need to have the fields in the xml pulled apart and put into their app in some way and may have different names for the fields which don't match up with the SAML language for things.
Once the two metadata xml files are exchanged in both directions, aka 'trust exchange' then SAML itself should be working and it is just minor config to refine at the Moodle application level. The best way to continue from here is acquire test credentials for the IdP and attempt a test login.
There is a 'raw' saml test script which is outside of the Moodle session, it is available at the link below and also linked from the Admin Authentication Management page: auth/saml2/test.php If this fails with a SAML error, then the most common issue is to regenerate the SP certificates and then repeat step 2. If it still fails further debugging is required. The first step would be ramping up the SAML debugging and tailing the logs, but often due to the SAML encryption you will not get meaningful errors on the Moodle side and you will need to look at the logs on the IdP side to see what the issues are.
When you have a raw saml login working it will show you all the attributes returned from the IdP for your test saml user. This is often called 'attribute release'. At the very minimum you will need to be able to see some sort of identifier such as a username, email or internal identifier such as a staff or student number. If you do not see this but the IdP has added it then you may need to tweak the 'nameidpolicy' and 'nameidasattrib' settings. You may also see a bunch of other fields in here such as first name, last name, email, etc depending on what the IdP has 'released'. Use this test page to cut and paste the exact key names in the next steps to avoid subtle typo errors.
The key settings to refine here are 'idpattr' and 'mdlattr' which tells Moodle which saml attribute to look for on the SAML side and which Moodle account field to align it with.
If the user accounts are already present in Moodle, there should be no more mappings to configure. If the plugin is configured to autocreate user accounts from the IdP, mappings will need to be setup. The best idea is to update all fields on login, ie set 'field_updatelocal_firstname' to 'On every login' for all the fields you populate. Often the issue here will be that you want to populate fields with data which isn't in the SAML attributes in step 5. This will need to be fixed at the IdP level to add in all the fields they want. Moodle has limited ability do do anything with these values so they should ideally be ready to go as is.
When setting up autocreate you can repeatedly delete the test user and relogin as them over and over as new fields are setup to ensure its all working. A small cheat you can do to make this faster is just delete the Moodle user but don't logout of the IdP and it should just create it again on the spot when you reload the page.