AAI-Login für Nextcloud

Nextcloud bringt eine eigene SAML-Erweiterung mit, die aber nur zur Anbindung eines einzigen IdPs geeignet ist. Glücklicherweise hat diese Erweiterung aber einen Modus in dem per CGI-Environment-Variablen Authentifiziert wird. Damit wird die Authentifizierung an den Apache ausgelagert und dadurch kann die Shibboleth-SP-Software als Apache-Authentifizierungsmethode verwendet werden.

Vorteile und Besonderheiten:

• für die 'normalen' User verwaltet Nextcloud keine lokalen Passwörter mehr
• nur der initiale NC-Admin kann sich nach wie vor mit einem lokalen Passwort anmelden, muss dazu aber eine spezielle URL nehmen:

  https://myvhost.mydomain.de/index.php/login?direct=1

• neue AAI-User werden automatisch angelegt. Will man nicht alle AAI-User zulassen muss ausserhalb von Nextcloud eine Einschränkung realisiert werden:
  • idealerweise über eine Attribute-Authority per SAML-Attribut (typischerweise „eduPersonEntitlement“)
  • alternativ als Userliste im Apache (nur praktikabel bei wenigen statischen Usern)
• für jeden nicht-Browser-Client muss der User selber per initialem Browser-AAI-Login ein Security-Token erstellen

• das DocRoot im Apache zeigt direkt auf die Nextcloud-Installation (also kein „/nextcloud“ oder anderer Pfad in der URL zur Nextcloud-Installation!)
• das Nextcloud-Feature Pretty URLs ist deaktiviert! D.h. falls die Variable 'htaccess.RewriteBase' in ./config/config.php enthalten sein sollte, löschen Sie diese und generieren Sie die .htacces-Datei neu wie in der Nextcloud-Dokumentation beschrieben.

• als Nextcloud-Admin einloggen
• unter „+Apps“ –> „Integration“ die Erweiterung „SSO & SAML authentication“ aktivieren
• unter „Settings“ –> „Administration“ –> „SSO & SAML authentication“ die Alternative „Use Environment variable“ auswählen
• „Only allow authentication if…“ NICHT auswählen
• General –> „REMOTE_USER“ eintragen (sollte korrekt vorbelegt sein)
• „Attribute mapping“ –> „Show attribute mapping settings…“
  • erstes Feld „displayName“ eintragen (sollte korrekt vorbelegt sein)
  • zweites Feld „mail“ eintragen (sollte korrekt vorbelegt sein)

Folgende Attribut-Mappings aktivieren falls nicht schon per Default aktiv:

/etc/shibboleth/attribute-map.xml

    <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/>
    </Attribute>
 
    <Attribute name="urn:oid:2.16.840.1.113730.3.1.241" id="displayName"/>
 
    <Attribute name="urn:oid:0.9.2342.19200300.100.1.3" id="mail"/>
 

Nicht vergessen diese drei Attribute in der DFN-AAI-Metadatenverwaltung als „required“ anzugeben, damit sie von den Idps freigeben werden!

Kontrollieren, dass „eppn“ als erstes/primäres Attribut an REMOTE_USER zugewiesen wird:

/etc/shibboleth/shibboleth2.xml

   <ApplicationDefaults entityID="https://myvhost.mydomain.de/shibboleth"
        REMOTE_USER="eppn subject-id pairwise-id persistent-id"
 

root@host:~# systemctl restart shibd

