LPS:Shib plus WA

• http://shibboleth.internet2.edu
  • URL: https://svn.shibboleth.net/java-shib-idp2-main/branches/REL_2
  • https://wiki.shibboleth.net/confluence/display/SHIB2/SourceAccess -- dokumentace ke zdrojovym kodum
  • https://wiki.shibboleth.net/confluence/display/SHIB2/IdPDevCustomExtension
  • https://wiki.shibboleth.net/confluence/display/SHIB2/IdPDevExtLoginHandler
    • https://wiki.shibboleth.net/confluence/pages/viewpage.action?pageId=5308680
• http://webauth.stanford.edu/protocol.html -- popis WebAuth protokolu
  • http://webauth.stanford.edu/protocol.html#tokenformat
  • http://webauth.stanford.edu/manual/mod/mod_webauth.html
• https://mailman.stanford.edu/pipermail/webauth-info/2011-September/000778.html -- navod jak to mame napsat
• https://wiki.shibboleth.net/confluence/display/SHIB2/Kerberos+Login+Handler -- obdobny projekt
• https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler -- obdobny projekt
• https://bugs.internet2.edu/jira/secure/attachment/10463/SIDP-448.patch -- nejaky remoteuser reauthpatch ktery sme ale v svn zatim moc nevideli nebo coze
• http://svn.shibboleth.net/view/extensions/ -- ostatni rozsireni

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...
• preloziji jsme vlastni IDPcko ze zdrojovych kodu
• vytvorili prvni implmenentaci ktera se na venek tvari tak jak bychom chteli, implementaci je potreba upravit aby odpovidala specifikaci presne (MUST != MUST-10sec)

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 ?