Page History

...

# Enable OIDC
plugin.sequence.org.dspace.authenticate.AuthenticationMethod = org.dspace.authenticate.OidcAuthentication

# Settings for OIDC authentication
# Based on instructions at https://www.phantauth.net/doc/integration
authentication-oidc.authorize-endpoint = https://phantauth.net/auth/authorize
authentication-oidc.token-endpoint = https://phantauth.net/auth/token
authentication-oidc.user-info-endpoint = https://phantauth.net/auth/userinfo

# Obtain a random client-id and client-secret via https://phantauth.net/client
# Find the "client_id" and "client_secret" returned, and place those values in these next two configs.
authentication-oidc.client-id = 
authentication-oidc.client-secret = 

# Because PhantAuth uses random users, you MUST ensure self registration is enabled 
# (This is the default setting though, which is why it's commented out)
# authentication-oidc.can-self-register = true

SAML (Security Assertion Markup Language) Authentication

Enabling SAML Authentication

To enable SAML Authentication, you must ensure the org.dspace.authenticate.SamlAuthenticationclass is listed as one of the AuthenticationMethods in the following configuration:

Configuring SAML Authentication

SAML (Security Assertion Markup Language) is an XML based standard for transferring identity information between entities, in particular an identity provider (IdP) and a service provider (SP). The former performs authentication and transmits user identity data to the latter, the system the user is attempting to access. The SAML Authenication plugin configures DSpace to operate as a SAML service provider interacting with an external identity provider. There are many SAML IdP server implementations, including open source and enterprise options from major cloud and SAAS providers.

Note: SAML configuation can be simple, but in some cases may require a lot of configuration. In addition to the settings summarized here if you are having trouble setting up a SAML intregration it is recommended you review the documentation provided in the source code. It may also be helpful to refer to the feature submission details: https://github.com/DSpace/DSpace/pull/9470

https://github.com/DSpace/DSpace/blob/main/dspace/config/modules/authentication-saml.cfg

https://github.com/DSpace/DSpace/blob/main/dspace/config/modules/saml-relying-party.cfg

Note: for the saml-relying-party.cfg settings replace RELYING-PARTY-ID with the value of authentication-saml.relying-party-id.

Sample/Test SAML Configuration

One way to test SAML authentication is to sign up for a free account with a service like Auth0. They provide documentation on how to create a SAML Identity Provider. However, you can use any SAML IdP and there are many available.

To configure DSpace to use SAML for authentication (with auth0 as an example) requires this minimal configuration:

# Enable SAML
plugin.sequence.org.dspace.authenticate.AuthenticationMethod = org.dspace.authenticate.SAMLAuthentication
authentication-saml.relying-party-id = auth0 # refer to our IdP as "auth0" in our configuration

# Settings for SAML authentication (note the use of "auth0" in the replying-party configuation properties)
saml-relying-party.auth0.asserting-party.metadata-uri = https://dev-vynkcnqhac3c0s10.us.auth0.com/samlp/metadata/Vn8jWX0iFHtepmXi7rjZa9h5M1kqXNWY

saml-relying-party.auth0.attributes = \
  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress => org.dspace.saml.EMAIL, \
  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname => org.dspace.saml.GIVEN_NAME, \
  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname => org.dspace.saml.SURNAME

# Add the IdP url to the list of allowed origins
rest.cors.allowed-origins = ${dspace.ui.url},https://dev-vynkcnqhac3c0s10.us.auth0.com

In general when setting up a SAML integration the flow will go something like:

1. The administrator of the IdP provides a URL to the metadata for the IdP.
2. Configure a new relying party in DSpace, setting asserting-party.metadata-uri to the IdP's metadata URL.
3. If encryption and/or signing are desired/required by the IdP, configure private keys and certificates into the relying party.
4. Ask the administrator of the IdP to release the user's email, first name, and last name as attributes, and ask what the names of those attributes will be. Configure the relying party's attributes property, to map those attribute names to org.dspace.saml.EMAIL, org.dspace.saml.GIVEN_NAME, and org.dspace.saml.SURNAME.
5. Start DSpace, and provide the relying party's metadata URL (/server/saml2/service-provider-metadata/{id}) to the administrator of the IdP, so they can use it to configure their side. Alternatively, retrieve the metadata, and provide it to the administrator of the IdP through another channel.
6. The administrator of the IdP says that the configuration is complete. Testing can commence.

Shibboleth Authentication

...