Password protection for recordings

[Philip John Mordecai]

Hello everyone,

after Rüdiger, Lars and Christian from Osnabrück resolved all of my problems I actually have a running matterhorn core instance and a working capture agent! (Thanks again guys!)

The CA is ready to be set up in the lecture hall by next monday to record four or even five lectures this summer at the University of Münster. 

Now I have one - hopefully tiny - problem left: Every recorded lecture has to be protected by a password. I don't need a complex user management system or anything like that. A simple password for every lecture would be enough - just as moodle does it. I checked the wiki but i didnt find thing relevant...

Cheers,

Philip

[Stephen Marquard]

Hi Philip,

If you're happy with the same password for every user and every lecture (i.e. only one password), then you can put an apache proxy in front of your Matterhorn setup, and use mod_auth (or any of the other apache auth modules, for example LDAP or CAS, which would give you user-based access).

You can create users in Matterhorn, but the engage player URL will just give you a "media not available" error at the moment rather than redirecting to a login page, so that approach is not that helpful.

Regards

Stephen

---

From: Philip John Mordecai [philipm...@gmail.com]
Sent: 04 April 2014 04:54 PM
To: matterho...@opencast.org
Subject: [Matterhorn-Users] Password protection for recordings

--
You received this message because you are subscribed to the Google Groups "Matterhorn Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to matterhorn-use...@opencast.org.
To post to this group, send email to matterho...@opencast.org.
Visit this group at http://groups.google.com/a/opencast.org/group/matterhorn-users/.

---

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.

[Philip John Mordecai]

Hi Stephen!

Well this would certainly be a simple way to protect the media gallery as a whole. Is there no simple way to protect each series of recordings with a different password? If not I just hope that all professors agree on having one password for all lectures...

Regards

Philip

Am Freitag, 4. April 2014 17:11:16 UTC+2 schrieb Stephen Marquard:

Hi Philip,

If you're happy with the same password for every user and every lecture (i.e. only one password), then you can put an apache proxy in front of your Matterhorn setup, and use mod_auth (or any of the other apache auth modules, for example LDAP or CAS, which would give you user-based access).

You can create users in Matterhorn, but the engage player URL will just give you a "media not available" error at the moment rather than redirecting to a login page, so that approach is not that helpful.

Regards

Stephen

---

From: Philip John Mordecai [philipm...@gmail.com]
Sent: 04 April 2014 04:54 PM
To: matterho...@opencast.org
Subject: [Matterhorn-Users] Password protection for recordings

Hello everyone,

after Rüdiger, Lars and Christian from Osnabrück resolved all of my problems I actually have a running matterhorn core instance and a working capture agent! (Thanks again guys!)

The CA is ready to be set up in the lecture hall by next monday to record four or even five lectures this summer at the University of Münster. 

Now I have one - hopefully tiny - problem left: Every recorded lecture has to be protected by a password. I don't need a complex user management system or anything like that. A simple password for every lecture would be enough - just as moodle does it. I checked the wiki but i didnt find thing relevant...

Cheers,

Philip

--
You received this message because you are subscribed to the Google Groups "Matterhorn Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to matterhorn-use...@opencast.org.

To post to this group, send email to matterh...@opencast.org.

Visit this group at http://groups.google.com/a/opencast.org/group/matterhorn-users/.

[Rüdiger Rolf]

Hi Philip,

Stephen is right that you are not asked for a login by default, when you open the player for a protected recording. But you could disallow anonymous logins for the player at all. Then the login field will show up at any time.
You can change that in etc/security/ mh_default_org.xml the line
<sec:intercept-url pattern="/engage/ui/**" access="ROLE_ANONYMOUS" />
to
<sec:intercept-url pattern="/engage/ui/**" access="ROLE_USER" />

You can use the uncomfortable build in user database of matterhorn then: simply insert the users to the database directly. For that you would need to switch to an MySQL database[1], that currently is not installed on your server. How to insert a user then is described on the bottom of this page:
https://opencast.jira.com/wiki/display/MHTRUNK/Security+Configuration
You can create separate accounts for the viewers and admins of every series.
If you have access to an alternative identity provider (CAS, LDAP, ...) you can configure Matterhorn to use them.

If you have Moodle available, you can use LTI to integrate Matterhorn with Moodle and use Moodles user management for access restrictions. That would still keep the public access to the open recordings.

Regards
Rüdiger

[1] https://opencast.jira.com/wiki/display/MHTRUNK/MySQL+Database+Configuration is hopefully up to date

