We just achieved a small but efficient SSO layer in a full open Moodle Network. A "full open" Moodle Network is a set of moodle connected together in which multiple hops are allowed. In such a network, a user is always known as its username/origjn_mnethostid information pair.
Achieveing this was done by delegating the MNET session jumping to the origin host of the user, when he tries to jump from another node in the network. (Works perfectly, but will need some side effect fix on reports, as Nigel McNie suspected).
I finished the design of a new Auth plugin, that allows SSOing any user of the network, this very simple plusing does the following :
- Capturing (must be set very high in the auth stack) the username/password submission, using login_page_hook loop at start of login/index.php
- Applying an heuristic over the username syntax to check for a probable origin host. (this works fairly well when a moodle node is mapped adminsitratively to an email domain, and the username is the email address).
- Building a redirection to the remote login/index.php, with a required URL that points back the local landing page. (the effect is that the user is actually login on his own origin node, but requiring immediately a jump to where he was supposing going first !!)
- Execute the redirection
If none of the above works, the auth plugin let go through to try a local login (or other pethods in the stack).
The process is completely compatible with a backside LDAP authentication (so we are making it work) and encrypts the login delegation for security, making an SSO ticket encrypted stub with identification data in it (using registered Mnet keys).
I need some feedback upon possible security issues or something to care at that I might have not thought about. Thanks everyone.
The "multimnet" auth plugin is candidate for public publication.
Cheers.
I presume your heuristic was necessary because users could come to any one of the nodes to log in for the first time?
What are the details behind the heuristic? It sounds like you're using username to infer which MNET peer has that user. This almost sounds like a question you'd want to ask each peer in turn - as long as you knew that usernames were unique across your entire set of MNET peers, which is unlikely I guess. This is the reason why Mahara won't let Moodle users necessarily create their accounts on the Mahara side until they've SSOed over - so we know for sure that 'bob' from Moodle 1 == 'bob' in Mahara, while 'bob' in Moodle 2 == 'bob1' in Mahara.
Hi Nigel,
Actually you're right. The Multinode MNET SSO relies on a consistant naming of usernames in all the Network.
We have this kind of control in our 35 Moodle nodes for Pairformance/Intel's TAO implementation. We do not allow having similar usernames, or these users will have a special username form that jumps out of our heuristic (and thus try the default, or just try a local login).
This would actually NOT BE suitable to a multi-institution network that have no consistant policy on user acocunt creation.
Dealing with institutional email address, we could force having a consistant namespace for all our users, and having an exception handling for some very special cases (eg. admin !! or external guests...)
The routing is perfect, in both cases !!
The heuristic requires depositing a REGEX to apply to usernames. This is a very simple approach, and might be extended on use case requests.
say we have a username that is : alain.bolli@ac-libourne.fr (I'm sorry Alain, but the town is bullshit, so no span to fear !!). The regex is : .*@(.*)\.fr that collects the "ac-libourne")
Can alos be entered in the auth plugin settings a replacable pattern to use this recollection back :
<%%HOSTNAME%%>.pairformance.education.fr wich is that actual naming sheme for all the nodes... and guess Alain comes from ac-libourne.pairformance.education.fr !!
I'm sure it could be made to work where usernames aren't controlled too, though it would require some way of peers informing one another about usernames. I guess you don't care about that though for your work
