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
Fri Dec 9 07:06:08 PST 2011


Hi Russ,
sorry for the delayed response to your mail. Your advice was really 
helpful and now we have a simple implementation of shibboleth module 
useful for forced re-authentication in connection with WebAuth 4.x. We 
hope, this solution is both robust and secure, so we ask you (and of 
course anyone who cares) for public review of this solution.

The description in detail and the module itself are accessible at 
http://support.zcu.cz/java-idp-webauth-login-handler

Thanks,
Petr Grolmus


On 21.9.2011 01:30, Russ Allbery wrote:
> I'm sorry about the long delay in getting back to this discussion about
> forced authentication with Shibboleth.  But I do have new information to
> add to the discussion that is now possible with WebAuth 4.0.0.
>
> Petr Grolmus<indy at civ.zcu.cz>  writes:
>    
>> On 14.7.2011 19:29, Russ Allbery wrote:
>>      
>    
>>> 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.
>>      
> Oh!  I see.  Shibboleth attempts to use the SAML protocol to negotiate
> forced authentication, but the Shibboleth RemoteUser session handler
> doesn't support 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.
>>      
> I don't think there's going to be any way around this apart from writing
> custom code, unfortunately.  But the custom code should hopefully be
> fairly simple.
>
> WebAuth 4.0.0 makes this easier in two respects.  First, it provides
> considerably more flexible support for requiring forced authentication by
> allowing configuration of specific required session authentication factors
> rather than just having one big switch.  Second, and more importantly, it
> exposes in the environment the initial and session authentication factors,
> which allows other code to make use of that information.
>
> The implementation strategy I would use is therefore:
>
> 1. Subclass some suitable RemoteUser authentication implementation for the
>     IdP and declare that it supports forced authentication.
>
> 2. Set up a URL on the IdP server (it can be any arbitrary URL) that
>     requires session password authentication (or whatever other specific
>     session authentication requirements you want to have).  Something like:
>
>         WebAuthRequireSessionFactor p
>
>     should do it for the general case.  The URL will need to accept any
>     parameters that are passed to the IdP and hand back a browser redirect
>     sending it back to the IdP login URL, maintaining all those parameters.
>     This shouldn't be too hard to do with mod_rewrite as long as you're not
>     using a POST to go from the SP to the IdP.
>
> 3. Inside the customized RemoteUser handler, if forced authentication is
>     set, check WEBAUTH_FACTORS_SESSION and see if it contains p.  If not,
>     redirect the user to the above URL with all its parameters intact.
>     This should force the session authentication and then send the user
>     back to the login handler with p in the session factors.
>
> 4. If p is present in the session factors, assert that the user did indeed
>     pass forced login if that's required by the SAML protocol.
>
> There are some bits in here that I don't know the details of, such as how
> to preserve all the IdP input parameters through that redirect pass to
> force the WebAuth reauthentication, but I think it should be doable.
>
>    



More information about the webauth-info mailing list