Am 04.04.14 18:14, schrieb Philip John Mordecai:

To post to this group, send email to matterho...@opencast.org.

Visit this group at http://groups.google.com/a/opencast.org/group/matterhorn-users/.

-- 
________________________________________________
Rüdiger Rolf, M.A.
Universität Osnabrück - Zentrum virtUOS
Heger-Tor-Wall 12, 49069 Osnabrück
Telefon: (0541) 969-6511 - Fax: (0541) 969-16511
E-Mail: rr...@uni-osnabrueck.de
Internet: www.virtuos.uni-osnabrueck.de

[Ruth Lang]

Hi all,

I don't think it is enough to create only users in the DB, you must also define a new role, so that a certain user can see the recordings of a certain series.

As we have done a lot of testing in this direction we ended up with the following scenarios (we are using those since WS 13/14)

1) To avoid a complete user management inside MH, lecture recordings are available almost entirely via the student's LMS course. They have to login there and the LTI interface is used to start the engage player. This works perfectly and the effort is negligibly (definitely on the MH side). We have modified the engage player to ban downloading  and distribution to social media. 

2) All LMS user ids, that request a video, were mapped to one single MH account (say LMS-USER) with the role ROLE_OAUTH_USER. Therefore all series available to an LMS must have this role.

3) We created (test)users in our DB. They can login under https://<engage-server>:8433/login.html. Depending on the roles assigned to user and series, they can play/see the lecture recordings of different series. 

Here an example:

       seriesA (ROLE_USER_A, ROLE_OAUTH_USER)     

       seriesB (ROLE_USER_B)

       seriesC(ROLE_OAUTH_USER)

       userA (ROLE_USER_A)  --> can only see recordings of series A

       userB (ROLE_USER_A, ROLE_USER_B) --> can see recordings of series A and series B

       LMS-USER (ROLE_OAUTH_USER) -- can see recordings in series A and series C 

Be careful when setting the password for an user in the DB, it is salted hash.

4.) All public video (default system role) can be seen under https://<engage-server>:8433/engage/ui

Regards

Ruth

[Lars Kiesow]

Hi Philip,
I'd like to add yet another way of password protection ;-)
It's a really simple one, though.

As you already have an Nginx installed as streaming server and reverse
proxy, you can use that one to easily set a simple password (HTTP
authentication).

For this, just edit your nginx configuration (should probably
be /etc/nginx/nginx.conf) and add:

#Password Protection for Engage UI
location ^~ /engage/ui {
auth_basic "Restricted";
auth_basic_user_file engage.htpasswd;

proxy_pass http://127.0.0.1:8080;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host YOUR.SERVER.HOST.DE;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Then you can add user/passwords to the file engage.htaccess (located in
the nginx configuration dir) using the htpasswd tool.

Regards,
Lars

On Sat, 5 Apr 2014 08:39:30 -0700 (PDT)
Ruth Lang <ruth...@googlemail.com> wrote:

> Hi all,
>
> I don't think it is enough to create only users in the DB, you must
> also define a new role, so that a certain user can see the recordings
> of a certain series.
>
> As we have done a lot of testing in this direction we ended up with
> the following scenarios (we are using those since WS 13/14)
>
> 1) To avoid a complete user management inside MH, lecture recordings
> are available almost entirely via the student's LMS course. They have
> to login there and the LTI interface is used to start the engage
> player. This works perfectly and the effort is

> negligibly<http://www.dict.cc/englisch-deutsch/negligibly.html>

> >> ------------------------------
> >> *From:* Philip John Mordecai [philipm...@gmail.com]
> >> *Sent:* 04 April 2014 04:54 PM
> >> *To:* matterho...@opencast.org
> >> *Subject:* [Matterhorn-Users] Password protection for recordings

> >>
> >> Hello everyone,
> >>
> >> after Rüdiger, Lars and Christian from Osnabrück resolved all of
> >> my problems I actually have a running matterhorn core instance and
> >> a working capture agent! (Thanks again guys!)
> >> The CA is ready to be set up in the lecture hall by next monday to
> >> record four or even five lectures this summer at the University of
> >> Münster.
> >>
> >> Now I have one - hopefully tiny - problem left: Every recorded
> >> lecture has to be protected by a password. I don't need a complex
> >> user management system or anything like that. A simple password
> >> for every lecture would be enough - just as moodle does it. I
> >> checked the wiki but i didnt find thing relevant...
> >>
> >> Cheers,
> >> Philip
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Matterhorn Users" group.
> >> To unsubscribe from this group and stop receiving emails from it,
> >> send an email to matterhorn-use...@opencast.org.
> >> To post to this group, send email to matterh...@opencast.org.
> >> Visit this group at
> >> http://groups.google.com/a/opencast.org/group/matterhorn-users/.

