Storing credentials against each assignment instance makes it difficult to rotate keys

[sarahjcotton]

It feels as though the storage of credentials could be better managed for this plugin.

If credentials are compromised and the keys need to be rotated, having them set against each instance makes it very difficult to update them. I understand the plugin is designed to be used with multiple instance of Mahara, but multiple sites could still be configured at site level and the user simply given a drop-down in the assignment instance to pick which one they wish to use, similar to the way the old plugin works.

If the credentials need updating it would then be much easier to action a change this way.

[anitsirk]

Great idea, @sarahjcotton. Happy for you to write up some specs of how you envisage this to work so we can discuss it and include whether it should also still be possible to manually add credentials in an assignment to be more flexible (I think it should as that makes testing easier and is possible for other LTI setups as well). I think one problem we have right now is that when you add credentials on the site level you can still seemingly overwrite them in an activity but upon saving the site credentials are taken again.

[danmarsden]

@sarahjcotton yes - definitely worth doing and I had similar thoughts when I looked at this a while back too - I even went as far as dropping some code in #45 to tidy up the forced config a bit too but never managed to test that to see if it made much of a difference.

[sarahjcotton]

Hi @danmarsden and @anitsirk

Thanks so much for your input on this. Some initial thoughts on how this could work to kick off discussions are as follows:

Config

• Multiple Mahara instances configurable at site level only - in my view, ease of testing should not take precedence over security.
• Site instances should not be able to deleted if associated with an assignment, but secret/key/url can be edited if required (history should hopefully be available in the config log in case of error).
• Test configurations could be marked as such and not be available in assignments to non-admins.
• Drop-down available in assignment to select desired instance.

Migration on upgrade

• Loop through all configured instances of maharaws and create unique site instances. 
• Set new assignment instance config value to ID of associated site Mahara instance.
• May require admin to re-configure some instances after upgrade.

There may be a better way of managing the migration so other ideas are very welcome.

This may also impact some Ouriginal customisations we've done for a client, although that also stores configs per instance so we might be able to manage that later.

[danmarsden]

Sounds good - I'd drop the requirement for "test configurations" for the first release - but it's a nice to have - now the next challenge.... find a client to fund the improvements :-)

[anitsirk]

@sarahjcotton What do you mean by "Set new assignment instance config value to ID of associated site Mahara instance." ? LTI values are not associated with an instance of Mahara but with an institution within Mahara. Or did you mean that?

[sarahjcotton]

@anitsirk If creating unique sets of credentials at site level that can be re-used, then each set would be given an ID (probably primary key of a table). So the config value stored against an assignment would be that primary key value. I wasn't really thinking too much about what the data represents so much as how to migrate and store it, if that makes sense?

[aspark21]

This also next level awful because you are exposing the secret to teachers

[aspark21]

"this-should-not-be-seen" was the secret key before I replaced it for the purpose of this screenshot

[danmarsden]

@aspark21 that's one of the issues I tried to improve when forcing credentials at the site level (#45), but yes, my preference would be to have a way for the admin to define a bunch of LTI endpoints at the site level, and just allow the teacher to choose one of those without being able to see the secret.

But.... I'm not sure we'd want to heavily invest doing this within the plugin right now. There are some massive improvements to LTI functionality coming in Moodle 4.5 with the move of mod_lti into a core system (allowing lti connections to be managed at the site level) - so we could re-use that new core interface for maintainng the credentials for each mahara connection and then re-use them within the plugin.

But... of course - the new LTI work also includes something called "Asset processor" which may eventually mean that we can implement native support in both Moodle and Mahara to manage assignments without needing a plugin at all. (but that might not come until a later release as the spec itself is still under development.)