 My name is Mark Johnson, I am from the Open University, and I'm talking about enabling public access to one of our private VLEs. So, I thought I would have a second screen but I don't, so I'm just getting my notes up. Ok, so at the OU we run several different Moodle sites. We have our main module VLE, which contains all of our main module materials that students use for studying our courses day to day. we have also have a separate site which contains student resources which aren't related to a particular sydd wedi gweld cyfo cyfnod o adredu at gweithrech yn yr uned, mae'r sgwrs yn ei dweud dod o'n gwarn ffordd a'r cyfrifar yr unol y gwir, hynny'n datblygiad ffordd o ffordd o'r ffordd. Felly, mae'n dweud gyrdd y cysyllt yn ddiwedig ar gweithwyr hir yw yma, ac mae'n ddahl iawn i ffordd. Felly, y problem ar y ffordd yma yn ymêmysgu yma ynglyn ail yn yr unfall o'r hoffwn. Mae'n gwneud i gael ddeumau ar y cyfrifar yw yn ei dweithwyr. a gynnwys wedi'i gwneud ei wneud yn gweithio gael y sylwyr syniadau. Felly, mae wnaeth ei bod i'n gwybod yn y sylwyr arbennig, bobl ddim yn meddwl i'n gwybod, a'n gwybod i gael y sylwyr a'r modd, fel yw hefyd yn gweithio ddim yn gweithio, ac mae'n amlwg, mae'n gweithio cyfnodd, maen nhw'n ei gweithio, a gweithio mae'n gweithio am ddwybl yn drwpor, here is throughable, nothing like the vle system that the users are going to be using in the real world. It's not an ideal solution for them to be using that and then have to change into using our actual vle system once they are registered. There is also other resources in the student resources site, which we wanted to make publicly accessible in the future. At the same time as this, we didn't want to make everything on the student resources moodle publicly accessible, Felly mae gydag i ddweud bod rhai o'r ffordd oherwydd y byddai i dda i ddweud o ddweud o'r adegau OU a phoblio i ddweud o'r adegau o'r adegau o'r adegau. Yn gwrthu'n ddechrau, mae gennym ni'n ddweud yr oedd ddweud ddweud o'r ddweud y modl wedi gweld yn lluniau cyfr�ir a'r oedd y cefnod. Y ddweud y llwyddiad sy'n ei fod i'r eich dweud i'r ddweudio'r plugau cyntaf arall. O'r ddweud o'r ddweud o'r llwyddiad cyntaf ar y syniad gyda'r system cyngor. Yr un rhai rhaid yn cael ei wneud i'r ddweud y cyngor ar gyfer y Scymig Llywodraeth, yn cael ei ddweud i'r cyngor ar gyfer y system cyngor, mae'r ddweud i'r cyngor yn cael ei ddweud i'r ddweud. The other one will let you access Moodle but then you'll, basically, you can be redirected from Moodle to the sign in page and Moodle talks to the single sign on system to determine whether you're logged in or not. So we changed the student resources website from using the first method to using the second method. The other thing we did was enable auto-login guests which means that if somebody comes to the website and they are not currently logged in, eu meddwl y bydd o'r buserooll yn eu sowrd. Wrth fy nesb sy'n tu teaseul, all yr ysafodd a'r bwysigai byddai'n meddwl eisiau ond rhaid e无'n rhaid i'r filen. Mae'r buserwyr iaith yw'r bwysig iaith, mae'n meddwl eisiau charlau i'r buserwyr, a felly mae'n meddwl i ddiweddau ysafodd fydd a'r ploedwys ysafodd, i ddoch yn wneud hynny. byddwn i ddweud i ddweud ysafodd, So, we changed the way that we give roles to our users, the users who are actually registered members of the OU, our staff, our tutors and our students, they got a new role called OU user, which was assigned to them by our authentication plug-in. The Sitewide user role still exists, but we took a lot of the capabilities off of that and gave them to the OU user role. So, guests and self-registered users who are public users that have registered an account and logged in, they will get a much smaller set of permissions which let them, they'll let them access activities and resources but they won't let them do anything to them. So, the key here was that we didn't want existing users to lose any permissions which they already had. Some challenges that we faced when trying to implement this, guest users mustn't try and save any data. So, everybody who is accessing using public access is logged in as a guest and that means they all have the same user ID of one. So, if you try and save something against the current user when someone is logged in as a guest, it will also display to all of the other people who are logged in as guests. Fortunately, Moodle's permission system has already thought of this. If you have a capability which is marked as being a right capability when it's defined in the code, that means that if you do a has capability call, it will always come back false. If you're logged in as a guest, which means that it wants to see if you've got the permission to write a new forum post, it'll always say no, even if you've tried to give the guest role that permission. So, that gave us the peace of mind that all of the core code should already handle guest access as we expect it to. We just had to look at our own activity plugins and we had to make a few modifications there to say, well, if it's a guest, don't show them this button, don't show them these links which are specific to your user, and also add some links which will take them to the sign-on register screen for our single sign-on system. This was a combination of when they were trying to access something which we didn't want them to access to when they were logged in, or if they were trying to access a page which might have a feature in it that saves user data, then we'd show them a message like this in place of that feature. Another challenge, if a user self-register is an account, they now have a user ID, so they can save data but they're still members of the public. So, we don't necessarily want them to be, while there's no technical barrier, we don't necessarily want them to be writing stuff on our websites because we have no, they're not one of our students, we haven't had an agreement with them, they're not going to get into trouble and not to get their degree if they start posting nasty things on our webpages. So, basically it's probably advisable not to let these users save data, so essentially by default the site-wide user role can't post things, can't write data anywhere, but in the cases where we want this to be able to happen, that's managed with permission overrides on a case-by-case basis, so that might be on a particular website or particular activities, they can be set up with these permissions. Another challenge, this proved to be a slightly more scary one than we thought. Previously, this server wasn't really accessible on the internet, you tried to go to it, you got a login page, if a bot tried to go to it, the bot got a login page. So, we needed approval from our information security team to make this change. The reason this is a problem is basically this gives us a greater exposure to risk for malicious actors on the internet. It turns out actually what we're doing isn't really any different to what we already do with Open Learn and the Open Science Lab, but when you talk to your Infosec team and you say, well, we've actually been doing this for years, but you just didn't notice, that doesn't go down so well. So, we've taken three steps to reduce the risk. First of all, we had our information security team run an automated vulnerability scan against our system. This is essentially what any malicious attacker on the internet will do. They'll be running a tool which is hitting our server, looking for common vulnerabilities. So, before we made it accessible for people to do that, we did it ourselves and fixed any vulnerabilities we found. There was one and it was very small. We also took some inspiration from the way that we've locked down the prison VLE. That has a whitelist of pages which are accessible to users. So, in this case, we have a whitelist of pages which is accessible to public users. This just reduces the surface area for attacks. So, if you try and access, say an admin page, you'll just get an error. It will never run any of the PHP for the admin page. This basically protects us from any as-yet-undiscovered vulnerabilities either in the Moodle code or in our own plugins. Finally, we're having a full third-party penetration test of our VLE systems to identify any further security flaws which we might need to worry about. That's all I had to say. Any questions? Questions? I should probably know this and I don't know if you can say publicly what was the small vulnerability we found? I think we were displaying a URL on an error page without sanitising it. So, it was a possible injection attack, but only on IE, I think, because all the other browsers noticed and didn't do something horrible. Thanks. I should also add that since I wrote this slide, we discovered another challenge which is that because of the way that we implemented our single sign-on system, we had to go back and change some of the integrations because things happened like if you logged out of our single sign-on system and then logged back in, you didn't actually have a Moodle session yet. This is because I think our single sign-on system probably works a bit differently to the way that Moodle is expecting it to. It actually sits sort of at the web server level rather than sitting alongside Moodle. Cool. Thanks very much.