Shibboleth und Opencast 4.x

[Maxime Pedrotti]

Hallo,

Ich probiere mich aktuell an einer Opencast-Installation bei uns und möchte dabei u.a. die Möglichkeit des Logins via Shibboleth nutzen -- leider bisher noch erfolglos.

Mein bisheriges Vorgehen in Kürze:
* Testsystem in einer VM mit Debian 9
* Opencast 4.1 im Profil allinone aus dem Repository (pkg.opencast.org) installiert
* Basiskonfiguration auf Grundlage der offiziellen Dokumentation (https://docs.opencast.org/r/4.x/admin/configuration/basic/) vorgenommen
* Apache 2.4 als Reverse Proxy für SSL/TLS eingerichtet
--> Ein frisches, funktionierendes Opencast 4.1 läuft.
* Shibboleth installiert und konfiguriert
* SP bei meinem IdP registriert
--> Ein Funktionstest mit einem zugriffsgeschützten Verzeichnis auf dem Webserver zeigt, dass ich erfolgreich eine Session initiieren kann und die erforderlichen Attribute vom IdP ausgegeben kriege.
* Anpassungen an der Opencast-Konfiguration laut Dokumentation (https://docs.opencast.org/r/4.x/admin/configuration/security.aai/) vorgenommen
* Webserver und Opencast neu gestartet
--> Beim Aufruf des Servers im Browser erhalte ich statt Opencast oder dem Login beim IdP eine 403-Fehlermeldung von Jetty.

Ich vermute, dass ich noch irgendetwas anpassen muss, komme aber im Moment nicht darauf und hoffe daher auf einen Tipp von Seiten derjenigen, die bereits eine erfolgreiche Shibboleth-Anbindung in Betrieb haben.

Vielen Dank und schöne Grüße,

Maxime

[Sven Stauber]

Hallo Maxime

Wahrscheinlich bekommst Du den 403, weil Du nicht dazu autorisiert bist auf das Admin UI zuzugreifen. Um Shibboleth-Benutzer zu autorisieren, kannst Du Dich im Admin UI anmelden (der Benutzer wird beim Anmelde-Versuch als Seiteneffekt in Opencast erzeugt), und den Benutzer dort in eine Gruppe eintragen.

Das Henne-Ei-Problem kannst Du mit dem Shibboleth Bootstrap Benutzer lösen: Die Shibboleth ID, welche Du bei bootstrap.user.id angebist, bekommt im Wesentlichen ROLE_ADMIN und darf alles mit Opencast machen.

Wie hast Du diesen Bootstrap User aktuell konfiguriert? (bootstrap.user.id=<AAI ID> auf https://docs.opencast.org/r/4.x/admin/configuration/security.aai/)

Grüsse

Sven

[Maxime Pedrotti]

Hallo Sven,

Der Bootstrap User ist eingestellt auf meine eppn, auf eine Zuweisung der entsprechenden Rechte hatte ich gehofft.
Allerdings wird die Session gar nicht initiiert, obwohl ich den entsprechenden Block aus der Doku in meine Apache-Konfiguration übernommen habe. :(

Schöne Grüße,

Maxime

[Sven Stauber]

Hmm... Wenn Du ....

<LocationMatch \.(htm|html)$> AuthType shibboleth ShibRequireSession On ShibUseHeaders On require valid-user </LocationMatch>

...übernommen hast, dann müsstest Du eigentlich auch ohne zutun von Opencast bereits auf den Identity Provider umgeleitet werden - selbst dann, wenn es die Seite gar nicht gibt...

Das passiert nicht, wenn Du eine HTML-Seite auf dem Server aufrufst?

[Maxime Pedrotti]

Genau das dachte ich auch, ist genau so bei mir eingestellt, passiert aber nicht. Sobald ich die Adresse des Servers aufrufe (was ja normalerweise automatisch von Opencast zum Pfad /admin-ng/index.html weiterleitet), zeigt er direkt die Fehlermeldung an. Auch wenn ich von Hand die Adresse zum Admin-Interface aufrufe, wird nicht auf den IdP geleitet, sondern es erscheint der 403.

[Maxime Pedrotti]

Jetzt hat sich das Problem tatsächlich doch durch etwas genaueres Hinsehen geklärt (hoffe ich).

Der letzte Block zu den Security-Einstellungen in der Doku:

<sec:authentication-manager alias="authenticationManager">
  <sec:authentication-provider ref="preauthAuthProvider">
  <sec:authentication-provider user-service-ref="userDetailsService">
    <sec:password-encoder hash="md5"><sec:salt-source user-property="username" /></sec:password-encoder>
  </sec:authentication-provider>
</sec:authentication-manager>

...enthält einen Fehler in Zeile 2, weil das Tag mit dem preauthAuthProvider nicht geschlossen wird. Durch diese fehlerhafte Einstellung wollte das Spring Framework die Konfiguration nicht laden und mich nicht durchlassen. Nachdem ich das bei mir korrigiert hatte, hat Opencast die Session gestartet und mich als Admin akzeptiert.

Vielen Dank trotzdem fürs Mitdenken, auch wenn es nur eine Ungenauigkeit in der Prüfung der Konfiguration meinerseits war.

Schöne Grüße,

Maxime

[Maxime Pedrotti]

Hallo,

Jetzt muss ich doch noch einmal nachfragen, denn heute haben sich zwei neue Probleme aufgetan, und ich bin nicht sicher, ob das ein Fehler im Modul oder in meiner Konfiguration ist.

Drei Phänomene, die ich beobachte:

1. Logout funktioniert anscheinend nicht bzw. leitet lediglich zurück zum Admin-UI, ohne die lokale Session zu beenden.
   
2. Mein Bootstrap User wird nicht in die Datenbank eingetragen, was dazu führt, dass er keinen Zugriff mehr hat, wenn ich den Bootstrap aus der Konfiguration rausnehme.
3. In Verbindung damit: Wenn ich eine valide Shibboleth-Session habe, die auch von Opencast erkannt wird, werde ich nicht wie vorgesehen zum Engage-UI weitergeleitet, sondern erhalte wieder den 403.

Hat hier jemand eine Idee, wo ich nachschauen könnte?

[King_S]

Hallo Maxime,

Zum Logout: Das liegt in der Natur von Shibboleth. Es wird im Browser die Session gespeichert und ein paar Cookies. Diese sind für die gesamte Browsersession gültig, denn nur so ist ein Single Sign on möglich. Abhilfe schafft hier die Konfiguration des Single Logout im Identity Provider, allerdings muss nicht nur der IdP die Session beenden, sondern auch die Anwendung. In wie weit das Opencast kann, weiß ich nicht, muss selbst erst mal das Setup aufsetzen.

Gruß 

Stephan 

--
You received this message because you are subscribed to the Google Groups "Deutschsprachige Opencast Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to anwender+unsubscribe@opencast.org.

[Sven Stauber]

Hallo

1. Mein Bootstrap User wird nicht in die Datenbank eingetragen, was dazu führt, dass er keinen Zugriff mehr hat, wenn ich den Bootstrap aus der Konfiguration rausnehme.

Der Bootstrap User soll wirklich nur das Bootstrapping ermöglichen, damit Du nicht zusätzlich Scripte benötigst, um die Rollen zu setzen. 

Da Du Dich mit dem Bootstrap User auf dem Admin UI anmelden kannst, kannst Du die Rollen, welcher dieser User später haben soll, direkt im Admin UI konfigurieren.

Bei uns machen wir das über Gruppen und tragen dann den Benutzer in die gewünschte Gruppe ein. Du kannst aber dem Benutzer auch direkt Rollen zuweisen.

Grüsse

Sven 

[Maxime Pedrotti]

Hallo,

Vielen Dank für den Hinweis zur Funktionsweise des Bootstrap-Users, damit macht dieses Verhalten auch Sinn! Dann hatte ich die Funktion einfach falsch verstanden, ich dachte, dieser Nutzer würde die Rolle 'ROLE_ADMIN' beim Erstlogin automatisch fest zugewiesen bekommen und könnte sich nach dem Deaktivieren wieder darauf beziehen. Der von dir beschriebene Weg mit der Gruppenzuordnung klingt gut, hat bei mir auch funktioniert, d.h. ich kann jetzt auch ohne Bootstrapping mit meiner Kennung auf die Admin-Oberfläche zugreifen. Damit dürfte mein Punkte 2 wieder erledigt sein (hatte meinen Nutzer in der Datenbank bei 'mh_user' gesucht, beim Login über externe Provider wird wohl in 'mh_user_ref' abgelegt).

Das Beenden der Opencast-Session per Logout ist mir leider trotzdem weiterhin nicht möglich, ich werde immer zurück auf das Admin-UI geleitet, und auch die lokale Shibboleth-Session wird nicht beendet (Punkt 1 bei mir vorhin). Zudem besteht das Problem weiter, dass Nutzer ohne Admin-Rechte nicht auf das Engage-UI weitergeleitet werden, sondern nur den 403 erhalten (Punkt 3).

Ich würde beim Betätigen des Logout im Admin-UI folgendes erwarten:
* Die lokale Opencast-Session wird geschlossen, so dass eine Neuanmeldung (für OC) erforderlich wird.
* Nach erfolgreichem Logout bei Opencast wird durch die Konfiguration im Security-XML (.../etc/security/mh_default_org.xml) der Logout-Handler von Shibboleth aktiviert, bei dem ich auch eine Ziel-URL für nach dem Logout angegeben habe.
* Der Logout wird auch für die Shibboleth-Session an meinem SP durchgeführt, ich werde auf die Zielseite weitergeleitet.
(* Die Shibboleth-Session vom IdP kann ich nicht direkt beeinflussen, dafür müsste in der Tat der Global Logout konfiguriert sein. D.h. solange meine Browsersession offen ist und bis zum Ablauf des Cookies, bleibe ich beim IdP noch angemeldet und kann dadurch transparent beim SP eine neue Session aufmachen.)

Wie ich es beobachte, wird der Logout schon in Opencast nicht richtig ausgelöst, wodurch er gar nicht zum Logout-Handler bei meinem SP kommt.

Zum anderen Punkt (Weiterleitung bei Kennung ohne Admin-Rechte):
Dies sollte eigentlich über das Security-XML mit diesem Block geregelt sein:

  <bean id="authSuccessHandler" class="org.opencastproject.kernel.security.AuthenticationSuccessHandler">
    <property name="securityService" ref="securityService" />
    <property name="welcomePages">
      <map>
        <entry key="ROLE_ADMIN" value="/admin-ng/index.html" />
        <entry key="ROLE_ADMIN_UI" value="/admin-ng/index.html" />
        <entry key="*" value="/engage/ui/index.html" /> <!-- Any role not listed explicitly will redirect here -->
      </map>
    </property>
  </bean>

Die Umleitung hat bei mir allerdings nicht gegriffen, und auch ein direkter Aufruf des Engage-UI hat den 403 gebracht.

Schöne Grüße,

Maxime

[Sven Stauber]

Hallo Maxime

Bei uns klappt das Beenden der Shibboleth-Session, wobei wir dies in der Security Configuration mit folgender Zeile machen:

    <sec:logout logout-success-url="/Shibboleth.sso/Logout?return=http://<whereever_you_want_to_go>" />

Bei uns schützen wir nur die Index Seite:

Apache:

    <Location "/admin-ng/index.html">

        AuthType shibboleth

        ShibRequireSession On

        ShibUseHeaders On

        require valid-user

        Options FollowSymLinks MultiViews ExecCGI

        Order allow,deny

        Allow from all

    </Location>

Opencast Security Configuration:

  <!-- Redirects unauthenticated requests to the login form -->

  <bean id="userEntryPoint" class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint">

    <property name="loginFormUrl" value="/admin-ng/index.html" />

  </bean>

... da wir beim Schutz aller HTML-Seiten irgendwelche Probleme bekommen hatten (schon lange her, weiss nicht mehr genau, was)

Bezüglich dem Redirect auf Engage:

Eigentlich müsste /engage/ui/index.html per default sogar öffentlich zugänglich sein (Vielleicht kriegst Du hier Probleme wegen der Apache Shibboleth Config, welche alle HTML Seite schützt). 

Hast Du die Zeile...

    <sec:intercept-url pattern="/engage/ui/**" access="ROLE_ANONYMOUS" />

... in Deiner Opencast Security Konfiguration?

Es wäre übrigens super, wenn Du Deine Learnings in die Opencast Dokumentation einfließen lassen könntest.

Grüsse

Sven

[Maxime Pedrotti]

Hallo,

Also zumindest in der OC-Konfiguration haben wir das gleiche stehen, sowohl die Anpassung der logout-success-url (leite auf die Startseite meiner Einrichtung) als auch die Änderung der loginFormUrl (index.html statt login.html) habe ich eingestellt.

Ich habe deine Apache-Einstellung bei mir ausprobiert (d.h. jetzt nur die index.html vom Admin-UI geschützt statt allgemein alle HTML-Dokumente):
* Beim Aufruf des Servers werde ich zum IdP-Login geleitet, wie vorgesehen.
* Nutze ich eine Kennung mit Admin-Berechtigung, komme ich wie vorgesehen zum Admin-UI.
* Nutze ich eine Kennung ohne Admin-Berechtigung, will trotzdem automatisch das Admin-UI aufgerufen werden, und ich erhalte den 403.

Das Verhalten beim Logout (über den Button oben rechts mit "Ausloggen") hat sich leider nicht geändert, hier werde ich weiterhin ohne Umwege wieder auf die Startseite vom Admin-UI zurückgeleitet, und alle Sessions bleiben offen.

Immerhin kann jetzt das Engage-UI direkt aufgerufen werden, sowohl mit als auch ohne Login. :)
Der Shibboleth-Login aus dem Engage-UI scheint wohl in der aktuellen Version nicht zu funktionieren, zumindest ist hier bereits ein Bug Report vorhanden (MH-12714).

Schöne Grüße,

Maxime

PS: Eine Rückführung in die Doku hatte ich in jedem Fall vor, soll ja nicht verloren gehen, und vielleicht kann dann jemand seinen Nutzen daraus ziehen, der vor ähnlichen Problemen steht. Ich versuche einen PR dazu, sobald es auf meiner Seite soweit funktioniert. :)

[Sven Stauber]

Engage:

Mit <server>/info/me.json kannst Du die Rollen sehen, welche der aufrufende Benutzer hat. Welche sind das bei Dir für einen Benutzer, welcher auf Engage weitergeleitet werden sollte?

[Maxime Pedrotti]

Hier stehen bei mir folgende Rollen:

roles    
0    "ROLE_AAI_U...@lrz.de"
1    "ROLE_ANONYMOUS"
2    "ROLE_USER_AB34DEF_LRZ_DE"
3    "ROLE_USER"
4    "ROLE_AAI_USER"
5    "ROLE_AAI_ORG_Leibniz Rechenzentrum_MEMBER"
userRole    "ROLE_USER_AB34DEF_LRZ_DE"

(Die Kennung habe ich anonymisiert, das Format der Werte ist aber so, wie es bei mir erscheint.)

[Sven Stauber]

Hmm... da wir selbst Engage nicht im Einsatz haben, kann ich Dir hier nicht wirklich weiterhelfen.

Was ich mir vorstellen könnte ist, dass die Einstellung userEntryPoint.loginFormUrl dazu führt, dass der nicht-authentifizierte Benutzer zuerst auf den IdP umgeleitet wird (wegen Apache Konfiguration), anschließend aber auf die Seite loginFormUrl. So würden die Seiten, welche Du im authSuccessHandler konfiguriert hast (und den Benutzer ohne ROLE_ADMIN/ROLE_ADMIN_UI auf den Engage leiten sollten), gar nie zum Zuge kommen.

Um zu prüfen, ob das so ist, kannst Du beim authSuccessHandler die ROLE_ADMIN auf eine beliebige Webseite weiterleiten und Dich mit einem Benutzer mit ROLE_ADMIN anmelden. Falls diese Weiterleitung nicht geht, wäre mein Verdacht wohl erhärtet.

[Sven Stauber]

Übrigens: Hast Du sichergestellt, dass für das Shibboleth Logout die Requests nicht an Opencast geleitet werden?

    # Do not forward Shibboleth requests

    ProxyPass /shibboleth !

    ProxyPass /Shibboleth.sso !

[Maxime Pedrotti]

Tatsache, der authSuccessHandler wird gar nicht ausgelöst, d.h. die Einstellungen spielen für OC gar keine Rolle, wenn das Admin-UI durch Shibboleth geschützt ist. Das könnte auch insofern Sinn machen, wenn durch das Shibboleth-Handling der eigentliche Login-Mechanismus von OC gar nicht aufgerufen wird, denn dann kann das System auch keinen erfolgreichen Login melden.

Ich könnte mir vorstellen, dass das Problem zumindest verwandt mit dem bereits gemeldeten Bug MH-12714 ist, da hier meinem Verständnis nach das Problem sein dürfte, dass Engage den internen Login von OC verwendet, die Shibboleth-Integration diesen Mechanismus aber umgeht. Ich schaue mir das morgen noch einmal genauer an, werfe auch einen Blick in den Code für den Fall, dass ich daraus schlau werde. Ansonsten würde ich das Problem an den Bug Report dranhängen und/oder einen neuen einreichen.

Vielen Dank schon einmal für die Unterstützung und fürs Mitdenken! :)

Schöne Grüße,

Maxime