> >> ------------------------------

> >> 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.
> >>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Matterhorn Users" group.
> > To unsubscribe from this group and stop receiving emails from it,

> > send an email to matterhorn-use...@opencast.org <javascript:>.

> > To post to this group, send email to

> > matterho...@opencast.org<javascript:> .

> > Visit this group at
> > http://groups.google.com/a/opencast.org/group/matterhorn-users/.
> >
> >
> >
> > --
> > ________________________________________________
> > Rüdiger Rolf, M.A.
> > Universität Osnabrück - Zentrum virtUOS
> > Heger-Tor-Wall 12, 49069 Osnabrück
> > Telefon: (0541) 969-6511 - Fax: (0541) 969-16511

> > E-Mail: rr...@uni-osnabrueck.de <javascript:>
> > Internet: www.virtuos.uni-osnabrueck.de
> >
> >
>

[Philip John Mordecai]

Thanks everyone for your ideas! I'll be going for an easy password protection as lars suggested for our test-run. Integration into our LMS (moodle) seems to be the smoothest solution in the long run.

We should think about adding those ways to protect recordings or the media gallery/engage as a whole to the wiki. I can imagine that this is an important feature for adopters - especially in germany where it's absolutley common to restrict access to university-content. 

Cheers,

Philip

[Olli Salo]

Hi,

I'd first like to thank you Pascal and Tobias for your ideas mentioned
in the previous thread regarding the best practices to protect video
content.

In our University a Moodle-based solution would solve maybe a majority
of our teachers' ACL needs. That's why I have been having dreams
(literally, during night time) of a Moodle block which would query MH
from the Moodle course area (which has a unique Moodle courseid) so that
MH would then search for series where the ACL is something like:
ROLE_MOODLE_<courseid>. Moodle would then get a listing of those
recordings which are assosiated to that course, and the students in that
course would be able to play the recordings from Moodle. Plain and
simple, right? So, has anyone made this kind of Moodle block already?

Or... is this doable directly with LTI? I tried LTI a couple of years
ago with Moodle and MH of that time. I didn't get it to work then, but
maybe it would work now. My only question is: does LTI let you set your
Moodle server so that the Moodle courses could retrieve course-spesific
MH content the way I describe above?

Olli S.

> --
> You received this message because you are subscribed to the Google
> Groups "Matterhorn Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to matterhorn-use...@opencast.org

> <mailto:matterhorn-use...@opencast.org>.

> To post to this group, send email to matterho...@opencast.org

> <mailto:matterho...@opencast.org>.

> Visit this group at
> http://groups.google.com/a/opencast.org/group/matterhorn-users/.


--

Olli Salo
Tietotekniikkakeskus
Helsingin yliopisto
Tel: +358 9 191 21782
Gsm: +358 50 407 5509
Email: olli...@helsinki.fi

[Per Pascal Grube]

Hi Olli,

for limiting access to certain lectures, we do the following.

Each lecture that should only be visible by students of the certain course,
we assign access to a role called <ID>_Learner to a series, where ID the
couse-id in ILIAS. The ID gets passed to mh using LTI. Creating the series
with the proper ACLs is done when creating a corresponding MH-Object in ILIAS.
This if of course something that would need to be created for moodle.

When using LTI to access the engage node, you can pass along the ID of a
series, so what the student basically see is a filtered list.

Hope this helps.

Regards,

Pascal

Per Pascal Grube
IZUS/TIK
Universitaet Stuttgart Tel: ++49-711-685-60011
Allmandring 30a
70550 Stuttgart www.tik.uni-stuttgart.de


***********************************************************

[Alexander Bias]

Pascal,

> Each lecture that should only be visible by students of the certain course,
> we assign access to a role called <ID>_Learner to a series, where ID the
> couse-id in ILIAS. The ID gets passed to mh using LTI. Creating the series
> with the proper ACLs is done when creating a corresponding MH-Object in ILIAS.
> This if of course something that would need to be created for moodle.
>
> When using LTI to access the engage node, you can pass along the ID of a
> series, so what the student basically see is a filtered list.

This sounds great. But I didn’t understand it completely up to now. Let me sum it up:

