Add support for SAML authentication

[ray-lee]

Is your feature request related to a problem? Please describe.
DSpace doesn't natively support authentication using SAML single sign-on.

Describe the solution you'd like
Add a DSpace authentication plugin that provides native support for SAML single sign-on.

Describe alternatives or workarounds you've considered
Single sign-on with SAML IdPs is currently possible via the Shibboleth authentication plugin. However, this is a relatively heavyweight solution that requires additional infrastructure (Apache), adding complexity to deployment, configuration, and maintenance of a DSpace system. This is especially true for hosted DSpace services with many clients.

Additional context
I'm working on a PR for this.

In concept, this will be pretty similar to Shibboleth authentication. Shibboleth intercepts requests to certain URLs, and handles the details of communicating with an IdP. Once a user has been authenticated with an IdP, Shibboleth issues an HTTP request to the Shibboleth-specific authentication endpoint in DSpace, sending the authenticated user details in request headers. The Shibboleth authentication plugin on the DSpace side reads the headers, and attempts to associate those user details to a registered DSpace user. If successful, the user is logged in.

With this in mind, here's what I'm thinking:

1. Add a dspace-saml2 module.

The dspace-saml2 module implements a SAML 2 relying party service. A relying party can be thought of as a SAML "client" (but it's really also a server — in any case, it's the thing that knows how to "speak" SAML), and serves more-or-less the same purpose as Shibboleth, handling the details of communicating with an identity provider (aka IdP, aka asserting party).

Like the other optional API providers (e.g., dspace-iiif, dspace-oai, dspace-rdf), the dspace-saml2 module can easily be removed from the build if SAML support isn't needed.

The module is implemented using spring-security-saml2-service-provider (Apache License, Version 2.0).

dspace-saml2 lives at /server/saml2, and provides the following endpoints:

• /server/saml2/service-provider-metadata/{relying_party_id}
  Produces metadata about the relying party. This URL can be provided to the administrator of the IdP to simplify setup.
• /server/saml2/authenticate/{relying_party_id}
  Initiates a login with the IdP.
• /server/saml2/assertion-consumer/{relying_party_id}
  Receives the identity assertion from the IdP after a user has successfully authenticated with the IdP.

As suggested by the above endpoint paths, multiple relying parties can be configured in dspace-saml2, for example, to connect to different IdPs. However, for the initial implementation, only one relying party will be connected to the user interface (i.e., there will only be one "Log in with SAML" option that initiates a log in with a configurable relying party, vs. many "Log in with SAML at {institution name}" options).

When a user has authenticated with an IdP, dspace-saml2 will extract attributes from the identity assertion it receives, including the Name ID (in SAML-speak, this corresponds to what DSpace calls a NetID), the user's email, first and last names, and other attributes, as configured. These values will be placed into request attributes.

The mapping of SAML assertion attributes to request attributes will be configurable for each relying party, because different IdPs may have different names for the attributes in their assertions. This mapping step normalizes the varying attribute names in the SAML assertions to canonical names in the request attributes.

The request is then forwarded to the SAML authentication endpoint. As opposed to Shibboleth, which has to issue an actual HTTP request over the network and send user information in headers, dspace-saml2 can issue an internal servlet request forward, and send user information in request attributes, since the same request object will be received by the authentication endpoint.

Example configuration for SAML relying parties is located in saml-relying-party.cfg.

2. Add a SAML authentication plugin.

Like other authentication plugins, this is comprised of multiple parts:

• SamlLoginFilter
  A StatelessLoginFilter that listens for requests to /server/api/authn/saml, and attempts to authenticate a user from information in the request, using SamlAuthentication.
• SamlAuthentication
  An AuthenticationMethod that looks for SAML authenticated user details in the request attributes, and attempts to associate those details to a registered DSpace user. This is very similar to ShibAuthentication, except it expects the user details to be in request attributes instead of headers. The algorithm for finding a DSpace user from the user details is identical.
• authentication-saml.cfg
  Configuration of the SAML authentication method, including the names of the request headers to look for, whether or not to autoregister non-existent users, and additional request header to EPerson metadata mappings.