...

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:

1. First level StatusCode urn:oasis:names:tc:SAML:2.0:status:Responder
   with second level StatusCodelevel StatusCode urn:oasis:names:tc:SAML:2.0:status:AuthnFailed:
   user canceled the authentication.
   or
2. First level StatusCode urn:oasis:names:tc:SAML:2.0:status:Requester  
   with second level StatusCode urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext:
   authentication cannot be performed at the requested LoA. 

...