AuthnContextRef vs. AuthnContextDeclRef?

[Cantor, Scott]

> Specifically this is what is in the AuthnRequest
> 
> > <samlp:RequestedAuthnContext>
> >
> <saml:AuthnContextClassRef>secure/name/password/icmaolr/uri</saml:AuthnContextClassRef>
> > </samlp:RequestedAuthnContext>

That of course is invalid since a class ref MUST be an absolute URI, as all URIs in SAML must be. To the extent that it is just a constant, we're in "what are you willing to accept?" territory, just like Google's google.com entityID.

So if you wanted to make a Shibboleth IdP accept that, it will, it just deals in strings. What it *means* is dependent on who is defining the constant, and absent a definition and a decision to support it in an IdP, it could never result in anything but an error.

> I have no idea what "secure/name/password/icmaolr/uri" is or where it
> came from. Also, the fact it is not a URI seems wrong.

See above.

> The assertion comes back from the IdP with this:

That's invalid. The IdP MUST respond with at least the matching ClassRef. I believe you MAY attach a DeclRef to the response alongside it, but of course the DeclRef must be "compatible" with the ClassRef. In practice the DeclRef is just ignored.

> The original requested ClassRef comes back as a DeclRef in the
> assertion. So I'm trying to figure out why, if that is correct, and
> overall why and when a DeclRef should be used (thanks for the
> explanation above)

It's not correct.

> So is returning the requested ClassRef as a DeclRef a protocol
> violation? A bug in the IdP? Is the IdP trying to say "I didn't
> understand the requested ClassRef"? If so shouldn't it have failed the
> AuthnRequest?

Bug.

> The SP rejects the assertion because it does not find the requested
> ClassRef in the assertion (which I believe is correct behavior).

Well, it's up to the SP of course, but it is common that if you ask for Foo you're going to require Foo. With Shibboleth SPs, those are separate mechanical steps so are not inherently coupled.

-- Scott