Bei der Datenbank-Authentifizierung werden die Benutzer komplett von Goobi workflow selbst verwaltet. Nutzername und Passwort werden in der Goobi-Datenbank gespeichert. Innerhalb der Datenbank wird von dem Passwort lediglich ein Hash (sha256 & salt) gespeichert und für den Vergleich mit dem eingegebenen Nutzerpasswort beim Login verglichen.

Im Folgenden sollen einige der typischen Authentifizierungsmöglichkeiten von Goobi workflow dokumentiert werden. Zur Auswahl steht neben der Authentifizierung mittels der in der Datenbank gespeicherten Passwörter der Nutzer auch die Nutzung von LDAP, Active Directory, CAS, SAML und OpenID. Einige dieser Anwendungsszenarien sind hier beschrieben.

Die HTTP-Header Authentifizierung liest einen HTTP-Header in der Anfrage aus, und überprüft ob es einen Nutzer gibt, bei dem die SSO-ID mit dem Inhalt des Headers übereinstimmt. Sollte es den Nutzer geben, wird er eingeloggt. Da HTTP-Header sehr leicht gesetzt werden können, sollte diese Authentifizierung nur benutzt werden, wenn Goobi workflow nur über einen vorgelagerten Webserver (zum Beispiel Apache2 oder nginx) erreichbar ist, und dieser die eigentliche Authentifizierung übernimmt. Um diese Authentifizierung zu nutzen, müssen in der Konfigurationsdatei goobi_config.properties folgende Schalter gesetzt sein:

EnableHeaderLogin=true
SsoHeaderName=ssoid
showSSOLogoutPage=true

Dabei wird mittels EnableHeaderLogin die Funktionalität eingeschaltet, mit dem Parameter SsoHeaderName wird der Name des auszulesenden Headers festgelegt. showSSOLogoutPage sorgt dafür, dass beim Logout eine Zwischenseite angezeigt und der Nutzer nicht direkt wieder neu eingeloggt wird.

Außerdem muss noch der login endpoint in der API freigeschaltet werden. Dazu wird ein neuer Eintrag in der goobi_rest.xml angelegt:

<endpoint path="/login/header">
    <method name="get">
        <allow />
    </method>
</endpoint>

Beispielkonfiguration für CAS mittels Apache2

Eine Beispiel-Einrichtung mit einem Apache2 Webserver und CAS single sign on könnte folgendermaßen durchgeführt werden:

Zuerst müssen Apache2 und das CAS-Modul installiert werden.

apt install apache2 libapache2-mod-auth-cas libcurl4 libpcre3

Das CAS-Modul setzt voraus, dass einige Verzeichnisse existieren und der Apache2-Prozess auf diese Verzeichnisse Zugriff hat:

mkdir -p /var/cache/httpd/mod_auth_cas/ && chown daemon /var/cache/httpd/mod_auth_cas/

Abschließend muss noch die Konfiguration für den Webserver Apache2 angepasst werden, damit das Modul geladen und der richtige upstream-Header gesetzt wird:

# load the CAS module
LoadModule auth_cas_module /usr/lib/apache2/modules/mod_auth_cas.so

<IfModule unixd_module>
# configure CAS
CASCookiePath /var/cache/httpd/mod_auth_cas/
CASLoginURL https://your.cas.service.tld/cas/login
CASValidateURL https://your.cas.service.tld/cas/serviceValidate
</IfModule>

# ProxyPass to Goobi...
ProxyPass "/goobi/" "http://localhost:8080/goobi/"
ProxyPassReverse "/" "http://localhost:8080/goobi/"

# ...and protect the location with CAS
<Location /goobi/>
  Authtype CAS 
  # this is the name of the header you need to set in the Goobi configuration
  CASAuthNHeader ssoid
  require valid-user
</Location>

Beispielkonfiguration für SAML mittels Apache2 und mod_auth_melon

Diese Beispiel-Einrichtung nutzt mod_auth_melon, um eine Authentifizierung mittels SAML Diensten und dem Goobi workflow header login umzusetzen. Hierbei nutzen wir für unseren neu einzurichtenden service provider die entityID https://mygoobi.tld/mygoobisp/ und nehmen an, dass unser Server unter der Domain mygoobi.tld zu erreichen ist. Das abzusichernde Goobi ist dann unter der URL https://mygoobi.tld/goobi/ zu erreichen.

Als erstes sollten Apache2 und mod_auth_melon installiert werden:

apt install apache2 libapache2-mod-auth-mellon

Als nächstes sollten die Service Provider Metadaten mitsamt des privaten Schlüssel und des Zertifikats erzeugt werden. Dazu gibt es im mod auth mellon repository ein praktisches Script:

