This documentation describes how to connect a SP to the SURFsecureID gateway directly. New SP's must connect to the SURFconext gateway.
Request authentication at a specific LoA
An example Apache configuration snippet where a request for a specific URL triggers a SAML request with LoA 2.
The LoA identifier
) in the example below is specific for the Production environment and the Test environments use different identifiers.
ShibRequestSetting requireSession 1
Below is an example of the resulting subset of environment variables that are set by the Shibboleth SP. You can use these for authorisation purposes in your application.
Note that a LoA2 authentication was requested, yet the user was authenticated at LoA3.
You can only rely on the value of
Shib-Identity-Provider is indeed the
EnityID of the SURFsecureID IdP. For Production that is
https://sa-gw.surfconext.nl/authentication/metadata, the other SURFsecureID environments use different
Note that when your Shibboleth SP trusts other IdPs in addition to the SURFsecureID IdP (e.g. the normal SURFconext IdP,
https://engine.surfconext.nl/authentication/idp/metadata). Shibboleth will by default accept unsolicited assertions as used in the IdP-initiaded SSO flow. This means that an IdP can login without the SP having first created an authentication request. We recommend that you always verify that the
EnityID of the IdP is the one you expect for each authentication, e.g. by verifying the value of