Authentication Context with IDP Federation

[RamKesanakurti]

I have a question about enabling Authentication Context for CATS 2.0 standards.

I know it is required between CP and RP in case of SP initiated federation sending AuthNContext in SAMLRequest and expecting a response in SAMLResponse.

What about the requirement in IDP initiated federation.

For example, currently CRA and ESDC use identity federation (IDP initiated) without the use of SAML Request. I was wondering if LOA2 Authentication Context is required in this scenario.

Thanks, Ram

[harrdou]

Hi Ram;

This is one of those use-cases where CATS 2.0 shows it's age. It actually has a constraint that "Cyber-Auth Deployments MUST discard unsolicited messages" which was justified at the time for no reason other than "No Cyber-Auth use case has been identified which requires these".

Obviously this is no longer appropriate, so we should fix this in CATS 3.

To answer your question: while there is no Authentication Request and associated <RequestedAuthnContext> applicable during IdP-initiated SSO, there is still a Response and an Assertion being generated, so I think it would be appropriate for the <AuthnStatement> of the <Assertion> to still contain the <AuthnContextClassRef> to the level of credential assurance that was achieved when the end user was originally authenticated.

I think it also wold make sense that the IdP Metadata should still follow the Identity Assurance Certification Attribute Profile and list the all of levels of credential assurance that it provides. E.g.

<IDPSSODescriptor ID="XXX" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <Extensions>
    <md-attr:EntityAttributes xmlns:md-attr="urn:oasis:names:tc:SAML:metadata:attribute">
       <saml2:Attribute xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:oasis:names:tc:SAML:attribute:assurance-certification" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
          <saml2:AttributeValue>urn:gc-ca:cyber-auth:assurance:loa2</ns2:AttributeValue>
       </saml2:Attribute>
    </attr:EntityAttributes>
  </Extensions>

[RamKesanakurti]

Hi Doug, Thanks for the response.

Has it (what you have referred below) been added to CATS 3.0 officially? Or is it a recommendation at this point?

Currently we are trying to comply on CATS 2.0. From time lines point of view I am not sure when CATS 3.0 will be enforced?

Thanks, Ram

[harrdou]

We are just starting to work on CATS 3.0 here. A first draft of a new SAML profile is still a few months away. The current approved version (r8.2) of CATS 2.0 doesn't even allow IdP-initiated SSO, but I think if you follow my suggestions above you will be well-positioned to align with where the specifications are going.

[harrdou]

Another question to ponder: Am I correct in my understanding that the assertions your IdP is issuing provides identity assurance instead of credential assurance?

I wonder if we should be defining new URIs to distinguish between credential LoA and identity LoA? There are use cases where some IdPs may provide identity-based credentials (e.g. My Alberta Digital ID, in which case a single assertion would provide both identity and credential assurance. To include both in a single <AuthnStatement> we would need separate authentication context classes.

Alternatively, such an IdP could issue a <Response> with two <Assertion>s (one for credential assurance, one for identity), or else a single <Assertion> with two <AuthnStatement>s.

The challenge with these sorts of problems is that, while all of these approaches may be legal SAML, there could be very few software implementations around capable of actually supporting this.