https://github.com/latchset/mod_auth_mellon/blob/master/mellon_create_metadata.sh

Dieses Script erwartet zwei Parameter, die entityID unseres service provider, sowie die URL unter der die SAML endpoints des Service Provider erreicht werden können:

./mellon_create_metadata.sh "https://mygoobi.tld/mygoobisp/" "https://mygoobi.tld/mellon"

Der Befehl erzeugt einen privaten Schlüssel, ein Zertifikat sowie die Metadaten für den service provider.

In der Apache2 Konfiguration muss nun das auth-Modul geladen werden, sowie zwei Locations angelegt werden:

LoadModule auth_mellon_module /usr/lib/apache2/modules/mod_auth_mellon.so


# ProxyPass to Goobi...
ProxyPass "/goobi/" "http://localhost:8080/goobi/"
ProxyPassReverse "/" "http://localhost:8080/goobi/"

<Location />
    MellonEnable "info"
    MellonEndpointPath "/mellon/"
    
    # This needs to be configured in the Goobi workflow configuration as 
    # SsoHeaderName=ssoid
    MellonSetEnvNoPrefix "ssoid" "mail"

    # needs to be obtained from the identity provider
    MellonIdPMetadataFile /etc/apache2/mellon/idp-metadata.xml
    
    # the next three files were created my the 
    # mellon_create_metadata.sh script mentioned above
    MellonSPMetadataFile /etc/apache2/mellon/sp-metadata.xml
    MellonSPPrivateKeyFile /etc/apache2/mellon/sp.key
    MellonSPCertFile /etc/apache2/mellon/sp.cert
</Location>

<Location /goobi/>
    Authtype "Mellon"
    Require valid-user
    MellonEnable "auth"
</Location>

Die erste Location ist die globale mellon Konfiguration, in der wir die Metadaten für den identity provider und den service provider konfigurieren. Die zweite Location ist die zu schützende Goobi-Anwendung. Hier konfigurieren wir den Authtype zu Mellon und verlangen nach einem validen Nutzer. Goobi workflow nutzt dann wie oben beschrieben den ssoid header, um Nutzer zu identifizieren.

OpenID Connect 1.0 ist eine Authentifizierungsschicht basierend auf dem OAuth 2.0-Protokoll. Sie ermöglicht es den Clients, die Identität des Endbenutzers auf REST-ähnliche Weise von einem Authentifizierungs-Anbieter zu erhalten.

Goobi workflow kann als OpenID Connect Client fungieren und konfiguriert werden. Bei der Implementierung wurde besonders darauf geachtet, dass möglichst jeder OpenID Connect Anbieter angesprochen werden kann. Aus diesem Grund sind die Einstellungen in der goobi_config.properties relativ komplex:

# use OpenID Connect
useOpenIdConnect=true

# set this to true and the user will be redirected automatically to the OpenID Connect login provider
OIDCAutoRedirect=true

# the authorization endpoint for OpenID Connect
OIDCAuthEndpoint=https://myopenidconnect.tld/oauth2/v2.0/authorize

# the logout endpoint
OIDCLogoutEndpoint=https://myopenidconnect.tld/oauth2/logout

# the issuer uri
OIDCIssuer=https://myopenidconnect.tld/v2.0

# The JWK set. Goobi will automatically fetch the set and verify the response from the openid server
OIDCJWKSet=https://myopenidconnect.tld/discovery/keys

# the client ID configured for Goobi in you openid connect backend
OIDCClientID=the-client-id-for-goobi

# the claim that is matched against the ssoId field in the Goobi users database
OIDCIdClaim=email

# redirect to a "you are logged out" page after logout, so you are not logged in right after logging out
showSSOLogoutPage=true

Außerdem muss noch der login endpoint in der API freigeschaltet werden. Dazu wird ein neuer Eintrag in der goobi_rest.xml angelegt:

<endpoint path="/login/openid">
    <method name="post">
        <allow />
    </method>
</endpoint>

Mit diesen Einstellungen wird ein Nutzer beim ersten Besuch von Goobi workflow auf die Seite des Authentifizierungs-Providers weitergeleitet. Dort ist der Nutzer entweder schon eingeloggt und wird direkt wieder zu Goobi workflow zurück weitergeleitet oder er muss sich zunächst einloggen und wird daraufhin weitergeleitet zu Goobi workflow.

Nach der Durchführung der Weiterleitung des Nutzers überprüft Goobi die Antwort des Authentifizierungs-Providers auf Validität und sucht nach einem Nutzer mit einer SSO-ID, die mit dem email-Claim aus der OpenID Connect Antwort übereinstimmt. Kann ein Nutzer gefunden werden, wird dieser anschließend eingeloggt.