Child pages
  • Mass-hosting virtual IDPs with SimpleSAMLphp
Skip to end of metadata
Go to start of metadata

This is a first look at providing a Hosted SAML IDP as a Service using SimpleSAMLphp (SSP) and its methods for multiplexing a single software instance into many virtual IDPs, with fully separate entityIDs (and keys). A corresponding git repository exists that suggests a basic structure and organisation for managing configuration.


Dynamic per-IDP config directory possible!

This document and the associated PoC code assumes that one instance of the software with a shared configuration directory is used for all hosted IDPs. But SSP also supports dynamic configuration directories based on environment variables, so the current vhost (HTTP Host request header) could be used to select the appropriate IDP configuration. While relying on user-supplied data for IDP config selection may not be ideal it would allow each IDP to have fully separate configuration in all respects, making most (or all) of the issues on this page moot!

Shared config directory for all instances

Things that are still unclear (does SSP support this when using a shared config directory for all hosted IDPs, and how can this be done) are marked with "(question)" below. Everything else has already been tested/implemented or seems to be "business as usual" for SSP.


SimpleSAMLphp and web server integration

  • A single SSP instance, deployed behind e.g. Apache httpd.
  • httpd is configured to only serve specific, named virtual hosts, everything else is dropped/redirected to an error/info page
  • Each httpd vhost sets a variable (Define tenent / SetEnv TENENT ${tenent}) that can be re-used throughout httpd configuration and trusted and used within SSP configuration to make lookups (log file locations, key material, metadata sources) dynamic/dependent on the accessed vhost/IDP.

Web server TLS

  • Host names are from the domain of the respective tenent, e.g., not under a shared DNS domain (
  • Each vhost references its own 3-tuple of server cert, server private key and PKIX chain file, so only web browsers with SNI support are supported
  • Hosting operator creates TLS private key, supplies tenent with CSR, gets back cert (and chain file). The private key never leaves the system it needs to be deployed to.

Log files

  • Syslog to remove machine, split into one directory per tenent, provide access to local files via SSH (SSH public keys uploaded via SAML SP)? Store logs into DB (SQL, MongoDB, etc.) and provide web interface (searchable, e.g. for userids)? (question)
  • Remote logging to tenent's syslog?
  • Support f-ticks by default! (question) HOW
  • Cookie storage only? If only Cookies and only "computed" NameIDs (see below) are supported the IDP can be run "dataless".
  • If stored in a local RDBMS that needs to be highly available/clustered

Persistent NameIDs

  • Either store to RDBMS or only support "computed" NameIDs (and forbid reassigning of userids via service contract)
  • If stored in local RDBMS that needs to be highly available/clustered
  • Provide Web UI to IDP admins to correct userid -> persistentId mapping (in case local userid got reassigned)? (question)
    • To remove the chance of local userIDs being reassigned, you could use another attribute from AD/LDAP to create the hash. (Though note the warning against using MS-AD's GUID as source attribute: "It should also be technology-neutral; using a GUID generated by an Active Directory is a very bad choice that will lead to problems if you ever change directories.")


  • Available metadata sources are:
    • federation (and likely interefederation) metadata
    • local metadata common to all instances (e.g. an SP with an admin UI for IDP admins, not exposed to the federation)
    • local metadata specific to a tenent/IDP, via server/environment variables

eduGAIN, Interfederation

  • Participation mandated (via service contract)?
  • Or merely highly recommended (opt-out)?

Community Best Practices

Support for Best Practices included by default (mandated via service contract?)


  • Login page branding different per tenent (question) HOW?
  • Only a single theme can be set for all IdPs at this time, though the current (user-supplied) HTTP Host request header used could be utilised to make SSP load different themes dynamically.
  • There is a patch available to allow per-IdP themes, but it only works for the login page (not consent, warning pages, two-factor, consent administration, etc). The workaround would be to have a single Javascript-based theme that would use the HTTP HOST header to set logos, colours, etc.

Authentication and Attributes

  • As many authsources (authN) and authproc filters (e.g. AddAttributeFromLDAP) configured as needed, each IDP references its own
  • Can we configure the TLS trust model for each IDP organization's LDAP server separately? (question)
    • Org A might use a self-signed cert on their LDAP system
    • Org B one from a local/private CA
    • Org C from a commercial PKIX supplier
  • SimpleSAMLphp uses standard ldap libraries which use the TLS_CACERT directive in the /etc/ldap/ldap.conf file for TLS server certificate verification. This enables the ability to store all LDAP certificates in a single file (certificate pinning).
    • TLS_CACERTDIR is an option as well, which you could use with the standard CA certificates on most systems, and append self-signed certs or local CAs to it.

Attribute release

Support most or all of the methods detailed in the wiki, that means support in SSP for:

  • Entity Categories (R&S, CoCo) – see above ("Community Best Practices")
  • (question) Based on mdrpi:registrationAuthority value (trust all md:RequestedAttribute elements for entities registered by a given registrar/fedop; don't release anything for others unless there are other reasons, e.g. Entity Categories)
  • Default set of attributes to release to anyone that asks (maybe limited to: persistent NameID/pairwise-id, eduPersonScopedAffiliation, schacHomeOrganization)
  • (question) Can you block all other attribute release?
  • (question) Can you ask for consent only for SPs that are not covered by R&S or CoCo? I.e., disable consent based on Entity Attributes, not by enumerating entityIDs?

Service aspects

  • SLAs, contracts, policies, etc. (question)
  • Support interfaces for tenents/IDP helpdesk (question) (See above: Log files, possibly SSH key upload, persistent NameID map access)
  • No labels