Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

Shibboleth and WebAuth II

Petr Grolmus indy at civ.zcu.cz
Mon Jul 18 01:08:42 PDT 2011


Hi Russ,

On 14.7.2011 19:29, Russ Allbery wrote:
 > Petr Grolmus <indy at civ.zcu.cz> writes:
 >
 >> we are using WebAuth for authentication in Shibboleth - which works
 >> fine. But now we have one special application - a certificate authority
 >> that issue personal digital certificates. This application just 
before the
 >> final issuing try to re-authenticate user (to make sure, that user is
 >> still the same, that initiated the issue process) in intention of
 >> Shibboleth terminology.
 >
 >>     Of course, in this case nothing happens - WAS still has its 
cookie and
 >> Shibboleth re-authentication does not proceed. This leads to an 
error and
 >> user never gets his certificate...
 >
 > What error?  Normally, Shibboleth doesn't have any visibility into how
 > WebAuth authenticates the user.  Is the code looking at the 
authentication
 > time or something like that?

Well, the error message showed on web page (Didn't recieved attributes 
from IdP) during work with the CA application after re-authentication 
request (forced authentication) to Shibboleth relates with this log from 
shib:

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.

For the time being we have in Shibboleth two LoginHandlers - RemoteUser 
(with configured WebAuth) and PreviousSession:

<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>

so we think, when CA application requests 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();
       }
   }

the PreviousSession is thrown away just on the begining, and the 
RemoteUser (WebAuth) is thrown away next - because

public class RemoteUserLoginHandler extends AbstractLoginHandler {

and the class AbstractLoginHandler has in its constructor determined, 
that this method doesn't support forced authentication :-(

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;
    }
    ...
}

so there is no method left to force authentication, and it evolves to 
the error.


 >>     Did someone already try to solve this problem - forced Shibboleth
 >> re-authentication in WebAuth??
 >
 > WebAuth has a corresponding Apache directive to force reauthentication:
 > WebAuthForceLogin.  The trick is getting the Shibboleth 
authentication for
 > this application to use it.  The easiest way would be if you can convince
 > Shibboleth, through one method or another, to go to a different login URL
 > on the IdP for this case, so that you could configure that different 
login
 > URL to use forced authentication.

Well, interesting idea to have two URLs - the first one for IdP itself 
and the second one for force authentication requests with 
WebAuthForceLogin and WebAuthAppTokenLifetime set to several seconds. 
But, I can see at least 2 problems:

1. ServiceProvider do know only one URL per one IdP - so, probably, we 
have to make changes to local implementation of the Shibboleth to 
enforce this behavior and somehow change originated URL to another one.
2. RemoteUser authentication method (from Shib) does not support force 
authentication. We have found another method IdPAuthExternal 
(https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthExternal), 
which is similar to RemoteUser. In the description is "This login 
handler requires additional code" so we suppose, this is the best place 
where to make changes. To write our own LoginHandler, that understand to 
force authentication requests and rewrite originated URL to URL where is 
WebAuth with  WebAuthForceLogin directive.

We are assuming, this could be a reasonable way how to tie Shibboleth 
force authentication with WebAuth features. Of course, this is only just 
our guess, may be, there are others ways, even easier... So, we 
appreciate any suggestions.

Petr Grolmus





More information about the webauth-info mailing list