1. In MH, you create a series.
2. You addd a role to the ACL of this series. This role is called <ID>_Learner and <ID> is the course ID in ILIAS. Did you create this role beforehand in the MH DB so that you can add it to the series? The role name is mixed case and does _not_ have a „ROLE_“ prefix..? Do you also have to add the ROLE_OAUTH_USER role to the series or not?
3. When serving the LTI object to a viewer, ILIAS passes the course ID where the LTI object is placed to MH when calling engageserver.com/lti, right? What LTI parameter does ILIAS use - a custom_* LTI key?
4. MH grants viewing access to the series based on the course ID from ILIAS and the ACL in the series. Is this a standard behaviour of the LTI module in MH or did you code anything special in MH to acchieve this?

You see, I’m pretty confused and am looking forward for some enlightening :)

Best regards
Alexander Bias

University of Ulm
Communication and Information Centre (kiz)
Team Web & Teaching Support

[Ruth Lang]

Hi,

I can't understand why it should be necessary to assign an additional role (containing the LMS course ID) to a series which is accessed via LMS/LTI.

The MH-object for an ILIAS course already contains either a mediapackage ID or a series ID. So the access to a certain series is already restricted. The only role that must be assigned to a series is ROLE_OAUTH_USER otherwise the LTI interface won't work.

The input of a series ID or a mediapackahge ID is requested in our LMS. Indeed if no series ID is given in the MH-object the student have access to all recordings belonging to a series with the role ROLE_OAUTH_USER.

Regards

Ruth

[Per Pascal Grube]

Hi,

sorry for the late reply,

On Tuesday 08 April 2014 22:30:45 Ruth Lang wrote:
> Hi,
>
> I can't understand why it should be necessary to assign an additional role
> (containing the LMS course ID) to a series which is accessed via LMS/LTI.
>
> The MH-object for an ILIAS course already contains either a mediapackage ID
> or a series ID. So the access to a certain series is already restricted.
> The only role that must be assigned to a series is ROLE_OAUTH_USER
> otherwise the LTI interface won't work.

We had used this before. The issue with this approach is, that whenever a user
will access the engage directly after he has accessed it from the lms, he will
see all lectures available to the oauth-user. This basically means you have a
visibility "LMS-User". In my opinion, this kind of restriction is still to
wide open. We wanted to have a visibility "Course-Member", so using this
approach does not work for us.

> The input of a series ID or a mediapackahge ID is requested in our LMS.
> Indeed if no series ID is given in the MH-object the student have access to
> all recordings belonging to a series with the role ROLE_OAUTH_USER.

Regards,

Pascal

[Per Pascal Grube]

On Tuesday 08 April 2014 14:12:38 Alexander Bias wrote:
> Pascal,
>
> > Each lecture that should only be visible by students of the certain
> > course, we assign access to a role called <ID>_Learner to a series, where
> > ID the couse-id in ILIAS. The ID gets passed to mh using LTI. Creating
> > the series with the proper ACLs is done when creating a corresponding
> > MH-Object in ILIAS. This if of course something that would need to be
> > created for moodle.
> >
> > When using LTI to access the engage node, you can pass along the ID of a
> > series, so what the student basically see is a filtered list.
>
> This sounds great. But I didn’t understand it completely up to now. Let me
> sum it up:

> 1. In MH, you create a series.
> 2. You addd a role to the ACL of this series. This role is called
> <ID>_Learner and <ID> is the course ID in ILIAS. Did you create this role
> beforehand in the MH DB so that you can add it to the series?

No, we don't create it in the database. You can add it the series, even if the
UI complains that the role does not exist. It still works.

>The role name
> is mixed case and does _not_ have a „ROLE_“ prefix..? Do you also have to
> add the ROLE_OAUTH_USER role to the series or not?

No. only the <ID>_ROLE. OAUTH_USER means anybody with LTI-access can see it.

One thing you need to know that the LTI module creates a none-persistent user
when accessing with LTI and assigns to is a none-persistent role in the form
<context_id>_<role>, with context_id and role being parameters passed via lti.
This is what gets matched by the engage node.

> 3. When serving the LTI
> object to a viewer, ILIAS passes the course ID where the LTI object is
> placed to MH when calling engageserver.com/lti, right? What LTI parameter
> does ILIAS use - a custom_* LTI key?

The <ID> needs to be passed ass context_id (not a custom one) parameter
You need to pass the tool (series/single episode) as custom_tool and the
matterhorn_id as custom_id.

