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

Russ Allbery eagle at windlord.stanford.edu
Tue Sep 20 16:30:16 PDT 2011


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.

-- 
Russ Allbery <eagle at windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University



More information about the webauth-info mailing list