...
Because your SP can still use the SURFconext, you could first authenticatie authenticate the user there and then authenticate the user at SURFsecureID. Because the user has SSO at the IdP, and SURFconext remembers the selected IdP the user wil will not get a WAYF (IdP selection screen) and does not need to reauthenticatie reauthenticate at the IdP.
Scoping using IDPList
...
Because your SP can still use the normal SURFconext, you could first authenticatie authenticate the user there and then authenticate the user at SURFsecureID. Because the user has SSO at the IdP, and SURFconext remembers the selected IdP the user wil not get a WAYF (IdP selection screen) and does not need to reauthenticatie reauthenticate at the IdP.
AuthenticationContext in the Assertion
...
The SURFsecureID gateway will send a SAML Response to the SP about the failure. The SP should be ready to handle the response. The response contains non-success StatusCodes:
- First level
StatusCode
urn:oasis:names:tc:SAML:2.0:status:Responder
with second levelStatusCode
level StatusCodeurn:oasis:names:tc:SAML:2.0:status:AuthnFailed
:
user canceled the authentication.
or - First level
StatusCode
urn:oasis:names:tc:SAML:2.0:status:Requester
with second levelStatusCode
urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext
:
authentication cannot be performed at the requested LoA.
...