Ulrichs Werkbank

Streaminginhalte sichern

Wie jeder weiß beinhalten Tisch- und Klapprechner sowie nahezu jedes mobile Gerät wie z.B. Schlaufon oder Tafelrechner Programme zum Abspielen von Musik und Video per Streaming. Nicht so bekannt ist, dass für deren Nutzung nicht unbedingt ein Streaming-Dienst benötigt wird. Die Installation einer einzigen Software und ein wenig zusätzliche Konfiguration lassen jeden beliebigen Rechner zum Streaming-Server und dessen Nutzer damit unabhängig von jeglichen Streaming-Diensten werden.

Der Web- und Applikationsserver Tomcat bringt für das Streaming bereits alles mit, es muss bloß eingeschaltet werden. Wie einfach Tomcat installiert wird beschreibt der Tipp Tomcat auf Linux. Der Tipp Statische Inhalte via HTTP beschreibt zudem, wie einfach mit Tomcat Audio- und Videoinhalte per Streaming bereitgestellt werden können.

Wird das ganze in den eigenen vier Wänden hinter einem Router betrieben, sind die betreffenden Inhalte auch hinreichend gegen unerwünschte Zugriffe geschützt. Was aber, wenn man auf diese Weise zentral abgelegte Musik und Videos auch ausserhalb der heimischen Umgebung nutzen möchte?

Auch für diesen Fall können Bordmittel von Tomcat bzw. der Java-Technologie verwendet werden. Dieser Tipp beschreibt, wie unerwünschte Zugriffe ferngehalten werden nachdem der Router für die Nutzung 'von außen' geöffnet wurde.

Im Prinzip wird dort, wo Musik und Video abgelegt sind, einfach ein Ordner WEB-INF und darin eine Datei web.xml angelegt. Nachfolgend die wenigen einfachen Einstellungen, mit denen eine Absicherung eingeschaltet wird.

Authentifizierung und Autorisierung

Zur Absicherung von Inhalten, die von Tomcat ausgeliefert werden, wird üblicherweise den betreffenden Inhalten eine Konfiguration beigegeben, die den Servlet Container veranlasst, den Benutzer zunächst zu authentifizieren, ihn also aufzufordern, den Benutzernamen und das Kennwort zu nennen. Ist auf diese Weise bestimmt wer zugreift wird geprüft, ob der betreffende Benutzer die ebenfalls in der Konfiguration hinterlegte Rolle besitzt und sofern alles passt der Inhalt schließlich ausgeliefert.

Zum Einschalten der Authentifizierung werden einige wenige zusätzliche Einstellungen nötig: Liegen die Inhalte z.B. im Verzeichnis /media/extplatte wird dort ein Verzeichnis WEB-INF und darin die Datei web.xml angelegt. In die Datei wird folgende Konfiguration eingetragen.

    <security-constraint>
        <display-name>Streameinschraenkung</display-name>
        <web-resource-collection>
            <web-resource-name>Media</web-resource-name>
            <description/>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <description>streamNutzerErlaubt</description>
            <role-name>streamNutzer</role-name>
        </auth-constraint>
    </security-constraint>
    <login-config>
        <auth-method>BASIC</auth-method>
    </login-config>

Diese Einstellung bewirkt, dass nur noch authentifizierte Nutzer Inhalte abspielen dürfen und nur dann, wenn sie die Rolle streamNutzer besitzen. Hierbei muss nicht zwangsläufig die Anmeldung vom Abspieler aus gemacht werden. Man kann auch ein Programm verwenden, das nach erfolgter Anmeldung die Session-ID ermittelt und dem Abspieler über den URL mitgibt. Hierfür wird dem URL einfach ;jsessionid= gefolgt von der Session-ID angefügt.

http://example.com/av/pfad/zum/inhalt.mp3;jsessionid=12345

