Multiple authenticationMethods on RemoteUserLoginHandler

[Cantor, Scott]

On 7/26/13 10:30 AM, "Howes, Nick" <N.Howes at warwick.ac.uk> wrote:
>
>I'm configuring my RemoteUserLoginHandler to support both Password and
>PasswordProtectedTransport authentication context classes instead of the
>default "unspecified", because an unconfigurable SP is making a request
>for a Password based handler and it obviously doesn't match the intended
>handler otherwise. The PasswordProtectedTransport is in there since
>that's the preferred default that I've specified in my relying party
>config.

The RemoteUser handler takes a servlet init parameter that controls the
*exact* method value that it will return. That is all it can do.

You can get the IdP to run it in response to configuration and requests
for many different strings, but the only one that it will ever return to
the IdP is a single static one, that defaults to PPT.

Where this breaks is if you configure the IdP to run it based on methods
A, B, C, and you have an SP request B or C, invoke it, and then it returns
A. That will fail.

Thus, the handlers simply are not equipped to operate in a multi-context
environment. The IdP itself isn't limited in that way, but the handlers
are, because they cannot return more than one possible value, which by
definition means they would break in the face of an SP requesting
something different that was mapped to that handler, but could never be
returned by it.

>This appears to work fine for this SP and for existing SPs that don't
>specify an authentication context class.

It will work with any SP that doesn't specify something other than the one
it's configured to return.

>This suggests that I shouldn't be doing this with a built-in handler. But
>I can't see anything special in the source for the built in login
>handlers that might do this cross-checking, added the fact that it
>appears to work fine. Am I actually doing something
> bad or is the documentation out of date?

The cross checking is actually in the AuthenticationEngine afterwards, not
the handler.

I suspect that explanation was actually much clearer than what's in the
note.

-- Scott