>4. MH grants viewing access to the
> series based on the course ID from ILIAS and the ACL in the series. Is this
> a standard behaviour of the LTI module in MH or did you code anything
> special in MH to acchieve this?

We have a standard matterhorn without any special configs.

> You see, I’m pretty confused and am looking forward for some enlightening :)

I hope this clarifies some things. Otherwise, I will try to explain it in more
detail.

Regards, Pascal

[Alexander Bias]

Hi,

>> I can't understand why it should be necessary to assign an additional role
>> (containing the LMS course ID) to a series which is accessed via LMS/LTI.
>>
>> The MH-object for an ILIAS course already contains either a mediapackage ID
>> or a series ID. So the access to a certain series is already restricted.
>> The only role that must be assigned to a series is ROLE_OAUTH_USER
>> otherwise the LTI interface won't work.
>
> We had used this before. The issue with this approach is, that whenever a user
> will access the engage directly after he has accessed it from the lms, he will
> see all lectures available to the oauth-user. This basically means you have a
> visibility "LMS-User". In my opinion, this kind of restriction is still to
> wide open. We wanted to have a visibility "Course-Member", so using this
> approach does not work for us.

That’s basically what I wanted to say, too.

I agree with you, Ruth, that access to recordings which only allow access to ROLE_OAUTH_USER users is restricted to LMS members. But to _all_ LMS members. What is done inside the LMS is security by obscurity - no more, no less. If a teacher who is allowed to place the LTI object gets to know a series ID from a colleague’s series, he is able to show these recordings to his students via LTI. And I dare to say if a student is capable of tampering with the communication between his browser and the LMS server, he might be able to modify the custom_series parameter and watch a different series. Please correct me if I’m wrong.

[Alexander Bias]

Dear Pascal,

>> The role name
>> is mixed case and does _not_ have a „ROLE_“ prefix..? Do you also have to
>> add the ROLE_OAUTH_USER role to the series or not?
> No. only the <ID>_ROLE. OAUTH_USER means anybody with LTI-access can see it.
>
> One thing you need to know that the LTI module creates a none-persistent user
> when accessing with LTI and assigns to is a none-persistent role in the form
> <context_id>_<role>, with context_id and role being parameters passed via lti.
> This is what gets matched by the engage node.
>
>> 3. When serving the LTI
>> object to a viewer, ILIAS passes the course ID where the LTI object is
>> placed to MH when calling engageserver.com/lti, right? What LTI parameter
>> does ILIAS use - a custom_* LTI key?
> The <ID> needs to be passed ass context_id (not a custom one) parameter
> You need to pass the tool (series/single episode) as custom_tool and the
> matterhorn_id as custom_id.

Wow. I am completely amazed!

I didn’t know about this "none-persistent user / role“ feature for LTI. Is this documented somewhere in the wiki?

Moodle passes exactly the same LTI parameters to Matterhorn as you described it for ILIAS:
„context_id" contains the Moodle course’s ID.
And „roles“ contains information about the user’s LMS role, i.e. „Learner“ or „Instructor“.

So, if I add Role „336_Learner“ and „336_Instructor“ (with 336 being my Moodle course’s ID) to my Matterhorn series and remove the „Public“ viewing rights, only students and teachers of exactly this Moodle course can view these recordings.

I think I will work this through in detail again early next week and will provide a step-by-step instruction for connecting Moodle to MH and for restricting MH series to Moodle courses.


Well, but one more question for the paranoid ones among us: In my previous mail, I wrote that a student might tamper with the HTTP request and modify the LTI parameters (here: context_id and roles). Does anyone know if the LTI parameters which get exchanged between the user’s browser and the LMS parameters get secured with something like a checksum to prevent tampering? Or is this still a possibility to access unauthorized series for the savvy students?

[Per Pascal Grube]

Hi Alexander,

No, unless they manage to bruteforce the password you use LTI. The entire form
gets signed by a hmac-sha1 signature. The shared secret between the LMS and MH
are part of this hmac-sha1 signature. So any modification of any parameter will
break the signature. In this case, the LTI-module reject the request as not
valid.

Regards, Pascal

[Alexander Bias]

> No, unless they manage to bruteforce the password you use LTI. The entire form
> gets signed by a hmac-sha1 signature. The shared secret between the LMS and MH
> are part of this hmac-sha1 signature. So any modification of any parameter will
> break the signature. In this case, the LTI-module reject the request as not
> valid.

That’s good to hear. Thanks!