LPS:Shib plus WA

Z HelpDesk



TODO

  • napsat rusovi podrobne informace o chybe a jejich pricinach se zadosti o radu co s tim [indy]
  • vyzjistit jak funguje webauthi reautentizace [bodik,p@ja]
  • asi potrebujeme idp auth external nebo coze

co jsme zatim udelali

  • webauth 4.0.1 jak na webkdc tak na mod_webauth
  • pri instalaci webauth-weblogin jsem pridali adresar kamsi do /usr/local/share/weblogin a dali jsme tam webserveru pristup pro kompilovani perlovskych template -- TODO: tohle presunout jinam ..
  • prevazali jsme tomcati kontejner za apache pres modjk protoze mod_proxy_ajp umi predat dodatecne atributy jenom pomoci http headers a to neni bezpecne. do propagovanych atributu jsme dali vsechny ktere wa 4.0.1 podporuje. je zajime ze pri iteraci pres request.getAttributeNames se polozky neukazuji, ale pri primem pristupu ano...

Data

(note that we don't have latest IDP version in production, line numbers taken from sources may differ)

our IDP configuration webapps/idp/conf/handler.xml

...
 <LoginHandler xsi:type="RemoteUser">
  <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</AuthenticationMethod>
 </LoginHandler>
 <LoginHandler xsi:type="PreviousSession">
  <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</AuthenticationMethod>
 </LoginHandler> 
...


error message showed during working with our TCS application (requesting a new certificate)

07:44:27.748 - INFO [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:440] - Force authentication requested but no login handlers available to support it
07:44:27.748 - INFO [Shibboleth-Access:72] - 20110525T054427Z|89.103.43.107|shib.zcu.cz:443|/profile/SAML2/Redirect/SSO|
07:44:27.756 - WARN [org.opensaml.saml2.binding.encoding.BaseSAML2MessageEncoder:88] - Relay state exceeds 80 bytes, some application may not support this.

so we think, than when our application is requesting forced authentication, shibboleth determines a set of available authentication methods in

 REL_2/java-idp/src/main/java/edu/internet2/middleware/shibboleth/idp/authn/AuthenticationEngine.java
 protected void filterByForceAuthentication(Session idpSession, LoginContext loginContext,
      ... 
      loginHandlers.remove(AuthnContext.PREVIOUS_SESSION_AUTHN_CTX);
      LoginHandler loginHandler;
      for (AuthenticationMethodInformation activeMethod : activeMethods) {
          loginHandler = loginHandlers.get(activeMethod.getAuthenticationMethod());
          if (loginHandler != null && !loginHandler.supportsForceAuthentication()) {
              for (String handlerSupportedMethods : loginHandler.getSupportedAuthenticationMethods()) {
                  LOG.debug("Removing LoginHandler {}, it does not support forced re-authentication", loginHandler.getClass().getName());
                  loginHandlers.remove(handlerSupportedMethods);
              }
          }
      }
      ...
      if (loginHandlers.isEmpty()) {
          LOG.info("Force authentication requested but no login handlers available to support it");
          throw new ForceAuthenticationException();
      }
  }


we end up with empty loginHandlers because we'r using:


REL_2/java-idp/src/main/java/edu/internet2/middleware/shibboleth/idp/authn/provider/RemoteUserLoginHandler.java
public class RemoteUserLoginHandler extends AbstractLoginHandler {
  
}

which inherits supportsForceAuthentication from:

REL_2/java-idp/src/main/java/edu/internet2/middleware/shibboleth/idp/authn/provider/AbstractLoginHandler.java
public abstract class AbstractLoginHandler implements LoginHandler {
   ...
   /** Constructor. */
   protected AbstractLoginHandler(){
       supportedAuthenticationMethods = new LazyList<String>();
       supportsForceAuthentication = false;
       supportsPassive = false;
   }
   ...
}


we thinks that we might need to program new LoginHandler based on

 edu.internet2.middleware.shibboleth.idp.authn.provider.ExternalAuthnSystemLoginHandler

in which we'll employ WebAuth reauthentication protocol features ?