...
- The SAML standard allows multiple
AuthnContextClassRef
elements to be specified in theRequestedAuthnContext
. Currenly SURFsecureID will only look at the firstAuthnContextClassRef
element. - Specifying an
AuthnContextClassRef
other than on one the of the defined authentication level levels for SFO will result in an error. - The SAML standard allows a
Comparision
attribute to be added to the theRequestedAuthnContext
element. Currently SURFsecureID does not interpret the value of this attribute and behaves as if"minimum"
was specified as value for theComparison
attribute, which is a deviation of the SAML standard which specifies"exact"
as the default."minimum"
means that the authentication context in the authentication statement that is returned after a successfull authentication will either be the requested authentication context, or the the authentication context of a stronger (i.e. higher level) authentication. SURFsecureID currently always returns the authentication context corrsponding to the highst level at which the user could be authentictated.
Future SURFsecureID versions may support more complex processing of RequestedAuthnContext
options and add new AuthnContextClassRef
"families" do to support different registration policies.
...
Note that SFO uses a different SingleSignOn
Location
and a different AuthnConextClassRef
identifiers than a standard authentication to SURFsecureID. See SURFsecureID Metadata for Service Providers for the diffenrent AuthnConextClassRef
identifiers that are being used by SURfsecureIDSURFsecureID.
Determining the SURFconext identifier of a user
...
urn:collab:person:
= fixed prefix.{{urn:mace:terena.org:attribute-def:schacHomeOrganization}}
= value of schacHomeOrganisation schacHomeOrganization attribute of the user; typically the same for all users of one institution and will be something like "institution.nl
".{{urn:mace:dir:attribute-def:uid}}
= value ofuid
attribute of the user. Replace each "@" (at) character in the uid with an "_" (underscore) character.
For the value of last two items: ask the administrator of the IdP .
ExampleExamples: urn:collab:person:some-organisation.example.org:m1234567890
urn:collab:person:uniharderwijk.nl:jan.jansen_uniharderwijk.nl
SAML Response
The result of a successful authentication is a SAML Response
. Note that it does not contain an AttributeStatement
and that the Assertion
element is signed and that the Response
element is not signed. Response signing is not currently supported by SURFsecureID, it may be added in future versions.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_ECAokbn0lm7lfVT7THQUl+dSbMrpeyAgiTv0+q16" Version="2.0" IssueInstant="2016-03-10T15:09:25Z" Destination="https://application-gateway.some-organisation.example.org/consume-assertion" InResponseTo="_zQIibz9FKixdlgX8E7bHqE29wfatcgbsPdVn0NN"> <saml:Issuer>https://sa-gw.surfconext.nl/second-factor-only/metadata</saml:Issuer> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_zQIibz9FKixdlgX8E7bHqE29wfatcgbsPdVn0NN" Version="2.0" IssueInstant="2016-03-10T15:09:25Z" > <saml:Issuer>https://gw.stepup.example.org/second-factory-only/metadata</saml:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /> <ds:Reference URI="#_1ROuxGVzJi5bbre6W4woNza82aK41HKjp6aKtw9r"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /> <ds:DigestValue>YR5JFfJc1JZIKm7Ao3kXtDupEfeMrhKpD9T1lF1z0Lg=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>...</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>...</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">urn:collab:person:some-organisation.example.org:m1234567890</saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData NotOnOrAfter="2016-03-10T15:14:25Z" Recipient="https://application-gateway.some-organisation.example.org/consume-assertion" InResponseTo="_zQIibz9FKixdlgX8E7bHqE29wfatcgbsPdVn0NN"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2016-03-10T15:09:25Z" NotOnOrAfter="2016-03-10T15:14:25Z"> <saml:AudienceRestriction> <saml:Audience>https://application-gateway.some-organisation.example.org/metadata</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2016-03-10T15:09:25Z"> <saml:AuthnContext> <saml:AuthnContextClassRef>http://stepup.example.org/verified-second-factor/level2</saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response> |
Error handling
For specifiec scenario'sspecific scenarios, when the authenticated authentication fails, the SURFsecureID gateway sends a SAMLResponse
to the SP with a non success status
:
urn:oasis:names:tc:SAML:2.0:status:Responder
with subcodeurn:oasis:names:tc:SAML:2.0:status:AuthnFailed =
Authentication was not successful. This specifically happens when the user cancels the authentication.urn:oasis:names:tc:SAML:2.0:status:Responder
with subcodeurn:oasis:names:tc:SAML:2.0:status:NoAuthnContext =
The user could not be authenticated at the requested level. The user does not have an activated (vetted) token at the requests requested level.- Other situations can also lead to an error response. Specifically:
- No
RequestedAuthnContext
orAuthnContextClassRef
in theAuthnRequest
- An unsupported URI in the
AuthnContextClassRef
- No
Subject
NameID
in theAuthnRequest
- The service provider is not authorised to authenticate the user specified in the
Subject
NameID
- No
A service provider SHOULD be able to handle the first two errors scenarios above (AuthnFailed
and NoAuthnContext
) in a user friendly manner. These error responses will occur during normal use: users can and do cancel the authentication process and users that do no not yet, or no longer have, a registered seond factor will try to authneticate authenticate to your service, and fail.
...
An example code for using SFO with SimpleSAMLphp can be found at: https://github.com/SURFnet/Stepup-SFO-demo