Switching between multiple login handlers cause first context to be sticky in Shib-Authentication-Method
Description
Environment
Linux 2.6.35-30-server, 64-bit. OpenJDK 1.6.0_20, tomcat 6.0.32
IdP extensions: Multi Factor Login Handler, MongoDB connector
Activity
Scott CantorOctober 10, 2011 at 7:22 PM
Per my IM, I'd like to see the pluggable auth method setting added to the UsernamePassword handler so that people trying to support assurance strings don't end up needing a custom login handler. Same code from the RemoteUser handler should do it.
ChadCOctober 10, 2011 at 3:49 PM
Fixed in rev 3073
ChadCSeptember 6, 2011 at 2:30 PM
Pretty sure they already do know that, but I'll verify it. That said, information in the LoginContext can't be changed by any external call/process, only locally running code. So, you'd have to install something that was either intentionally or accidentally doing some malicious in order to cause problems.
Scott CantorSeptember 6, 2011 at 2:25 PM
I agree, I think it's pointless to add a "type" system based on the actual login handler when we already select the handler based on AuthenticationMethod and support returning that to the engine.
We do have to take care that the login handlers know what method they're supposed to be handling and not just echo back what the LoginContext is tracking.
ChadCSeptember 6, 2011 at 2:17 PMEdited
I believe the best route is to require each login handler to return the mechanism it executed. Anything else is going to massively complicated I think.
Oh, and yes, there is no question that it needs to be fixed. We'll address it in the next patch release.
I have two login handlers, one is UserPassword and the other is MultiFactor (2FA). The problem I have is that the first authn context loaded is the one that seem to get sticky when Shib-Authentication-Method attribute is released to the SP.
Example:
The SP request MultiFactor handler but the user decide to manually override it by editing the URL from /MultiFactor to /UserPassword and then completes the login using one factor. Now I expect to be Shib-Authentication-Method = urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, but instead it's Shib-Authentication-Method = urn:oasis:names:tc:SAML:2.0:ac:classes:Token. And vice versa if the SP request UserPassword and the user change it to MultiFactor.
I have tried requesting a login handler from the SP or letting the IdP choose a default login handler both with same result.