Versions Compared

Old Version 3

changes.mady.by.user Ray Lee

Saved on

compared with

New Version Current

changes.mady.by.user Ray Lee

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

CollectionSpace supports integration with single sign-on providers using SAML. Single sign-on can be enabled by adding connection information to a services configuration XML file.

Overview

A typical process for setting up SAML login requires coordination with the administrator of the SAML identity provider (IdP).

  1. Request the metadata URL of the IdP from its administrator. Also communicate the attributes that need to be released (made available) in the SAML response from the IdP. CollectionSpace requires the following attributes:

    • Email address. When a user first logs in using SSO, this is used to associate the user on the IdP to an existing CollectionSpace user account. If no account exists with a username that is equal to the email address, the log in fails. (There is currently no auto-registration feature for users on the IdP that do not have an existing CSpace account.) This can be released as either an attribute or the NameID of the SAML assertion. Ask the administrator of the IdP for the attribute name that will be used (or if it will be the NameID of the assertion).

    • User ID. This should be a persistent identifier used by the IdP to uniquely and permanently identify a user. This can be the same as the user’s email, but only if the user’s email on the IdP is never expected to change. When a user first logs in using SSO, and their CSpace account is successfully located using the email address, this ID is stored, and subsequent logins will be able to associate a user on the IdP to a CSpace user using this ID, even if the user’s email changes on the IdP. This can be released as either an attribute or the NameID of the SAML assertion. Ask the administrator of the IdP for the attribute name that will be used (or if it will be the NameID of the assertion).

    • Full name. The user’s full name. This is not currently used, but will be used in the future to auto-register new CSpace users. Ask the administrator of the IdP for the attribute name that will be used.

  2. Configure SSO for CSpace using the instructions below. Add a relying party registration, setting the metadata URL of the provider to the URL received in Step 1. Configure the locations to probe for the email address and user id, using the information received in Step 1.

  3. Start CollectionSpace.

  4. Provide the metadata URL of the SAML relying party added in step 2 to administrator of the IdP.

  5. The administrator of the IdP communicates that the connection is ready. Test a login. When a SAML assertion is received from the IdP, the NameID and attributes are logged to cspace-services.log. Confirm that the expected NameID and attributes are received.

Creating a file to store local configuration

...

  1. Create the local directory if it does not exist.

  2. Inside that directory, create a file with any name of your choosing, ending with.xml; for example, services-config-sso.xml. This local configuration file will be merged with theservices-config.xml and services-config-security.xml files, found in $CSPACE_JEESERVER_HOME/cspace/config/services. You may add more than one .xml file to the local directory if you want to split your configuration into multiple files. If more than one .xml file is present in local, the files are merged into the configuration in alphabetical order.

  3. Add configuration to your file(s), following the example and instructions below.

Info

Your local configuration is merged with the default configuration files when CollectionSpace starts. For debugging, the output of the merge is written to $CSPACE_JEESERVER_HOME/cspace/config/services/service-config.merged.xml

SAML configuration settings

...

Code Block
languagexml
<?xml version="1.0" encoding="UTF-8"?>

<svc:service-config
    xmlns:svc='http://collectionspace.org/services/config'
    xmlns:merge='http://xmlmerge.el4j.elca.ch'
>
    <security>
        <sso>
            <saml>
                <single-logout />

                <relying-party-registrations>
                    <relying-party id="auth0">
                        <name>Auth0</name>
                        <icon location="https://cdn.auth0.com/manhattan/versions/1.4478.0/assets/badge.png" />
                        <metadata location="https://dev-vynkcnqhac3c0s10.us.auth0.com/samlp/metadata/aiXoltFSsQymeHorBxWM5pGLxnslocpe" />

                        <assertion-username-probes>
                            <attribute name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" />
                        </assertion-username-probes>

                        <assertion-sso-id-probes>
                            <name-id />
                            <attribute name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" />
                        </assertion-sso-id-probes>

                        <signing-x509-credentials>
                            <x509-credential>
                                <private-key location="file:///home/collectionspace/tomcat/cspace/services/credentials/private.key" />
                                <x509-certificate location="file:///home/collectionspace/tomcat/cspace/services/credentials/certificate.crt" />
                            </x509-credential>
                        </signing-x509-credentials>

                        <decryption-x509-credentials>
                            <x509-credential>
                                <private-key location="file:///home/collectionspace/tomcat/cspace/services/credentials/private.key" />
                                <x509-certificate location="file:///home/collectionspace/tomcat/cspace/services/credentials/certificate.crt" />
                            </x509-credential>
                        </decryption-x509-credentials>
                    </relying-party>
                </relying-party-registrations>
            </saml>
        </sso>
    </security>
