These examples demonstrate how REFEDS authentication profiles are presented in the SAML 2.0 and OpenID Connect protocol flows

SAML authentication contexts

The XML namespaces used in the examples:

  • samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
  • saml="urn:oasis:names:tc:SAML:2.0:assertion

Example 1: An SP requests MFA

An SP requests MFA (Comparison attribute present):

<samlp:RequestedAuthnContext Comparison="exact">
  <saml:AuthnContextClassRef>https://refeds.org/profile/mfa</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

An IdP responds MFA:

<saml:AuthnContext>
  <saml:AuthnContextClassRef>https://refeds.org/profile/mfa</saml:AuthnContextClassRef>
</saml:AuthnContext>

Alternatively, an IdP responds that it cannot satisfy the request:

<samlp:Status>
 <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext”/>
</samlp:Status>

Example 2: An SP prefers MFA but accepts SFA

This is NOT supported by the SAML standard. See the FAQ for alternatives.

OpenID Connectr acr claims

Example 1: An RP requests MFA

An RP issues a claims request, with “essential”:true qualifier as defined in [OIDC Core, section 5.5]:

 {
  "id_token":
   {
    "acr": {"essential": true,
           "value": "https://refeds.org/profile/mfa"}
    }
 }

An OP responds with an ID token indicating MFA:

 {
  "iss": "https://server.example.com",
  "sub": "24400320",
  "aud": "s6BhdRkqt3",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970,
  "auth_time": 1311280969,
  "acr": "https://refeds.org/profile/mfa"
 }

Alternatively, an OP responds to the client that it cannot satisfy the request:

 HTTP/1.1 302 Found
 Location: https://client.example.org/cb?error=invalid_request&error_description=The%20specified%20authentication%20context%20requirements%20cannot%20be%20met%20by%20the%20responder.&state=af0ifjsldkj

N.B. Currently there is no standard error code to signal OP’s inability to satisfy the requested authentication context. A dedicated error code may be later published by competent specification bodies.

Example 2: An RP prefers MFA but accepts SFA

An RP issues a claims request with a list of authentication contexts in the order of preference and “essential”:true qualifier as defined in [OIDC Core, section 5.5]:

 {
  "id_token":
   {
    "acr": {"essential": true,
           "values": ["https://refeds.org/profile/mfa",
                      "https://refeds.org/profile/sfa"]}
    }
 }

An OP responds with an ID token indicating SFA:

 {
  "iss": "https://server.example.com",
  "sub": "24400320",
  "aud": "s6BhdRkqt3",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970,
  "auth_time": 1311280969,
  "acr": "https://refeds.org/profile/sfa"
 }

Note: according to the and OpenID Connect specification, an OP can present only one authentication context in the response.

  • No labels

2 Comments

  1. I would argue that as with SAML, it is impossible in OIDC to ask for two different things with the semantic to prefer the first one, and I can definitely say the Shibboleth implementation, which is now certified, does not. So it follows that it's not interoperable, whether it's meant to be supported or not. The SAML section for that is now explicit about it being impossible, and I would probably suggest making the same change to OIDC.

  2. At the recent REFEDS meeting, it sounded like more profiles are being considered, including identity proofing and strong multifactor.  

    I am creating an issue for the OIDC iGov profile so that ACR being an array, is tested at least for that profile.  

    If the ACR request is a single value then adding more ACR values is just going to make things less interoperable.