Módosítások

* When SP does not specifically request an authentication methodmethods, the user should have the choice between supported authentication modes. Otherwise, the IdP must conform with the authentication context class the SP sent. The IdP must refuse to authenticate the user with authentication methods unacceptable to the SP. There is a support ticket named SIDP-258 about this flaw in Shibboleth IdP.* One can tweak the UsernamePassword login page We want to have links for support two authentication methods: username/password (PasswordProtectedTransport) and X.509 authentication servlet and end up with three different authentication handlers:.** UsernamePasswordX509 hybrid handler with 'unspecified' Unfortunately this is not enough, we need a default authentication method classwhich offers the choice of these two methods to our users. This handler invokes the UsernamePasswordX509LoginServlet which takes care of user choices on can be done by placing a link to the extended login page.** RemoteUser login handler with protected servlet location /Authn/X509, where our custom X.509 authentication servlet livesin login.** UsernamePassword jsp. However when the SP requests PasswordProtectedTransport, this link must not be visible, so we decided to configure a new UserPassword login handlerwhich maps to the unspecified authentication class and uses this tweaked login.jsp.* These last two We also want to send the actual authentication method to the SP (instead of saying 'unspecified'), so both login handlers must ensure that the set their corresponding authentication method class is set in the Shibboleth request. When user authenticates with X.509, clients would receive As the X509 class, and with internal UsernamePasswordlogin servlet does not do this, they would receive PasswordProtectedTransport, respectivelywe subclassed it.* Playing with Shibboleth login handlers and authentication contexts revealed that Shibboleth IdP can not properly support default authentication methods, and our hybrid handler with its 'unspecified' authentication method is invoked on every authentication request, even when (because both actual methods it uses override this unspecified method in the request and IdP can not decide whether the unspecified class is requested by the SP or it is simply the user has a valid previous sessiondefault method configured in relying-party.xml). Fixing SIDP-265 with our proposed patch corrected this flaw.* When the SP requires a specific authentication method, the IdP should make sure the user can not override the requested method, implementation of Shibboleth IdP issue SIDP-258 is needed for thisbehavior.