Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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.

Creating a file to store local configuration

Your configuration file should be placed in the $CSPACE_JEESERVER_HOME/cspace/config/services/local directory on the CollectionSpace server.

  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.

SAML configuration settings

Your merged XML file must conform to the XML schema at https://github.com/collectionspace/services/blob/v8.0-branch/services/config/src/main/resources/service-config.xsd . That schema defines the security/sso/saml element that contains the configuration for SAML SSO.

The following example shows a typical SSO configuration file:

<?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" />

                        <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>
                    </relying-party>
                </relying-party-registrations>
            </saml>
        </sso>
    </security>
</svc:service-config>

The merge result can be fine tuned by adding attributes from the merge namespace defined in the example. In most cases, the default merge behavior (no merge attributes, as above) is sufficient. See the XmlMerge documentation for details.

Some important elements inside saml include:

single-logout

The presence of this element enables SAML single logout (SLO). At present, only RP-initiated logout (logging out of CollectionSpace also logs the user out of the SAML identity provider) is supported. AP-initiated logout (logging out of the SAML IdP also logs the user out of CollectionSpace) may be supported in the future.

Enabling single logout enables the feature for every registered relying party. There is currently no way to enable SLO only for certain relying parties.

If single logout is enabled, credentials for signing must be present in the configuration of every registered relying party, since single logout requests must be signed.

relying-party-registrations

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.

relying-party

Configures a connection between CollectionSpace and a SAML IdP.

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 readability, it is recommended to use only URL-friendly characters.

name

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.

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.

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.

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, credentials are optional.

x509-credential

A signing credential.

private-key

The private key to be used for signing. The key can either be specified in the content of the element, or as a URL. If the 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.

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.

  • No labels