is it possible to verify that the authnContextClassRef in the response is the
one which was requested in the authnRequest?
I'm not sure how to read the standard on this.
Moreover the IdP does not verify that the authnContextClassRef in the response
is in alignment with what's been requested by the SP. (SIDP-265).
By combining the two, the following would end up in successful session
- SP claims that it requires some special authnContext (X509)
- IdP tries to authenticate the user using that method
- user interrupts the authentication (eg. refuses to send the certificate)
- user invokes some other login handler manually (UserPassword),
- If the IdP login servlet does not overwrite the context (like
-- the IdP returns the originally requested method (X509)
-- the IdP returns the method specified by the login handler (PPT).
- SP accepts the response either way.
Kristof BAJNOK wrote on 2009-06-22:
> is it possible to verify that the authnContextClassRef in the response
> is the one which was requested in the authnRequest? I'm not sure how to
> read the standard on this.
It's physically possible, sure, but the SP doesn't do that, no. I don't
maintain state associated with requests to do any correlation. Nor do I see
the point, since the SP has to allow for unsolicited responses that have no
request, which means the app has to check this anyway. I also provide for
access control based on the class or decl ref, via the built-in or custom
> What do you think about it?
I think the IdP has some outstanding bugs that make the feature unusable for
the time being.