• der lokale Admin-Login wird aus Sicherheitsgründen eingeschränkt.
• nur die Login-Seite wird per Shibboleth geschützt (siehe https://github.com/nextcloud/user_saml/issues/243):

/etc/apache2/sites-available/VHOST.conf

# local Admin-Login nicht von weltweit!
<Location /index.php/login>
    Require ip xxx.xxx.xxx.xxx/xx
</Location>
# SAML/SSO-Login auf AAI konfigurieren
<Location /index.php/apps/user_saml/saml/login>
   AuthType           shibboleth
   ShibRequestSetting requireSession true
   <RequireAll>
     Require shib-attr  eppn        ~ ^.+$
     Require shib-attr  displayName ~ ^.+$
     Require shib-attr  mail        ~ ^.+@.+$
     Require valid-user
   </RequireAll> 
</Location>

Hier sieht man an der Location „/index.php/…“ dass die Nextcloud-Installation direkt im DocumentRoot des Vhosts liegt und das Nextcloud-Feature „Pretty URLs“ deaktiviert ist. Sollte jemand Erfolg haben „Pretty URLs“ mit dem AAI-Login in Einklang zu bringen freuen wir uns über eine Rückmeldung!

root@host:~# systemctl reload apache2

Damit wird ein AAI-Login möglich und (sofern der Nutzer die geforderten drei Attribute mitbringt) automatisch ein Nextcloud-Account angelegt.

• die Einschränkung des Nutzerkreises erfolgt typischerweise mithilfe des Berechtigungsattributes („entitlement“) welches z.B. aus einer Attribute-Authority kommen kann.
• im Folgenden ersparen wir uns aber das aufwändige Aufsetzen einer Attribute Authority und gehen davon aus dass der Userkreis klein und recht statisch ist. Der Userkreis kann dann ganz einfach mithilfe eine User-Liste im Apache eingeschränkt werden.
• in jedem Fall muss unbedingt eine verständliche Fehlerseite konfiguriert werden, welche dem abgelehnten User eine Erklärung gibt.

/etc/apache2/sites-available/VHOST.conf

# local Admin-Login nicht von weltweit!
<Location /index.php/login>
    Require ip xxx.xxx.xxx.xxx/xx
</Location>
# SAML/SSO-Login auf AAI konfigurieren
<Location /index.php/apps/user_saml/saml/login>
   AuthType           shibboleth
   ShibRequestSetting requireSession true
   <RequireAll>
     Require shib-attr  eppn        ~ ^.+$
     Require shib-attr  displayName ~ ^.+$
     Require shib-attr  mail        ~ ^.+@.+$
     Require user       userX@hochschule-ab.de userY@hochschule-cd.de ...
   </RequireAll>
   ErrorDocument 401 /info.php
</Location>
 
# die Error-Seite muss auch einen Shibboleth-Context haben damit
# dort die SAML-Attribute im CGI-Environment auftauchen!
Alias /info.php /srv/www/vhosts/myvhost.mydomain.de/info.php
<Location /info.php>
    AuthType           shibboleth
    ShibRequestSetting requireSession true
    Require            valid-user
</Location>

root@host:~# systemctl reload apache2

Einen Vorschlag für eine Error/Info-Seite „info.php“ sowie die relevanten EDS-Dateien im Nextcloud-Design können Sie als zip-File downloaden:

dfn-aai-nextcloud-18.0.3-layout.zip

Diese Dateien müssen noch an Ihre Installation angepasst werden:

• idpselect_config.js: Namen Ihres Servers eintragen, damit der EDS nicht seine Arbeit verweigert, siehe SP Installationsanleitung!
• index.html, info.php: Kontakt- und Datenschutz-Links anpassen

Bei der hier beschriebenen Konfiguration überlässt die Nextcloud-Software die Autentifizierung dem Webserver. Genauso müsste das Logout nicht mehr nur von Nextcloud selber gemacht werden sondern es sollte nach dem Beenden der Nextcloud-Session eine Weiterleitung zu einer SSO-Logout-Location geben. Leider kann man das im Moment noch nicht konfigurieren, es wurde aber immerhin schon angeregt.

Wer nicht auf die Nextcloud-Entwickler warten will kann es prinzipiell auch selber implementieren da der Logout vom Shibboleth-SP übernommen werden kann. Getriggert wird das Single-Logout durch Aufruf der Location

 https://myvhost.mydomain.de/Shibboleth.sso/Logout

: wie baut man das in die Nextcloud-Oberfläche ein?

: wie kann dabei die Nextcloud-Session mit beendet werden?

Dabei wird ein Single-Logout getriggert, d.h. der User wird nicht nur vom Nextcloud-Dienst abgemeldet sondern auch von allen anderen AAI-Diensten an denen er in diesem Moment eingelogged ist. Daher sollte unbedingt eine Nachfrage mit entsprechendem Hinweis an den User gestellt werden bevor das Logout aktiviert wird.

: wie sieht so ein Code aus?

Hier ist ein Logout im Zusammenspiel mit CAS beschrieben, analog liesse sich vermutlich auch ein AAI-Single-Logout verwirklichen.

IdPs welche die Attribut-Infos in den DFN-AAI-Metadaten nicht auswerten müssen drei Attribute manuell freigeben:

/opt/shibboleth-idp/conf/attribute-filter.xml

<AttributeFilterPolicy id="mydomain-nextcloud">
 
     <PolicyRequirementRule xsi:type="Requester" value="https://myvhost.mydomain.de/shibboleth" />
 
     <AttributeRule attributeID="eduPersonPrincipalName" permitAny="true"/>
     <AttributeRule attributeID="mail"                   permitAny="true"/>
     <AttributeRule attributeID="displayName"            permitAny="true"/>
 
</AttributeFilterPolicy>