Während der obige Streaming-Aufruf vom Server beantwortet wird, sofern die Session-ID eine gültige Sitzung referenziert, würde ein URL ohne Session-ID abgewiesen werden. Wird z.B. der Ablageort eigener Medieninhalte erraten oder anders herausbekommen, kann dieser ohne gültige Session-ID nicht verwendet werden.

Einsatz eines Filters

Wo das Anfügen der Session-ID nicht funktioniert, kann stattdessen mit einem Filter gearbeitet werden. Hier sind zugleich bedeutend individuellere Implementierungen von Zugangsbeschränkungen möglich, da eine für eigene Zwecke entwickelte Methode eingesetzt werden kann.

Ein Filter ist stets von der Klasse javax.servlet.Filter abgeleitet und prüft in seiner Methode doFilter alle eingehenden Anfragen. Den programmierten Kriterien entsprechende werden durchgelassen, die restlichen abgewiesen. Ein einfaches Beispiel der Methode doFilter sieht wie folgt aus

  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 
   throws IOException, ServletException {

    if(request instanceof HttpServletRequest) {
      HttpServletRequest hr = (HttpServletRequest) request;
      String token = hr.getParameter("token");
      if("123".equals(token)) {
        chain.doFilter(request, response);       
      } else {
        ServletException ex =  new ServletException("Ungueltiger Token");
        logger.log(Level.INFO, ex.getMessage(), ex);
        throw ex;
      }
    }
  }

Im obigen Beispiel werden alle Streaming-Anfragen beantwortet, wenn sie im URL einen Parameter token=123 enthalten. Fehlt der Parameter oder beinhaltet er einen anderen Wert, werden die Streaming-Anfragen abgewiesen. Freilich kann und sollte anstelle von "123" bei "123".equals im Code ein Methodenaufruf stehen, der den erwarteten Wert für den Token dynamisch liefert. Mit einem solchen Filter würde ein Streaming-URL wie folgt funktionieren.

http://example.com/av/pfad/zum/inhalt.mp3?token=123

Ein Filter wird ebenfalls im Deployment Descriptor, der Datei web.xml konfiguriert

    <filter>
      <filter-name>StreamFilter</filter-name>
      <filter-class>de.uhilger.mc.web.StreamFilter</filter-class>
    </filter>
    <filter-mapping>
      <filter-name>StreamFilter</filter-name>
      <url-pattern>/*</url-pattern>
      <dispatcher>REQUEST</dispatcher>
      <dispatcher>FORWARD</dispatcher>
      <dispatcher>INCLUDE</dispatcher>
      <dispatcher>ERROR</dispatcher>
    </filter-mapping>

Die Filter-Klasse wird dem obigen Beispielt folgend entweder im Verzeichnis WEB-INF/classes oder in [CatalinaHome]/lib abgelegt. Wie bei der Variante mit der Session-ID führt das Erraten oder Herausbekommen des Ablageortes nicht zum Ziel. Nur mit gültigem Token werden Streaming-Anfragen beantwortet.

Fazit

Bei beiden vorgestelleten Varianten kann mit einfachen Mitteln die bestehende Technologie von Java und Tomcat verwendet werden um digitale Audio- und Video-Inhalte per Streaming über HTTP bereit zu stellen. Beliebige Abspielgeräte können die Inhalte wiedergeben und selbst außerhalb des heimischen Netzes  sicher eingesetzt werden. Zentral mit Tomcat bereitgestellte Inhalte bleiben vor unerwünschten Zugriffen geschützt.

Den betreffenden Geräten wird einfach der passende URL nebst gültiger Session-ID bzw. gültigem Token angegeben, was sowohl von Hand als auch maschinell über eine Software erfolgen kann. Die Methode mit Filter wird zum Beispiel vom Gespann Mediacenter und PiRC implementiert.

Es müssen nicht gleich Streaming-Dienste sein, man kann mit freier Software auch ohne fremde Dienste Inhalte sehr gut per Streaming konsumieren. Keine Flatrate, keine Kosten aus "pay per view". Auch die Abhängigkeit von Firmen und die damit einhergehende Preisgabe privater Daten kann so entfallen.