Hi Tobias and others, To clarify what we are doing with roles and users for LTI:
In the LMS (well, in Sakai), each user has a role specific to a site (context). So your role could be STUDENT in site A (e.g. Maths 4) but INSTRUCTOR in another site (say it's a site for which you are a tutor / TA or something). In Matterhorn, there is a flat role space, i.e. your role is global as there is no context modelling in the application. So what we do for LTI is map LMS_Context + LMS_Role to MH_Role, e.g. SITEID_STUDENT or SITEID_INSTRUCTOR, and then the Matterhorn series has permissions set for those roles. So in Matterhorn, you end up potentially with a lot of roles (2 x the number of active courses in the LMS). The question of the relationship of LTI users to MH users is related to http://opencast.jira.com/browse/MH-8316. By default, because there could be many different LTI consumers talking to a Matterhorn instance (e.g. a Sakai, moodle, drupal instance all from the same institution) and their userids could overlap in theory, LTI users are namespaced in MH with lti:domain:userid (e.g. lti:vula.uct.ac.za:userid). However, in the case where users could ALSO be authenticated via some non-LTI method (e.g. login from a mobile app not via the LMS, authenticated via LDAP), it may be helpful to have the LTI users map 1:1 to MH users, i.e. not with an lti namespace prefix, which is the notion of a "trusted" LTI consumer. LTI is relatively new so I don't think there's "common practice" here yet, more just what seems common sense and will be scalable and flexible. Regards Stephen Stephen Marquard, Learning Technologies Co-ordinator Centre for Educational Technology, University of Cape Town http://www.cet.uct.ac.za Email/IM/XMPP: [email protected] Phone: +27-21-650-5037 Cell: +27-83-500-5290 >>> Tobias Wunden <[email protected]> 7/6/2012 10:56 AM >>> 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] _______________________________________________ ### UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity. ### _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
