shibboleth-dev - RequestedAuthnContext issue in IdP
Subject: Shibboleth Developers
List archive
- From: Pieter Vandepitte <>
- To: "" <>
- Subject: RequestedAuthnContext issue in IdP
- Date: Fri, 10 Apr 2009 14:50:29 +0200
- Accept-language: nl-NL, nl-BE
- Acceptlanguage: nl-NL, nl-BE
Let me explain the problem: Suppose we have 2 LoginHandlers: one supporting PasswordProtectedTransport
AuthenticationMethod, another supporting let’s say X509 (but not
important for this discussion) AuthenticationMethod. Suppose both LoginHandlers
are just redirecting the request to a Servlet or some other code handling the
authentication. (Even if only one of the LoginHandlers is sending a redirect
the problem can occur) The code which handles the authentication after redirect
will execute the following as final step: request.setAttribute(LoginHandler.PRINCIPAL_NAME_KEY,
userId); AuthenticationEngine.returnToAuthenticationEngine(request,
response); When an SP requires X509 authentication, it will send out a
SAML AuthnRequest with a <samlp:RequestedAuthnContext> <saml:AuthnContextClassRef
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:X509</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> The IdP AuthenticationEngine will search for the appropriate
LoginHandler and will redirect the browser to the code handling the X509
Authentication. Now here’s the issue: if the user is simply entering
the URL for the PasswordProtectedTransport (e.g. https://idp-server/idp/Authn/UserPassword)
and the user enters his username/password, the AuthenticationEngine will
proceed authentication and will assume the user has passed X509 authentication…
Thus the user can bypass the requested authentication method. Is there a way to solve this issue? A solution would be to
get the cookie with name AuthenticationEngine.LOGIN_CONTEXT_KEY_NAME, lookup
the LoginContext in the StorageService and then check if the
authenticationMethod is equal to the authenticationMethod that your code is
handling. This is a lot of code to write (write the code to instantiate the StorageService,
finding cookie, … ). Moreover, every authentication handler based on
redirecting the browser to another servlet should contain the same code. It
would be great if one could just execute following code request.setAttribute(LoginHandler.PRINCIPAL_NAME_KEY,
userId); //
NEW: add AuthenticationMethod attribute request.setAttribute(“AuthenticationMethod”,”
urn:oasis:names:tc:SAML:2.0:ac:classes:X509”); AuthenticationEngine.returnToAuthenticationEngine(request,
response); The returnToAuthenticationEngine method of the
AuthenticationEngine should check: if an “AuthenticationMethod”
attribute is available in the request, then it should be the same as the
authenticationMethod provided by the LoginContext. If the result is false then
it should return an exception, otherwise it should execute forwardRequest(loginContext.getAuthenticationEngineURL(),
httpRequest, httpResponse); Cheers, Pieter |
- RequestedAuthnContext issue in IdP, Pieter Vandepitte, 04/10/2009
- RE: [Shib-Dev] RequestedAuthnContext issue in IdP, Scott Cantor, 04/10/2009
- Re: [Shib-Dev] RequestedAuthnContext issue in IdP, Paul Hethmon, 04/10/2009
- RE: [Shib-Dev] RequestedAuthnContext issue in IdP, Pieter Vandepitte, 04/14/2009
- RE: [Shib-Dev] RequestedAuthnContext issue in IdP, Scott Cantor, 04/10/2009
Archive powered by MHonArc 2.6.16.