Hi Edmore, > We are currently working on allowing users to schedule recordings via an LMS > ( in our case Sakai ) . We are facing an issue since the LTI user is > currently created "on the fly" (in memory). The userDirectoryService cannot > see this user which makes it impossible to schedule recordings.
Just to add some context here: the service registry stores a "creator" when a job is created, which in this case is the lti user. When the job is executed, the creator is set in the security service as the current user, which is when it can't be found since it was only available in memory when the LTI tool was used to connect and create the job. > We were considering the possibility of persisting a new user into the > Matterhorn database on LTI launch. The user is currently name spaced in the > format "lti:<tool_consumer_instance_guid>:<user_id>", e.g. > "lti:vula.uct.ac.za:8f14f862-dbec-48a6-92ad-4841b983d90f". David had chatted > to Tobias briefly about this. Does anybody have any reservations regarding > this or any suggestions about how we could handle this issue. One thing that I don't understand about LTI is the user authority. When a user is working in an LMS and connecting to MH through an LTI tool, the LMS knows about the user and its roles (in the LMS) and passes this information though LTI on to MH. Looking at the code and reading Edmore's message, it seems as if there is an LTI user created on the fly. So now I am wondering what the ideal design should be: Are LTI requests usually matched to MH users, or is it common practice in LTI land to keep the LTI users apart from the tool's user base? And if so, how can the LTI consumer tell MH about the MH roles that the current user should have (i. e. "INSTRUCTOR" vs. "STUDENT")? Anyways, if we need to support lti:xyz users, I suggest creating an LTIUserDirectory service that returns a user for each of the lti:lookups. This implementation by default could simply create a user with the correct role set (make this a managed service with service configuration). Alternatively, that service could be backed by the existing user database. Tobias _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
