Tags:
create new tag
, view all tags

Rechtemanagement für Videoinhalte in CQ5 (und MMP)

Ausgangslage / Problematik

Beteiligte Systeme:

  • Opencast Matterhorn (MH), Video Management System
  • CQ5 Content Management System
  • Wowza Video-Streaming-Server (RTMP und HLS)
  • Apache HTML5-Videoserver (http)

Mit Opencast Matterhorn werden Videos für die Distribution auf verschiedenen Servern (Wowza, Apache) gespeichert. Informationen (Metadaten, Rechte, Links auf Videos und Vorschaubilder) über diese Videos gehen via OAI-PMH an CQ5,


a) um dort auf Basis einer in den Metadaten angegebenen URL (z.B. http://www.multimedia.ethz.ch/lectures/arch/2013/spring/051-0312-00L) das Multimedia Portal zu generieren (Szenario MMP) bzw.

b) um in CQ5 als Asset angezeigt und von Redakteuren in Webseiten integriert zu werden (Szenario CQ5).

Beide Szenarien unterscheiden sich (bei einigen wenigen Übereinstimmungen) deutlich hinsichtlich der Anforderungen an das Rechtemanagement, daher werden sie nachfolgend unterschieden.

Vorab: Gruppen in CQ5

Zur Zeit ist geplant, neben Leitzahl-Gruppen (Mitarbeiter/Dozenten/ETH-nahe/ETH-Gäste, die einer Leitzahl angehören) Einschreibungs-Gruppen (Studenten, die sich einem bestimmten Studiengang eingeschrieben haben) sowie Custom-Gruppen (selber definierte Gruppen) von nethz ins CQ5 zu exportieren. In CQ5 werden geschützte Seiten für solche Gruppen zugelassen. Beim Login-Prozedere via AAI/Shibboleth wird für den Benutzer ein Session-Key definiert und bei jedem Zugriff auf eine Seite wird die Berechtigung geprüft.

Im Szenario MMP ist es wünschenswert, dass die Zugangsberechtigung sehr granular, d.h. auf Kursebene, vergeben werden kann. Die Kurse befinden sich im Vorlesungsverzeichnis der OIS-Datenbank und werden derzeit noch nicht über nethz an die Zielsysteme geführt.

Offen:

  • Prüfen, ob Kursteilnehmer in der OIS-Datenbank vorhanden sind und ob diese Information auch nach nethz synchronisiert werden kann
  • Erstellen von Kursteilnehmer-Gruppen in CQ5

Szenario MMP

Im Multimedia Portal sollen Videos auf den folgenden Ebenen in ihrer Zugänglichkeit begrenzt werden:

  1. öffentlich
  2. Angehörige der Schweizer Hochschulen (AAI)
  3. Angehörige der ETH (gemäss der Differenzierung von Swen wären dies die Personenkategorie "ETH-Angehörige")
  4. Auf Ebene an anderen Orten definierter Gruppen (z.B. Mitarbeiter ID, Studierende D-ARCH, Studierende eines Kurses - also wahrscheinlich "Leitzahl" oder "Einschreibung")
  5. Frei definierte Gruppen (Forschungsgruppe inklusive Externer)
  6. Geschützt mittels fester Kennung/Passwort auf Ebene CMS; dieses Variante dient v.a. der Überführung alter Videos, die mangels Alternativen auf diesem Wege in Silva geschützt waren.
  7. Geschützt für einen IP-Range:Für Videomaterial, das nur in der Bibliothek eingesehen werden soll ("Sichtarbeitsplatz")

Die Rechte werden hoheitlich durch ID MMS in Opencast Matterhorn vergeben und sollten sich idealerweise auf die HTML-Seiten des CMS wie auch auf die Videos selbst beziehen; letzteres wird unten im Szenario "CQ5" behandelt. Die zentralen Fragen lauten:

  • Von welchen Systemen soll Opencast Matterhorn die verfügbaren Gruppen (zwecks Berechtigungs-Zuweisung) bekommen?
  • Wie gehen die Informationen von Matterhorn nach CQ5 (ACL?) und wie werden sie dort pro Seite (identisch i.d.R. mit einer Gruppe von Videos) verwaltet bzw. zur Zugangsprüfung eingesetzt?
  • Welche Information erhalten Personen, die nicht über ausreichende Rechte verfügen? Idealerweise sehen sie die Seite dennoch, jedoch ohne die Videos. Mittels der Metadaten könnnten Sie dann die für die Rechtevergabe zuständige Person identifizieren und ggf. kontaktieren.

