WARNING: This plugin should only be enabled and configured by system administrators as it affects how users log in to ResourceSpace.
This plugin allows users to log on to ResourceSpace using a SAML compliant single sign-on (SSO) Identity Provider (IdP)
- Please note that use of this plugin is dependent on your organisation having implemented a SAML compliant single sign-on solution. Configuration of this plugin will require co-operation between your ResourceSpace hosting provider and the administrators of your Single Sign-On system.
- Implementing a new single sign-on solution is not trivial and is normally an organisation wide decision requiring a significant amount of work. If you are at all unsure as to whether you have a single sign-on solution in place please speak to your IT team.
This plugin utilises the simplesamlphp application (https://simplesamlphp.org/). Please refer to the documentation for this project if you require more in-depth configuration instructions
These instructions are very basic and assume that you already have a working IdP (Identity provider) that is compliant with SAML 2.0 or other supported standard. You may choose to move the entire plugins/simplesaml/lib folder to another directory away from the plugins directory e.g. for shared ResourceSpace environments. If so please ensure that you change the relevant files and not those specified below.
- Copy the sample configuration files from
- Copy the sample metadata files from
- Ensure the password, email contact and secret salt are changed in plugins/simplesaml/lib/config/config.php as below
- Unzip the plugins/simplesaml/lib/www.zip directory. This is useful for decoding external XML metadata for use in config files and retrieving metadata that can be used by the IdP.
- Edit the file plugins/simplesaml/lib/config/config.php
- Select the technology you want to use by setting values to true or false as below.
IMPORTANT: if setting up ADFS, leave enable.saml20-idp = true
* Enable * * Which functionality in simpleSAMLphp do you want to enable. Normally you would enable only * one of the functionalities below, but in some cases you could run multiple functionalities. * In example when you are setting up a federation bridge. */ 'enable.saml20-idp' => true, 'enable.shib13-idp' => false, 'enable.adfs-idp' => false, 'enable.wsfed-sp' => false, 'enable.authmemcookie' => false,
- Change this if necessary
* A directory where simpleSAMLphp can save temporary files.
* SimpleSAMLphp will attempt to create this directory if it doesn't exist.
'tempdir' => 'resourcespace/filestore/tmp/simplesaml',
/** * This password must be kept secret, and modified from the default value 123. * This password will give access to the installation page of simpleSAMLphp with * metadata listing and diagnostics pages. * You can also put a hash here; run "bin/pwgen.php" to generate one. */ 'auth.adminpassword' => '123', 'admin.protectindexpage' => false, 'admin.protectmetadata' => false, /** * This is a secret salt used by simpleSAMLphp when it needs to generate a secure hash * of a value. It must be changed from its default value to a secret value. The value of * 'secretsalt' can be any valid string of any length. * * A possible way to generate a random salt is by running the following command from a unix shell: * tr -c -d '0123456789abcdefghijklmnopqrstuvwxyz' /dev/null;echo */ 'secretsalt' => 'defaultsecretsalt', /* * Some information about the technical persons running this installation. * The email address will be used as the recipient address for error reports, and * also as the technical contact in generated metadata. */ 'technicalcontact_name' => 'Administrator', 'technicalcontact_email' => 'email@example.com',
1. Configuring the Service Provider (SP)
The SP is configured by an entry in config/authsources.php. See https://simplesamlphp.org/docs/1.5/simplesamlphp-sp for more detail
The following is an minimal authsources.php file
array( 'saml:SP', ), );
If you want muliple Service Providers in the same site and installation, you can add more entries in the authsources.php configuration. If so remember to set the EntityID explicitly. Here is an example:
'sp1' => array( 'saml:SP', 'entityID' => 'https://sp1.example.org/', ), 'sp2' => array( 'saml:SP', 'entityID' => 'https://sp2.example.org/', ),
2. Enabling a certificate for your Service Provider (recommended)
Some Identity Providers / Federations may require that your Service Providers holds a certificate. If you enable a certificate for your Service Provider, it may be able to sign requests and response sent to the Identity Provider, as well as receiving encrypted responses.
Create a self-signed certificate in the cert/ directory.
cd cert openssl req -new -x509 -days 3652 -nodes -out saml.crt -keyout saml.pem
Then edit your authsources.php entry, and add references to your certificate:
'default-sp' => array( 'saml:SP', 'privatekey' => 'saml.pem', 'certificate' => 'saml.crt', ),
3. Adding IdPs to the SP
The service provider you are configuring needs to know about the identity providers you are going to connect to it.
This is configured by metadata stored in metadata/saml20-idp-remote.php and metadata/shib13-idp-remote.php.
The following is a minimal example of a metadata/saml20-idp-remote.php metadata file:
'https://openidp.feide.no/simplesaml/saml2/idp/SSOService.php', 'SingleLogoutService' => 'https://openidp.feide.no/simplesaml/saml2/idp/SingleLogoutService.php', 'certFingerprint' => 'c9ed4dfb07caf13fc21e0fec1572047eb8a7a4cb', );
For more information about available options in the idp-remote metadata files, see the IdP remote reference
If you have the metadata of the remote IdP as an XML file, you can use the built-in XML to simpleSAMLphp metadata converter, which by default is available as /admin/metadata-converter.php in your simpleSAMLphp installation.
Note that the idp-remote file lists all IdPs you trust. You should remove all IdPs that you don't use.
4. Setting the default IdP
An option in the authentication source allows you to configure which IdP should be used. This is the idp option.
array( 'saml:SP', /* * The entity ID of the IdP this should SP should contact. * Can be NULL/unset, in which case the user will be shown a list of available IdPs. */ 'idp' => 'https://openidp.feide.no', ), );
5. Exchange metadata with the IdP
If you do not have setup an IdP yourself, you could use the Feide OpenIdP to verify your Service Provider setup. The metadata for Feide OpenIdP is already included in the metadata distributed with simpleSAMLphp, so you can copy the metadata from metadata-templates where Feide OpenIdP is included.
But, in order to complete the connection between your SP and Feide OpenIdP, it is not sufficient that you have configured metadata for Feide OpenIdP. Feide OpenIdP also needs to add metadata for your SP.
Copy the SAML 2.0 XML Metadata document automatically generated by simpleSAMLphp (as described below), and go to the OpenIdP Metadata Self-Service Registry:
You need to login with an OpenIdP account to authenticate (you can create a new account if you do not have one already). Next, click the link 'Add from SAML 2.0 XML metadata', and paste in your SAML 2.0 XML Metadata, give it a proper name and description and click 'save'. Now you can test the SAML 2.0 Example on your SP, and try to login with Feide OpenIdP.
Before you can run the test examples, you need the people running the IdP to load the metadata for your SP. This metadata can be generated automatically. Links to the generated metadata can be found under the Metadata-tab on the front page.
Azure Active Directory
When configuring Azure AD, you will have to set the Identifier and Reply URL. If you go to the admin area of SimpleSAML (ie. the www location in lib) - click on the Federation tab and then under SAML 2.0 SP Metadata click on Show Metadata (or use the URL above: https://your-domain.com/path/to/lib/www/module.php/saml/sp/metadata.php/resourcespace-sp). Using this information, set:
- Identifier: https://your-domain.com/path/to/lib/www/module.php/saml/sp/metadata.php/resourcespace-sp
- Reply URL: https://your-domain.com/path/to/lib/www/module.php/saml/sp/saml2-acs.php/resourcespace-sp
6. Test the SP
After the metadata is configured on the IdP, you should be able to test the configuration. The installation page of simpleSAMLphp has a link to test authentication sources. When you click the link, you should receive a list of authentication sources, including the one you have created for the SP.
After you click the link for that authentication source, you will be redirected to the IdP. After entering your credentials, you should be redirected back to the test page. The test page should contain a list of your attributes. These can then be used to configure the plugin within ResourceSpace
7. Configure the plugin setup page
The plugin options page requires the following information to be provided:-
|SAML Lib path||Please enter the full server path to the SimpleSAML lib folder|
|Use SAML to block access to site completely, if set to true then no one can access site, even anonymously, without authenticating||If set to TRUE, this means that no user can access the site without signing in to the IdP|
|Use SAML credentials to login to ResourceSpace? (This is only relevant if above option is enabled)||If above is TRUE and this is FALSE you can then configure anonymous access which will be only available to your SSO users|
|If blocking site, allow public shares to bypass SAML authentication?||Allow external shares to bypass the requirement for SAML SSO access|
|Name of local service provider (SP)||As configured in step (3)|
|List of additional allowed paths that can bypass SAML requirement||Pages listed here will not require SAML login|
|Allow users to log in with standard accounts as well as using SAML SSO?||If set to FALSE users will not be able to log in with standard ResourceSpace accounts|
|Prefer standard login (redirect to login page by default)||If set to TRUE users will be taken to login page which has a 'Sign on using SSO' link.
If FALSE then users will be signed in automatically or redirected to the IDP. If above option is enabled and users want to log in using standard accounts they will need to navigate directly to login.php
|Update user group at each logon. If not using SSO group attribute to determine access then set this to false so that users can be manually moved between groups||Self explanatory|
Duplicate account management
|Email-match: Before creating new users, check if the SAML user email matches an existing RS account email. If a match is found the SAML user will 'adopt' that account||This helps when implementing SSO for an existing installation provided the email addresses match the SSO account|
|Allow new accounts to be created if there are existing ResourceSpace accounts with the same email address? (this is overridden if email-match is set above and one match is found)||If this is false and a SAML account has the same email address and is not 'adopted' as above then no new account will be created and the login will be blocked|
|Email address to notify if an email conflict is found||If the above is set to false then an email will be sent to this address when the matching SAML user tries to log in|
|Attribute(s) to use for username. If this is a concatenation of two attributes please separate with a comma||Which SAML attribute will be used for the username. Two attributes can be combined e.g. initials and surname|
|If joining fields for username use this character as a separator||This will be used as the separator if multiple attributes are used for the username|
|Attribute(s) to use for full name. If this is a concatenation of two attributes please separate with a comma||Which SAML attribute will be used for the full name. Two attributes can be combined e.g. first name and surname|
|If joining fields for full name use this character as a separator||This will be used as the separator if multiple attributes are used for the full name|
|Attribute to use for email address||This will be stored in the ResourceSpace email field and used for system emails|
|Attribute to use to determine group membership||This will be used if SAML - ResourceSpace Group Mappings are configured|
|Default user group that will be used for newly created users||New SAML users will be added to this group if no match is found with a configured group mapping|
|Custom attributes to record against the user record||Any attributes listed here will be stored against the ResourceSpace user record and can be seen on the user edit page|
|Attribute (assertion/ claim) name||The attribute received from IdP and on which ResourceSpace will decide if user is allowed to log in or not.|
|Attribute (assertion/ claim) value||The value of the authorisation attribute on which ResourceSpace will decide if user is allowed to log in or not.|
|SAML-ResourceSpace Group Mapping||This list will be auto populated with discovered SAML groups once users start to log on. Each group can be mapped to a RS group and assigned a priority. If the groups are known these can be input in advance.
Each group mapping can be assigned a priority to deal with the usual situation that a user is a member of multiple groups. For example if it is required that membership of a media team group take precedence over the general staff group mapping, the media team mapping should be assigned a higher number
7. Security considerations (v8.6+)
From version 8.6, ResourceSpace has CSRF protection enabled by default. When configuring simplesaml plugin, please ensure that ResourceSpace is whitelisting the IdP system. This is done using the configuration option CORS_whitelist from CSRF protection feature.
Upgrading the SimpleSAML plugin for version 9.3
Because of an update to the version of SimpleSAMLphp used by ResourceSpace 9.3 and later any SAML SP configuration and metadata files that were previously configured need to be updated.
You will first need to identify the location of your SimpleSAML 'lib' folder. By default this will be located in the ResourceSpace web folder (plugins/simplesaml/lib). You can check whether your lib folder is located outside of the plugins directory by checking the path defined on the simplesaml plugin setup page.
Ensure that any SP private keys and certificates referenced in the old config/authsources.php file are saved e.g.
'privatekey' => 'saml.pem',The actual files will be located in the folder specified by the 'certdir' value in config/config.php as below
'certificate' => 'saml.crt',
'certdir' => '/etc/ssl/certs/',
Backup the contents of the /config and /authsources folders under the lib folder to a safe location, If you have customised the plugin ensure you also backup any of your custom files.
Delete the www folder located in the lib folder.
If your lib folder is located outside of the plugins directory you will also need to delete all the existing folders below the SimpleSAML lib folder and replace them with the contents of the plugins/simplesaml/lib folder
Unzip the www.zip file to create the SimpleSAMLphp administration site
Check which files are located in your previous 'config' and 'metadata' folders and copy the files with the same names as these from the new 'config-templates' and 'metadata-templates' folders into the new config and metadata folders
Update each of these files to match the settings that were set in the files with the same name previously.
To assist with this you can 'diff' the files in the old config and metadata folders with their respective template files in the old 'config-templates' and 'metadata-templates' folder to see what needs to be added. e.g.
cd [saml backup location from step 2] diff config/config.php config-templates/config.php diff config/authsources.php config-templates/authsources.php diff metadata/saml20-idp-remote.php metadata-templates/saml20-idp-remote.php
Log in to the SimpleSAMLphp administration site e.g.
Test SAML authentication works by clicking 'Test configured authentication sources' on the 'Authentication' tab
Once the SAML lib folder and configuration files are updated the SAML SSO integration will start working again