Hi Tobias,
On 01/27/2012 10:22 AM, Tobias Wunden wrote:
Hi David,
I see that in the Series UI in engange one can no longer add Roles that aren't
returned by a Role provider. I believe this is a recent change and I think a
problematic one.
I am not aware of that change, but it seems to make sense since the role
provider in the end is used to do authorization. Giving the user the ability to
add roles that cannot be evaluated at runtime may not be what you want and
*may* in most cases lead to speling mistakes go by unnoticed.
Hmm if thats the case I missed something major and may have a major
issue here. Mapping SIS information to group information in a system is
a non trivial task and one I hoped to shelve past our launch (I also
think the RoleProvider is inadequate for a sizeable organization).
OK our case is this - LTI passes role and context information to the
producer (Matterhorn). This is mapped to a role (or roles). So LTI in
Matterhorn will construct a role like:
206889d6-569b-4fd3-8014-d0e699f710df_student (In Sakai, Moodle etc
the id part may be different)
There is no way that that the RoleProvider can know these ahead of time
(it would break the point of the loose integration), however an admin
can know them and add them to a series. The only other way to limit
would be for the LTI key to be highly trusted and for Matterhorn to map
the supplied user to a known user with group information - this is in
the works but not ready yet.
Also I would like our admins to give the series access to the SIS groups
so that when the integration work is complete access is available
through non LTI channels.
Currently we have 3898 courses being offered this year, Seeing as they define
at least 2 roles each we're now up to potential 7796 roles (and in reality
there are more than 2 roles in a course). So we're loading matterhorn with role
definition in the thousands for the hand full that need tight permission
handling.
I think the original idea behind this was that most universities would have a database
that would state that a given student is attending this and that course (or is at a
certain stage in his educational carreer) and that those "affiliations"
(provided by university system) would be used as roles.
However, if you need to add those roles manually, I agree that it's a daunting
task. One question though: My understanding is that if you don't add any role
information, the recording will be open, which I think is what you want for
most series, correct?
Actually no - having to have all lectures public will be a serious
barrier to adoption at UCT - most of our users are not ready for that so
we want to offer them the opportunity to limit it to the course members.
There are 2 issues here we may be conflating:
1 - UserProvider supplying user details and the names of the groups the
user belongs to
2 - Groupprovider - supplies all the know group names to matterhorn.
1 is not the issue here and my understanding this is what's used to
answer Authz questions. 2 is the issue as its now being used to do more
than suggest valid names.
D
Tobias
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
