Remote user bounce limitation

Remote user bounce limitation

Valery Fremaux -
Колькасьць адказаў: 14

I'm tuning a 40 x Moodle network that need complete transparency of roaming from any of the users.

I fall over this (understandable but limitative) restriction that a remote user cannot roam again to another site of the network. As we disabled this limitation (auth/mnet/auth.php function start_jump_session()) we get the open distributed moodle we wanted to.

I suggest this should be restricted by an additional capability, or a system wide mnet configuration var.

I didn't followed all tracks for consequences of this (possible origin identity mismatch when bouncing to next moodle in the path and cloning account).

Cheers.

Сярэдняе рэйтынгаў: -
У адказ на Valery Fremaux

Re: Remote user bounce limitation

Nigel McNie -
There are a few significant negative consequences of allowing MNET users to roam again. They mostly center around the fact that you'll quickly end up with many duplicate accounts for users, depending on which host they enter another host from.

Example: Let's say you have just four moodles in your network: Moodle 1, 2, 3 and 4. And for simplicity, let's assume that users only ever get accounts on Moodle 1 initially.

When a user roams from Moodle 1 to Moodle 2, they will get an account there. This account will be marked as having come from Moodle 1 (mnethostid column of user table). Likewise, the user roaming from Moodle 1 to 3 will have the same effect.

Now if this user roams from Moodle 2 to 3, they will not be put in the same account as if they had roamed from Moodle 1 to 3. Instead, a new account will be created for them associated with Moodle 2. And if they roam from 3 back to Moodle 1, yet another account will be created for them.

You can see the problem I hope - soon there are many accounts on all the Moodles, all associated with this one user, and you're unable to get to them except by browsing through the Moodle Network in the explicit path it took t create them. This problem gets worse with having more Moodles, and worse again if users can initially sign up at more than one Moodle.

Until someone traces through all the consequences and works out a solution, it doesn't make sense for now to even make this configurable.
Сярэдняе рэйтынгаў: -
У адказ на Nigel McNie

Re: Remote user bounce limitation

Valery Fremaux -

Thanks Nigel.

I was gathering something like this, as I already saw some duples in our test system.

As it is a "mandatory" requirement in our architecture. I'm up to find a turn around for that.

My idea is to find the location to keep the "origin" of the account safe through any bounce. Of course this will require that the "origin" mnet_host is registered in the landing location, so a valid mnethostid can be found for this incoming user.

In this case we should keep a unique identity of a user across all our moodles, as long as he has a unique entry point that he will capture as origin. 

In case we have no registered host for him, there would be a real issue to take the incoming host as reference. This would break again identity unicity and present a risk of duplication : say A -> B and C, B and C -> D, user a from A comming to B and registered as a::A, a comming to C registered as a::A, a comming to D through B registered as a::B, a::A comming to D through C would want to register as a::C. That not fits. So would we reject registration in this case.

There is another turn around in our case : as we have a unique "username" scheme, it would be easy to disable mnet_host caracterization on auth/mnet/auth.php§start_jump_session() so we default mnethostid to the first identified mnet_host for that username.  

I still wonder what is the simpler to code...

Сярэдняе рэйтынгаў: -
У адказ на Valery Fremaux

Re: Remote user bounce limitation

Nigel McNie -
We dealt with a similar problem for Mahara - because we knew usernames were unique, we added a new mode, 'usersuniquebyusername'. That meant that we only looked for user accounts to use for a user based on their username, not on both their username _and_ where they came from.

This opens up potential security issues - you have to make sure it is impossible for a user to register at any of the Moodles using another username, else they gain access to that user's account. In Mahara we solved this by refusing to allow registration - users have to be authenticatable by an external data source. Not sure if that will work for you, but it's an idea.
Сярэдняе рэйтынгаў: -
У адказ на Nigel McNie

Re: Remote user bounce limitation

Valery Fremaux -

It is more and less the situation we have, as manual registering is disabled everywhere. Quite all our moodles are bound to an LDAP source. We should not create any account in our system, unless a small set of users on a single platform. It should work.

I have looked for adding propagation of origin identity when roaming. It seems not be so hard to do, as it just involves jump.php, land.php and both functions start_jum_session() and confirm_mnet_session(). It seem we can do it just there.

Cheers.  

Сярэдняе рэйтынгаў: -
У адказ на Valery Fremaux

Re: Remote user bounce limitation

Nigel McNie -
Sounds like you can make it work - it might be interesting for Moodle upstream too? wink
Сярэдняе рэйтынгаў: -
У адказ на Nigel McNie

Re: Remote user bounce limitation

Valery Fremaux -

May be.