Rechtemanagement im Szenario CQ5

Rechtemanagement für Assets in CQ5

Bei der Bereitstellung von Video für CQ5 sind prinzipiell ähnliche Wünsche nach Zugänglichkeit zu erwarten. Das bedeutet aber auch, dass die Videos nicht nur in der Konsumation auf der Webseite geschützt werden müssen, sondern auch in der Bereitstellung als Asset: Redakteure dürfen nur diejenigen Videos sehen bzw. einbetten, für die sie die notwendigen Rechte haben (inkl. freier Videos).

Rechtemanagement von CQ5 nach MH

Da mittelfristig die Bereitstellung von Video nicht mehr über MMS erfolgen soll, sondern Redakteure selbst Videos heraufladen können, müssen sie zusätzlich die Zugänglichkeit dieser Videos definieren und modifizieren können. Die Information hierüber müssen, ebenso wie das Video selbst und die (neuen oder modifizierten) Metadaten an Matterhorn gehen, um eine Konsistenz zwischen CQ5 und MH zu gewährleisten.Prinzipiell müsste OAI-PMH "umgekehrt" werden.

  • Wie wird sichergestellt, dass die Autoren nur diejenigen Assets sehen, die gemäss Rechten der Assets (i.e. Videos) für sie zugänglich sind?
  • [Wie erfolgt das Heraufladen von Videos via CQ5 nach Matterhorn?]
  • Wie erfolgt die Erstellung einer ACL in CQ5?
  • Ist deren Weitergabe mit dem Video und weiteren Metadaten nach Matterhorn möglich? Ist eine Aktualisierung der ACL möglich?
  • Ist deren Weitergabe bzw. Aktualisierung gegenüber den Videoservern möglich (s.u.)?
  • Wie wird die Synchronizität von Zugänglichkeit einer Seite und eines Videos gewährleistet? In freie Seiten sollten z.B. eigentlich keine geschützten Videos eingebettet werden.

Geschützte Videos, http und Streaming (CQ5 und MH)

Wenn ein User ein bestimmtes Video auf einer geschützten CQ5-Seite ansehen möchte, wird zwar über die Gruppen-Mitgliedschaft geprüft, ob der eingeloggte User dies darf. Der eingebettete Video-Player hingegen holt das Video mit einer URL vom Apache- oder Streaming-Server ab. Diese Video-URL kann vom User problemlos kopiert und weitergegeben werden. So kann ein nicht autorisierter Benutzer ebenfalls auf dieses Video zugreifen - was man eigentlich verhindern möchte. Wie die Industrie solche Probleme handhabt, kann man hier nachlesen. Generell kann man nie 100% verhindern, dass ein geschützter Inhalt einen Weg nach «draussen» findet.

In unserer aktuellen Systemlandschaft ergibt sich allerdings noch ein weiteres Problem: Wenn die Information, wer ein bestimmtes Video sehen darf, sich im Video respektive in den Metadaten auf dem Apache- und Streamingserver befindet, hat der Publisher in CQ5 keine Möglichkeit, diese direkt in CQ5 zu ändern. Das ist insofern problematisch, weil der Publisher in der Regel davon ausgeht, dass er die vollen Rechte über seinen Content hat (wie bei Bildern und Text ja auch) und er demzufolge bestimmen darf, wer Zugriff bekommt und wer nicht.

In diesem Sinne ist es nicht sinnvoll, wenn bereits beim Recording die Zugriffsrechte festgelegt werden, zumal der Publisher den Film zunächst für einen kleinen Benutzerkreis einschränken und später den Filmfür die ganze Welt freischalten möchte. Wenn er dann den Schutz auf seiner Webseite aufhebt, kann der Film trotzdem nicht von jedermann abgespielt werden, weil die Rechte auf der Webseite nicht automatisch auf den Content vererbt wurden und der Streamingserver nach wie vor das Abspielen für jedemann sperrt. Es ist wichtig, dass der Content die Zugriffsrechte von der Seite erbt, in der er eingebettet ist.

Lösungsansatz 1: Berechtigung IP-basierend

