Note |
---|
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
http://surfconext.nl/assurance/loa2
) in the example below is specific for the Production environment , and the Test and Pilot environments use different identifiers.< Location /secure> AuthType shibboleth ShibRequestSetting requireSession 1 ShibRequestSetting authnContextClassRef http://surfconext.nl/assurance/loa2 require valid-user </ Location > |
[Shib-Application-ID] => default [Shib-Session-ID] => _77421bdf5f17e10c70efb9a89aa3737e [Shib-Identity-Provider] => https://sa-gw.surfconext.nl/authentication/metadata [Shib-Authentication-Instant] => 2013-10-29T22:08:46Z [Shib-Authentication-Method] => http://surfconext.nl/assurance/loa3 [Shib-AuthnContext-Class] => http://surfconext.nl/assurance/loa3 [Shib-Session-Index] => c8a493e33432686feb5cc683a9fd0c7c |
Note that a LoA2 authentication was requested, yet the user was authenticated at LoA3.
Security
You can only rely on the value of Shibof Shib-Authentication-Method
or Shib-AuthnContext-Class
when Shib-Identity-Provider
is indeed the EnityID
that of the SURFsecureID IdP. For Production that is https://sa-gw.surfconext.nl/authentication/metadata
, the other SURFsecureID environments use different EntityIDs EntityID
s.
Note that when your shibboleth Shibboleth SP trusts other IdPs in addition to the SURFsecureID IdP (e.g. the normal SURFconext IdP, https://engine.surfconext.nl/authentication/idp/metadata
) in addition to the SURFsecureID IdP. Shibboleth will by default accept unsolicited assertions (also known 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 Shib-Identity-Provider
.