I'm just finishing an automatic key renewal cron hook and I promise I spend some hours on it.

Cheers.

Сярэдняе рэйтынгаў: -
У адказ на Valery Fremaux

Re: Remote user bounce limitation

David Sturrock -

Hi Valery

Assuming the technical issues are solvable падморгваньне how would the user experience this roaming ability?

  1. Would they always have to login on their "home" Moodle? Without knowing how your Moodles are distributed would there be potential for any confusion around this?
  2. Do you envision users being able to roam across the network freely or will you be controlling the courses they access via some automated enrolment process?
  3. Do you expect to have their home Moodle Themes follow them through the network or will they just see each sites theme? There are implications for how networked users access support services etc that we have used theming to solve in our own mnet project.
  4. Also interested in what makes Moodle networking a better solution than some federated identity/access management system like Shibboleth?

Cheers
David

Сярэдняе рэйтынгаў: -
У адказ на David Sturrock

Re: Remote user bounce limitation

Nigel McNie -
David, for your reference I have been having a separate conversation with Valery, and one thing that came out of that is that people probably will need to log in at their home moodle, and always be bounced through their home moodle to get from host to host - otherwise the activity logs won't be sent back to the right place (among other issues).
Сярэдняе рэйтынгаў: -
У адказ на Nigel McNie

Re: Remote user bounce limitation

Valery Fremaux -

David, Nigel,

Answers for you two :

The roaming mechanism is now completed and runs nicely using a transparent "base jumping" from the origin site of the user. Logs are preserved that way and I tested a quite fluid circulation of the user across the network, keeping its origin identity safe all along the path.

 The benefit of such architecture is that :

  • we can twick the whole semantics of the platform GUI in some zones differently so sections of the "global platform" can come further to users contextual needs.
  • we can segmentate the whole space within smaller zones, fo witch we have a complete front page with segmentated summary.
  • we can spread a huge user base (400.000 foreseen in 2011) on separate satellites, having a small set of users who will be enclined to roam (or will have to) so we keep user table and other very central tables smaller.
  • we can make local adapations in theming and propose several "worlds" to our users. These could have been achieved partially with category theming, but not with a full home appearance.

We don't use user themes here indeed. It is a very tighen project where we keep full control on design, so there is no theme roaming issue.

About the ability of loging in from everywhere (any door ?). I'm thinking about it, because of better user convenience. As the entire platform appears as a set of distinct base URLs, it should be better we can log a user at any door.

What I plan is to allow any user THAT HAS ROAMED ONCE to log from that door, so we already know his username and his origin mnethostid. It is easy for us to allow him transparently get a suitable session there and bring him back to the starting platform. We cannot do that with completely "unknown" users, so we would redirect them to their origin entry point.

Сярэдняе рэйтынгаў: -
У адказ на Valery Fremaux

Re: Remote user bounce limitation

Nigel McNie -
Without commenting on any other aspect of your mechanism, your last paragraph is interesting - I'm not sure how you imagine that working, don't forget that at the remote host there could be a local user with the username - then how do you know who is to log in when you get a log in request from that username?
Сярэдняе рэйтынгаў: -
У адказ на Valery Fremaux

Re: Remote user bounce limitation

Hubert Chathi -
I know this is an older thread, but for the record, simply disabling the check in auth/mnet/auth.php:start_jump_session() opens up a rather serious security issue, due to the way Moodle Networks identifies users. Multiple bounces would require changes to, at least, the sso_idp API. I have ideas for how to change it, but I'm not sure if it's worth pursuing unless other people are interested.

Valery: is your "base jumping" code available anywhere?
Сярэдняе рэйтынгаў: -
У адказ на Hubert Chathi

Re: Remote user bounce limitation

Valery Fremaux -
Hi Hubert,

actually not published yet, but we are experimenting a 40 x 40 Moodle grid full networked without many troubles.

Actually the changes we made on mnet code is not so important. I may try to make a diff with standard 19_STABLE code to give you a view.

We added to the project a "multinet" auth layer that allows "login from everywhere" behaviour (almost MNET internal SSO behaviour). Works nice and we could spread our potentially 1,400,000 accounts across the 40 Moodle grid.

Actually security has been addressed and I reinforced the check of origin of the users as counterpart of the networking opening. We essentially "base jump" within a trusted moodle network, in which foreign instances might not connect unless the interconnection strongly reviewed.

As Nigel said, there is still some weaknesses in reports, specially dealing with foreign stats from other nodes of the network. This is not a mandatory point in our project, as we are plugin a full external BI/Datamining reporting suite to our Moodle grid.

Cheers.
Сярэдняе рэйтынгаў: -