authnContextClassRef not verified?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

authnContextClassRef not verified?

Kristof BAJNOK
Hi,

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
creation:
  - 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),
authenticates successfully
  - If the IdP login servlet does not overwrite the context (like
UserPassword):
    -- the IdP returns the originally requested method (X509)
  - else
    -- the IdP returns the method specified by the login handler (PPT).
  - SP accepts the response either way.

What do you think about it?

--
Kristof
Reply | Threaded
Open this post in threaded view
|

RE: authnContextClassRef not verified?

Cantor, Scott E.
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
plugins.

> What do you think about it?

I think the IdP has some outstanding bugs that make the feature unusable for
the time being.

-- Scott