Some of the typical authentication options offered by Goobi workflow are documented below. In addition to authentication using the user passwords stored in the database, you can also use LDAP, Active Directory, CAS, SAML and OpenID. Some of these application scenarios are described here.
HTTP header authentication reads an HTTP header in the request and checks if there is a user whose SSO-ID matches the content of the header. If there is a user, he will be logged in. As HTTP headers can be set very easily, this authentication should only be used if Goobi workflow can only be accessed via an upstream web server (e.g. Apache2 or nginx) and this server handles the actual authentication. To use this authentication, the following switches must be set in the goobi_config.properties configuration file:
The functionality is switched on with EnableHeaderLogin, the parameter SsoHeaderName defines the name of the header to be read out. The configuration key showSSOLogoutPage enables a redirect to a logout page, so the user is not logged in directly after logging out.
In addition, the login endpoint must be activated in the API. To do this, a new entry is created in the goobi_rest.xml:
An example setup with an Apache2 web server and CAS single sign on could be performed as follows:
First Apache2 and the CAS module must be installed.
The CAS module assumes that some directories exist and that the Apache2 process has access to these directories:
Finally, the configuration for the Apache2 web server must be adjusted so that the module is loaded and the correct upstream header is set:
This example setup uses mod_auth_melon to implement authentication using SAML services and the Goobi workflow header login. Here we use the entityID https://mygoobi.tld/mygoobisp/ for our new service provider to be set up and assume that our server can be reached under the domain mygoobi.tld. The Goobi to be secured can then be reached under the URL https://mygoobi.tld/goobi/.
First of all, Apache2 and mod_auth_melon should be installed:
Next, the service provider metadata should be generated along with the private key and certificate. There is a handy script for this in the mod auth mellon repository:
https://github.com/latchset/mod_auth_mellon/blob/master/mellon_create_metadata.sh
This script expects two parameters, the entityID of our service provider, and the URL under which the SAML endpoints of the service provider can be reached:
The command generates a private key, a certificate and the metadata for the service provider.
In the Apache2 configuration, the auth module must now be loaded and two Locations must be created:
The first Location is the global mellon configuration where we configure the metadata for the identity provider and the service provider. The second Location is the Goobi application to be protected. Here we configure the Authtype to Mellon and require a valid user. Goobi workflow then uses the ssoid header to identify users as described above.
With database authentication, users are managed entirely by Goobi workflow itself. The user name and password are stored in the Goobi database. Within the database, only a hash (sha256 & salt) of the password is stored and compared with the user password entered at login.
OpenID Connect 1.0 is an authentication layer based on the OAuth 2.0 protocol. It enables clients to obtain the end user's identity from an authentication provider in a REST-like manner.
Goobi workflow can function and be configured as an OpenID Connect Client. During implementation, particular care was taken to ensure that as many OpenID Connect providers as possible can be addressed. For this reason, the settings in goobi_config.properties are relatively complex.
In addition, the login endpoint must be activated in the API. To do this, a new entry is created in the goobi_rest.xml:
With these settings, a user will be redirected to the authentication provider's page the first time they visit Goobi workflow. There, the user is either already logged in and is redirected back to Goobi workflow or he or she must first log in and is then redirected to Goobi workflow.
Once the user has been forwarded, Goobi checks the authentication provider's reply for validity and searches for a user with an SSO-ID that matches the email claim from the OpenID Connect reply. If a user can be found, he or she is then logged in.