Generic SAML Stepup Provider

Generic SAML stepup provider

Stepup authentication and enrolment can be delegated to a separate component that is part of the step up authentication service. This service is implemented in a generic way that may also be applicable to different (future) authentication services, and uses the SAML protocol to delegate both enrolment and the actual step up authentication to a separate system. This approach simplifies support for new authentication mechanisms using loosely coupled services that interact with the step up gateway using the SAML 2.0 protocol.

For this purpose, we informally introduce a new role step-up provider which is a combination of

1. a SAML SP that enrols new users (binds federated identities to an authentication method)
2. a SAML IDP that performs (second factor) step up authentication using the authentication method enrolled.

The SAML SP is connected to the same set of IDPs that the SAML step up gateway is connected to. See also the following diagram:

Enrolment SP

Enrolment is performed on the server by first authenticating using the first-factor IDP (which may be an IDP proxy like SURFconext), and using the resulting federated identity to register a new account. When coming from the self-service registration application SSO applies as the user is already authenticated. The enrolment process itself is specific to the authentication method.

Note that:

• by triggering enrolment using an authentication request, the user
• the service can detect if the user is already enrolled, or needs to enrol first

Authentication IDP

The authentication process is specific to the step up authentication method implemented by the IDP. From a SAML perspective however, authentication is performed exactly as with a regular SAML IDP, except for the following:

• The user identity resulting from the first factor authentication (i.e. SURFconext) should correspond to the user identity obtained from the second factor (step up) authentication. Otherwise, someone could hijack someone else's authentication session.

The authentication flow is depicted in the following diagram:

In this diagram Idp1 can be a single IdP, or a complete federation (or federation proxy like SURFconext). An example authentication request for the second factor is:

<samlp:AuthnRequest
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    AssertionConsumerServiceIndex="1"
    Destination="https://tiqr.stepup.org/idp/profile/saml2/Redirect/SSO"
    ID="_2b0226190ca1c22de6f66e85f5c95158"
    IssueInstant="2014-09-22T13:42:00Z"
    Version="2.0">
  <saml:Issuer>https://gateway.stepup.org/saml20/sp/metadata</saml:Issuer>
  <saml:Subject>
        <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">[email protected]</saml:NameID>
  </saml:Subject>
</samlp:AuthnRequest>

Note that this request includes a Subject (See Assertions and Protocols for the OASIS Security Assertion ..., section 3.4.1 Element ). This may be useful for two reasons: It lets the SAML IDP enforce the user to authenticate with the expected identity. For some authentication methods, it may optimise the authentication flow (e.g. a username doesn't need to be entered) Note that some IDP's ignore the subject element in AuthnRequest elements, so the step up gateway MUST verify that the identities from both the first and second factor IDPs coincide.

User Identifiers

To be able to verify if an subject's identifier obtained from the (first factor) IDP corresponds to the identifier obtained from the (second factor) step up IDP, a common identifier is needed. This identifier can be a persistent NameID, or an attribute