Guide for Outsourcing the Operation of a SAML Service Provider

Intro / Targeted audience

This guide is designed for people who are responsible for a service but wish to outsource the operation of the SAML Service Provider (SP) to an external provider, e.g. a web hoster. Therefore, this guide is not aimed at technical persons. If you are looking for instructions on how to install and operate an SP, please refer to our SP installation guide and SP configuration guide.

General guidelines

Make sure both you and your external provider are familiar with the SP Best Current Practices document (SP BCP in PDF). Specifically, take a good look at its chapter 1. Introduction, and make sure your external provider follows the security measures advised in chapter 4.5. Security.

Also ensure that both you and your external provider are familiar with the Resource Registry guide.

Points to check with your external provider

  • Your provider must be able to properly download and verify the federation's SAML metadata file. Failure to do so will result in your service not working in the federation.
    In particular you should verify that your service can properly process SAML metadata containing several EntityDescriptors to support users from multiple Identity Providers.
  • Decide which attributes are necessary for your service:
    You should discuss the attribute requirements together with your external provider, select only the required attributes, as advised in the privacy policy. Check out the SWITCHaai Attribute Specification and list of attributes in the Resource Registry.
  • For each service three contact addresses must be provided: Administrative, Technical and Support contact.
    You need to figure out with your external provider who is responsible for which one. These addresses should be impersonal/group addresses (for example support@example.org rather than john.paul@example.org) as they will be publicly released.
  • When registering a service with the federation, the intended audience of the service has to be provided. The intended audience should only include those organizations and organization types whose users potentially should be able to access your service.
    It is also possible to include SWITCH edu-ID users without an affiliation to any organization, if you wish so. This would mean that anyone with a self-registered SWITCH edu-ID account could use your service. By default, this is disabled.
  • User experience and IdP discovery:
    If you accept users from multiple IdPs, there are several ways to configure a Discovery Service where users will pick their Home Organization. You need to discuss this with your external provider.
  • If your external provider is in charge of handling the service registration in the Resource Registry, he might not be able to do so himself, because his VHO (Virtual Home Organization) or SWITCH edu-ID user account is not entitled to add a service to your Home Organization. In this case the external provider should contact the SWITCHaai team before submitting the registration request for approval.
  • Note that you can register your service in the AAI Test Federation in the Resource Registry if you want to test it in an environment, which resembles that of production. It is especially useful if your Home Organization has an IdP registered in the test federation with which you can interact.
  • SWITCH and the participants in SWITCHaai have made good experiences with the open source Shibboleth Service Provider SAML implementation, which is also the only implementation for which SWITCH can provide good support. Therefore, it is recommended you prefer external providers that use Shibboleth. Another SAML implementation frequently used is SimpleSAMLphp.