</svc:service-config>

...

Registers SAML relying parties. A relying-party in this configuration file can be thought of as a connection between CollectionSpace and a SAML identity provider.

...

The required id attribute specifies a registration ID that must be unique among all relying parties.

This ID appears in the URLs of CSpace REST API endpoints; for . For readability, it is recommended to use only URL-friendly characters.

...

The user-friendly name of the connection. This is used in the user interface, so it should be human readable, and familiar to end-users of the identity provider. The metadata provided by an IdP sometimes contains a suitable name, but this setting currently is not automatically configured from the metadata.

If the name element is not present, the id is displayed in the user interface.

icon

An icon (logo) image to use in the user interface for this connection. The metadata provided by an IdP sometimes contains a suitable image, but this setting currently is not automatically configured from the metadata.

The required location attribute contains the URL of the image. This may be a file:// URL, if the image can be found in a local file.

If the icon element is not present, a default icon is displayed in the user interface.

metadata

The XML-formatted metadata provided by the SAML identity provider.

The required location attribute contains the URL of the metadata. This may be a file:// URL, if the metadata can be found in a local file.

assertion-username-probes

A list of locations in a SAML assertion returned by the identity provider to look for the username of a CollectionSpace user. A location is either an attribute in the assertion or the NameID of the assertion. Each location is probed in the order given. If it contains something that looks like an email address, an attempt is made to locate a CSpace user whose username is equal to that email. Once a user is found, probing of locations stops.

name-id

Specifies that the NameID of the assertion is a possible location of the email/username.

attribute

Specifies that an attribute in the assertion is a possible location of the email/username. The required name attribute specifies the name of the attribute in the assertion.

Defaults to:

<name-id />

<attribute name="urn:oid:0.9.2342.19200300.100.1.3" />

<attribute name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" />

<attribute name="email" />

<attribute name="mail" />

assertion-sso-id-probes

A list of locations in a SAML assertion returned by the identity provider to look for the SSO ID of a CollectionSpace user (the persistent ID of the user in the identity provider). A location is either an attribute in the assertion or the NameID of the assertion. Each location is probed in the order given. Once a non-null value is found, probing stops.

name-id

Specifies that the NameID of the assertion is a possible location of the SSO ID.

attribute

Specifies that an attribute in the assertion is a possible location of the SSO ID. The required name attribute specifies the name of the attribute in the assertion.

Defaults to:

<name-id />

signing-x509-credentials

A list of credentials to use for signing SAML requests issued by CollectionSpace. Typically, you will only specify a single credential (private key and certificate pair). A credential is required if the identity provider requires login requests to be signed (as reported in its metadata), or if single logout is enabled. Otherwise, signing credentials are optional.

...

The private key to be used for signing. The key can either be specified in the content of the element, or as a URL.

Note

If the private key is entered as content, be sure to treat this configuration file as a secret.

If the key is not set as the content of the element, use the location attribute to specify the URL where the key can be found. This may be a file:// URL, if the key can be found in a local file.

For an example, see: https://github.com/spring-projects/spring-security-samples/blob/5.8.x/servlet/xml/java/saml2/login-logout/src/main/resources/credentials/rp-private.key

x509-certificate

The certificate to be used to validate a document signed with the private key. The certificate can either be specified in the content of the element, or as a URL.

If the certificate is not set as the content of the element, use the location attribute to specify the URL where the certificate can be found. This may be a file:// URL, if the certificate can be found in a local file.

For an example, see: https://github.com/spring-projects/spring-security-samples/blob/5.8.x/servlet/xml/java/saml2/login-logout/src/main/resources/credentials/rp-certificate.crt

decryption-x509-credentials

A list of credentials to use for encrypting and decrypting SAML assertions issued by the IdP. Typically, you will only specify a single credential (private key and certificate pair). A credential is required if the identity provider requires its assertions to be encrypted. Otherwise, decryption credentials are optional. The content of decryption-x509-credentials has the same structure as signing-x509-credentials, but the decryption and signing credentials may differ.

Retrieving CollectionSpace SAML Metadata

Restart the CollectionSpace server to activate your SSO configuration. CollectionSpace SAML metadata for a configured relying party can be retrieved from the REST API at:

/cspace-services/saml2/service-provider-metadata/{id}

(Replace {id} with the value of the id attribute of the relying-party in your configuration).

This URL can be provided to the administrator of the SAML identity provider in order to complete the connection.