SSO based on several user fields for ID

[fbuland]

Hi,

Several schools would like to use the same instance of Moodle for shared courses. But:

• Each school has his own Student Information System (SIS) and his own IdP
• A federated IdP with Shibboleth, which redirect to IdP of each school
• Students may be enrolled in several schools, but they are in the SIS of each school (specific ID, username and password), with no unique ID between schools
• So no unique ID in the federated IdP
• So for SSO, when he comes from a specific school, the federated IdP redirects him to the IdP of this school

Schools may find a rule to create a unique user ID in Moodle, but they would also need to provide for each user the ID in each school the user belongs to for the authentication process.

I'm wondering if it does make sense and if it can be added to this plugin. Thanks in advance for your feedbacks.

Kind regards, Franck

[brendanheywood]

It probably doesn't make sense to have this in this plugin, this really needs to be in the federated IdP. After all it is the system responsible for merging the combined user spaces from the real IdP's so it should be the central point of truth which creates the unique Id across them and provides it to moodle (and presumably other systems too). This could be as simple as an email, or whatever convention you want. This can then be communicated back to moodle as a unique username and in additional you could also pass back any other fields you want, eg you could set the 'Institution' user profile field in moodle based on a saml attribute that the Shib provides based on which end Idp / SIS was used. Note that the username moodle sees does not have the be the username the student typed into their schools Idp login page, so for example they could type in 'brendan' + password into the login.school1.edu.au idp but then the shib idp tells moodle that their username is "brendan@school1.edu.au" (this looks like an email but isn't and could be any namespaced convention) and their Institution is "School 1"

If a particular student can be enrolled in two schools but you want them to be a single user in moodle then the Shib idp needs to be aware of this and have deterministic rules for how to resolve the duplicates.

[fbuland]

@brendanheywood, I agree with you. But the reality is not so simple, because it will take several years to evolve toward a unique ID in IdP federation. In France, it will be the case for several federation of schools who are starting to grouping together.

A first evolution is to support multiple IdP from metadata and let the user choose the school where to authenticate (I believe SimpleSAML can manage that). Cf. issue 5: Potential for multiple IdPs

The second evolution would be to manage several IdP IDs for users. A possible solution:

1. Create a new field on customer profile for each ID specific to IdP to store : ok with Moodle GUI
2. Create a mapping between previous fields and IdP : in plugin
3. Find the user search on previous corresponding field

What do you think of that ?

[brendanheywood]

If you go down the path of #5 then that could work, but then you are also duplicating the logic contained in the central shib instance, and I assume in this architecture that you would remove shibboleth completely from the equation. Yes that could work, and if you want to sponsor #5 that's one solution. But I think it's a bad workaround solution.

But the reality is not so simple, because it will take several years to evolve toward a unique ID in IdP federation. In France, it will be the case for several federation of schools who are starting to grouping together.

You don't need a unique login ID across the federation, ie you don't need all the schools to agree to have a common sign on, and indeed the various federations I've worked with around the world generally don't do this either. All you are doing is configuring shibboleth to generate a globally unique ID based on the user id they get from each upstream Idp combined with some sort of domain identifier. By convention this is almost always the users email which is already unique. Shib can definitely do this and the schools do not even need to be aware of this. If the users don't have an email tied to their schools domain then something superficially like an email will suffice. This is by far a much better architecture than a bandaid solution inside moodle itself, I can only assume that there would be other applications also leveraging shib which could / should also leverage the same unique id. If you are worried about this new unique ID being used for other purposes outside of moodle, then you can set up shib to only release that attribute to moodle, so you are free to evolve it without messing with other apps using shib.

One issue with implementing and using #5 could be that each school's IdP might be setup differently and release different attributes etc. I doubt that #5 would ever expose the full power of SimpleSamlPHP and it would make a lot of assumptions to keep it simple. Another solution could be to have a SSPHP instance between moodle and the various school IdP's, but this too is also effectively just replacing your Shib instance.

So really I don't think you need a moodle plugin change, I think you just need a Shib expert to create that mapping configuration. If you were using SSPHP as your federated Idp we could definitely help out, I'm just not sure what Shib expertise we have internally but if you are interested I could check.

If you don't mind could you open up in your moodle /auth/saml2/tester.php and this will do a raw saml authentication outside of moodle and just dump the attributes it got. If you can dump that here it would help frame this discussion a fair bit (redact bits if you need). If you could give two examples from different schools that would be even better

[fbuland]

@brendanheywood, sorry for the delay, we had more analyze the situation. Actually, I discovered there is no Shibboleth for the federation of identities, only a mutual engagement and technical framework to automatically manage metadata. A unique ID for each user need to be added. We agree with you, it should not be added to this plugin.

One issue with implementing and using #5 could be that each school's IdP might be setup differently and release different attributes etc.

In our case, a set of common attributes is defined in the federation.

I will writte directly on #5 for enhancements we need and we can sponsor.