JISC DVLE meeting

The W2C team headed off to Bolton for a meeting with sister projects in the JISC’s Distributed Virtual Learning Environment Programme. The morning provided an opportunity to hear what each project was working on. I failed to do justice to W2C in the 2 minutes allowed, but the slides used for my summary appear below.

I was struck by potential synergies with other projects (for instance Glasgow Met’s interest in communicating marks to Moodle and the OU’s interest in surfacing Moodle content in other places). Plenty to follow up!

Ross, Scott and Wilbert then gave neat summaries of Open Social, Wookie and IMS Basic LTI, and we got the chance to follow up our specific widget questions:

  • W2C: Is it possible to get the authenticated userId and Moodle courseId from the Moodle widget container?
    Scott: Yes
    W2C: Hurray!
  • W2C: Is it possible to devise a mechanism for distributing to widgets configuration data necessary to generate web-service authentication tokens without creating a security hole that could allow one user to read another’s details?
    Scott: the Moodle plug-in running the widget could hold the shared secret used for token generation and configure the widget properties on instantiation
    W2C: is it possible to do something similar for students who download widgets to their mobile?
    Scott: you could run a widget store that allocates a personalised token when the user registers to download the widget
    W2C: …. hmm … that sparks some ideas …

Some Security, Privacy and Authentication Ideas

W2C is developing a suite of web-services that will allow students to gain access to data about them and their studies, such as a personalised timetable, a personalised assignment hand-in schedule and preliminary marks. These web-services will need to be called with a student identifier in order to return data relevant to a particular student.

As a first principle of privacy those web-services should return no more data identifying the person than that already supplied. A personal timetable web-service called with a userID would not, therefore, return the name of the person for whom the timetable was generated.

Our current thinking on these web-services is that they will use an impersonation account that has sufficient privileges to return data on any student id they are called with, so another mechanism is needed to ensure that the call is from a trusted source. A common method of proving that the call is from a trusted source is to use a shared secret, known only by the server and trusted clients, to generate an authentication token which is supplied to prove the web-service call is legitimate. The authentication token is typically a one-way hash so the shared secret is never transferred over the wire. However, the client needs access to the shared secret in order to generate the authentication token.

MMU currently uses the shared secret/token generation approach to allow WebParts in SharePoint to make trusted calls to web-services to access personalised WebCT announcements with pre-authenticated single-sign-on links to a user’s WebCT areas. The shared secret (which is used to generate authentication tokens for any user) is stored in the WebPart’s configuration parameters and is therefore not visible to users.

W2C plans to use widgets running in Moodle to call institutional web-services for details of timetables, hand-ins, reading lists and marks. We understand from Scott’s answer that the Moodle plug-in for running the widgets can perform the same function as the SharePoint WebPart container and distribute the shared secret for the widget to use.

Distributing a shared secret that would work for any user should work well in Moodle as the shared secret would not be visible to users. However, the approach would not work if the widget were to be used outside the Moodle container (for instance on a student’s mobile device) as the shared secret used to generate tokens must be known wherever the widget runs; the transparent nature of the widget code would make it trivial to work out how to call the web-service for a different user. A variation on the approach is therefore needed which issues user-specific shared secrets to widgets so they can generate authentication tokens to make trusted calls to institutional web-services.

If a widget’s configuration parameters can be instantiated by the container on initialisation and the widget container has access to the ID of the user for whom the widget is being initialised, then we have a mechanism for generating these user-specific shared secrets. The approach would be as follows:

  1. Moodle Widget Container is supplied with a secret word (eg “bolton”) known to it and the web-services to be called
  2. Moodle Widget Container receives a request to instantiate a widget for the current user (eg “55500555”)
  3. Moodle Widget Container appends the shared secret to the user id (“5550055bolton”) and performs an MD5 hash to generate a personalised secret word (“6653e1e33cb96c21f19c53ad62330371”) which it makes available in the widget’s configuration preferences
  4. Widget appends the secret word from its configuration preferences to the user ID (“55500556653e1e33cb96c21f19c53ad62330371”) and performs an MD5 hash to generate an authentication token (“8d04021352a1a78ebab989ce5bee77d9”) which it uses to call a web-service to get a list of preliminary marks
  5. Web-service receives the request, appends the shared secret (“bolton”) to the person parameter (“55500555”) to produce “55500555bolton” and generates an MD5 hash from it (“6653e1e33cb96c21f19c53ad62330371”) which it appends to the user ID and generates a further MD5 hash (“8d04021352a1a78ebab989ce5bee77d9”) which it compares against the supplied token. They match, so the web-service returns the preliminary marks for that user.

So far this approach hasn’t given us anything over the approach we were using before, but if we create a widget store that has a registration mechanism that requires students to supply their userID to download a widget for use on their mobile, then the widget store will ideally pre-configure the widget preferences with the user-specific token for download. User 55500555 will therefore receive a widget pre-configured with userID “55500555” and secret word “6653e1e33cb96c21f19c53ad62330371” that will be used in the javascript to generate the token for calling the getMarks web-service.

OK, so what about the privacy holes that were worrying us before?

  • Someone intercepts the REST call to the web-service and tries to use the token with a different userID (“88800888”), eg getMarks?person=88800888&token=8d04021352a1a78ebab989ce5bee77d9
    Outcome: code for generating the token values in the web-service does an MD5 hash on “8880088bolton” to give “ada366a302275b46ccb34181d5afd4d6” which it appends to the person ID and does a further hash to give “a6ba82a8497026787a5b9ea96f515152” which doesn’t match the supplied token so the request is refused
  • Someone downloads the widget and changes the preferences file to try to access another student’s marks (say 88800888)
    Outcome: the widget appends the token from the preferences file to the supplied user id (“888008886653e1e33cb96c21f19c53ad62330371”) to generate the MD5 hash (“ec662ff5a55b5c8920163c7e3ecda9b5”) which it supplies to the getMarks web-service. The getMarks web-service generates its token value based on “88800888bolton” as above which fails to match the supplied to token so the request is refused

I suspect I need to think about this some more (ideally with your help), but if there isn’t a flaw in the thinking set out above (and *please* use the comments feature to tell me if there is!), and if the Moodle Widget Container can set widget configuration parameters dynamically, and if it is possible to create a widget app store that can customise widget configuration parameters based on user registration, then we might have the basis for a workable approach and it will have been worth getting soaked in Bolton today!