Second Factor Only (SFO) Authentication is an alternate SAML authentication endpoint that is offered by the SURFconext strong authentication (SA) gateway. The SFO endpoint allows a Service Provider (SP) to authenticate only the second factor of a user. This in contrast to a "standard" authentication at the SA gateway where authentication of the first factor, being the normal authentication of the user to the IdP of their home institution through SURFconext, is always performed in addition to (an optional) authentication of the user's second factor.
SFO Authentication was designed to facilitate the integration of SURFconext SA with the internal services of an institution (i.e. the institution offering services to their own users). Typical applications include:
Both SFO authentication and standard authentication use the 2nd factor of the user that is registered with SURFconext SA. This means that once a user is registered with SURFconext SA both services using standard and SFO authentication can be used.
The table below shows the differences between a SURFconext SA standard authentication and a SURFconext SA SFO Authentication.
| Feature | Standard authentication | SFO authenticaton |
|---|---|---|
| Authentication of the user's first factor | Always | Never |
| Authentication of the user's second factor | Based on policy between the IdP and SP | Always |
| User registration | Using SURFconext SA selfservice registration and vetting by an RA | |
| Standard SURFconext features | Attributes, Authorization, persistent identifiers | None |
During SFO Authentication the authentication via SURFconext is bypassed (see image below). This means that SURFconext functionality like attributes (from the user's home IdP), persistent user identifiers or the definition of authorization rules is not available when using SFO authentication. For the self-service registration of users and the vetting by RA the SURFconext SA self-service and RA web interfaces are used, with the first factor authentication provided by SURFconext.
Second factor authentication (SFO) requires implementation / configuration at the service provider. The SFO authentication protocol is very similar to the SAML 2.0 protocol used by normal authentication to the SA gateway. The main difference is that the SP must send the identifier of the user to SA gateway in the SAML AuthnRequest. For this the Subject element in the SAML AuthnRequest must be used (see the description of the AuthnRequest element in the https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, section 3.4.1, line 2017)
To start a SFO the SP must send a SAML 2.0 AuthnRequest to the SFO endpoint of the SA Gateway. This request:
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect bindinghttp://www.w3.org/2001/04/xmldsig-more#rsa-sha256 algorithm. (Note that the HTTP-Redirect binding does not use XML Signatures)RequestedAuthnContext with an AuthnContextClassRef with one of the defined levels.Subject element of the AuthnRequest. (see the description of the AuthnRequest element in the https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, section 3.4.1, line 2017) as a SAML NameID with Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified".The SFO uses a different SingleSignOn Location and different AuthnConext identifiers as the standard authentication.
See below for an example AuthnRequest. The signature is not visible in the XML as it will be encoded in HTTP GET parameters according to the specification of the HTTP-Redirect binding.
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_zQIibz9FKixdlgX8/E7bHqE29wfatcgbsPdVn0NN"
Version="2.0"
IssueInstant="2016-03-10T15:09:21Z"
Destination="https://gw.stepup.example.org/gssp/2nd-factor-only/single-sign-on"
AssertionConsumerServiceURL="https://application-gateway.some-organisation.example.org/consume-assertion"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
<saml:Issuer>https://application-gateway.some-organisation.example.org/metadata</saml:Issuer>
<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:Subject>
<samlp:RequestedAuthnContext>
<saml:AuthnContextClassRef>http://stepup.example.org/verified-second-factor/level2</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest> |
The SURFconext identifier is built from identifiers that the IdP of the users sends to SURFconext during authentication. It has the following form:
urn:collab:person:{{urn:mace:terena.org:attribute-def:schacHomeOrganization}}:{{urn:mace:dir:attribute-def:uid}}
where:
urn:collab:person:" is a fixed prefix.{{urn:mace:terena.org:attribute-def:schacHomeOrganization}}" is the value of the schacHomeOrganisation attribute of the user. This value is the same for all users of an institution and will typically be something like "institution.nl". The administrator of the identity provider (IdP) of the institution can tell you how this value is formed for users of the institution.{{urn:mace:dir:attribute-def:uid}}" is the value of the uid attribute of the user. The administrator of the identity provider (IdP) of the institution can tell you how this value is formed for users of the institution.Example SURFconext identifier (59 characters): urn:collab:person:some-organisation.example.org:m1234567890
The result of a successful authentication is a SAML Response. The Response does not contain an AttributeStatement as would a Response from a standard authentication.
<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="_zQIibz9FKixdlgX8/E7bHqE29wfatcgbsPdVn0NN"
>
<saml:Issuer>https://gw.stepup.example.org/second-factory-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="_zQIibz9FKixdlgX8/E7bHqE29wfatcgbsPdVn0NN"
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="_zQIibz9FKixdlgX8/E7bHqE29wfatcgbsPdVn0NN"
/>
</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> |
When the SA gateway is unable or unwilling to authenticate the user a SAML Response with a non success status is sent. In some failure scenarios a non 20x HTTP status code may be returned.
SAML status codes are used to refer specific failure modes back to the SP:
urn:oasis:names:tc:SAML:2.0:status:Responder with subcode urn:oasis:names:tc:SAML:2.0:status:AuthnFailed: The authentication was not successful urn:oasis:names:tc:SAML:2.0:status:Responder with subcode urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext: The user could not be authenticated at the requested levelExample error response:
<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="_zQIibz9FKixdlgX8/E7bHqE29wfatcgbsPdVn0NN">
<saml:Issuer>https://gw.stepup.example.org/metadata</saml:Issuer
>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" />
</samlp:StatusCode>
</samlp:Status>
</samlp:Response> |
Starting an SFO authentication will immediately start an authentication at the SA gateway. For tiqr this means that a push notification is sent to the phone of the user being authenticated. For SMS authentication this means that an SMS message is sent to the mobile phone of the user being authenticated. When an authentication is started for the wrong user (deliberately or not) this will derange the targeted user and in case of SMS, incur a cost to the institution and possibly for the user.
By observing the behaviour of the SFO authentication it is possible to determine whether a username exists or not.
For the above two reasons we strongly advise implementers to always perform a first factor authentication before starting a SFO authentication. The second factor authentication process was not designed to be used as a single factor authentication mechanism.