Dieser Ansatz macht geltend, dass die Autorisierung jederzeit vom Publishing-System aus bestimmt wird, in unserem Fall ist das CQ5. Der Apache- und Streaming-Server muss grundsätzlich wissen, woher der Request stammt und wohin er das Video ausliefern muss. Die Autorisierungsinformation (darf dieser Benutzer das?) könnte man im URL des Videos als (symmetrisch verschlüsselten) Parameter mitgeben, eine Art Quittung. Der Ablauf würde z.B. so aussehen:

  • CQ5 produziert in einer geschützten Seite für jeden User einen symmetrisch verschlüsselten Hash, welcher folgende Informationen enthält:
    • die IP-Nummer des Users
    • einen Timestamp
    • eine für das Video-Objekt eindeutige Information (z.B. Anzahl Bytes oder eine eindeutige ID)
  • dieser Hash wird im Video-URL als Parameter hinzugefügt, zusammen mit der URL der ursprünglichen CQ5-Seite, wo das Video publiziert wurde
  • der Streaming-Server kann mit demselben Schlüssel wie es CQ5 benutzt (shared secret) den Hash wieder entschlüsseln und bekommt somit die IP-Nummer sowie den Timestamp
  • der Streaming-Server vergleicht die Request-IP mit der IP des Hashes (müssen identisch sein)
  • der Streaming-Server prüft, ob der Timestamp nicht bereits zu alt ist (timeout) und sich der Benutzer eventuell nochmals bei CQ5 authentisieren muss
  • der Streaming-Server prüft alternativ (bei Abwesenheit von IP und Timestamp), ob die ID des Videos stimmt (=Video ist frei verfügbar)
  • falls die Prüfungen erfolgreich verlaufen, wird das Video gestreamt
  • falls nicht, erfolgt ein Redirect auf die ebenfalls übermittelte URL der CQ5-Seite, wo sich der Benutzer neu authentisieren/autorisieren kann

Vorteile

  • der Publisher in CQ5 hat stets volle Kontrolle über seinen Content und die Berechtigungen darauf
  • die URL des Videos kann nicht ohne weiteres gefälscht werden
  • die URL des Videos kann frei kopiert werden und führt zur CQ5-Seite, falls der User nicht authentisiert ist
  • das Video kann problemlos in einem anderen Player ausgeführt werden (VLC, Quicktime etc.)
  • Streaming-Server muss keinen weiteren Server anfragen, da er die «Quittung» gleich mitbekommt

Nachteile

  • relativ lange URL für ein Video
  • alternativ können generell freie Videos in den Metadaten entsprechend markiert werden
  • Redirect auf eine CQ5-Seite, die wenn man nur die Video URL shared, nicht von Playern verarbeitet werden kann

Lösungsansatz 2: Session Token

  • wie bei 1 produziert CQ5 einen verschlüsselten Hash (Token)
  • der Streaming Server validiert das Token immer über CQ5, das dann mit OK oder Not Ok antwortet.
  • falls Token ungültig,
    • versucht CQ5 einen eingeloggten User zu autorisieren oder
    • antwortet CQ5 mit einer standardisierten Basic Authentication Anfrage. Diese wird auch von externen Video Playern verstanden (z.B. VLC)
  • Vorteil: gesamte Logik in CQ5, standardisierter Login
  • Nachteil: mehr Requests
Da CQ keine Authentisierung macht sondern Shibboleth, sind wesentliche Teile dieses Vorschlags hinfällig

Todos

  • Prüfen, ob es neben den besprochenen Lösungsansätzen noch weitere Möglichkeiten gibt
  • Prüfen, ob der Lösungsansatz überhaupt umgesetzt werden kann
  • Prüfen, welche Gruppen auf Learning Platformen verwendet werden
  • Wie werden RSS-Feed in den Schutz eingebunden?

Graphisches

-- SwenVermeul - 2013-06-05

Topic attachments
I Attachment History Action Size Date Who Comment
PDFpdf Authentication_Landscape.pdf r1 manage 217.7 K 2013-06-07 - 05:48 UnknownUser Übersicht der Matterhorn-CQ5 Landschaft
PDFpdf nethz_Gruppen.pdf r1 manage 1518.9 K 2013-06-05 - 20:04 UnknownUser nethz Gruppen-Synchronisation
Topic revision: r13 - 2013-08-21 - schulteo
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback