Shibboleth Developers

[Chad La Joie <>]

I should be clear, those are just my comments as the Shib developer, not 
some sort of official response from SWITCH.  Halm, the current developer 
of the ArpViewer, may have other comments.

Technically I'm on holiday at the moment.  :)

Adam Lantos wrote:
> Hi Chad,
>
> Thank you for your comments, I will remove the servlet path checking.
>
>
> On Mon, Aug 11, 2008 at 9:12 AM, Chad La Joie 
> <>
>  wrote:
> > Hey Adam,
> >
> > I completely missed the addition to the Serlvet 2.4 spec that allowed
> > filters to placed in front of any dispatch mechanism instead of just the
> > request.  So yes, I think what you describe should work quite well.  The
> > only comment I have is that the filter should NOT try to check that the
> > request is made to the profile servlet as there is no reasonable way to do
> > this (the way you do it breaks if people map the Serlvet to a different
> > URL).  Instead it needs to be up to the installer to appropriately configure
> > the filter so that it only operates on the path they are using for their
> > profiles.
> >
> > Otherwise I think what you have is correct.
> >
> > Adam Lantos wrote:
> > > hello,
> > >
> > >
> > > SWITCH.ch user consent Shibboleth extension
> > > (http://switch.ch/aai/support/tools/arpviewer.html) works great, but
> > > there is one big problem with ArpFilter: it only supports REMOTE_USER
> > > -based authentication. Shibboleth2 IdP comes with username and
> > > password module, which can be extended to use with any JAAS-compliant
> > > Login module. Unfortunately, current ArpFilter design can not work
> > > with this module.
> > >
> > > So I made some research to find out how to bring ArpFilter and
> > > Shibboleth IdP's internal authentication modules together. My
> > > motivation was to support the shipped UserPassword authentication and
> > > many of the features that Shibboleth IdP has (forceAuthn, isPassive).
> > >
> > > I found out that ArpFilter only depends on Shibboleth's LoginContext.
> > > This LoginContext is created by the profile handler code and
> > > interpreted by the authentication engine (and authentication modules)
> > > - then, after authentication succeeds, the profile handler processes
> > > the LoginContext and issues the response to the SP that requested it.
> > >
> > > So my idea is simple: why ArpFilter is put before the authentication
> > > servlets instead of the profile handler servlet?
> > >
> > > I got ArpFilter work before the profile servlet (see the attachment),
> > > but not quite sure whether my solution works in all use cases where it
> > > should do. I have tested it with SAML2 requests and UserPassword
> > > authentication and it seemed to work. Even the PreviousSession
> > > authentication handler did with no additional need of
> > > PreviousSessionServlet.
> > >
> > > Of course I made some modifications to the original ArpFilter code,
> > > but not too much. Basically, it just looks for LoginContext and makes
> > > sure the profile servlet gets the LoginContext, even if ArpFilter is
> > > called.
> > >
> > > The code logic is the following:
> > >
> > >    * Ensure that the request is made to the profile servlet.
> > >    * Try to get LoginContext from session.
> > >          o If LoginContext is found in the session, transfer it back
> > > to the request scope and remove it from the session.
> > >    * Try to get LoginContext from request scope.
> > >          o If no LoginContext found, proceed to the profile servlet and
> > > exit.
> > >          o Else process the request as usual, and find username in
> > > the IdP session.
> > >    * In the case when ArpFilter decides to hand over the control to
> > > the ArpViewer application, save the LoginContext back to Session.
> > >
> > > I needed one more little modification to web.xml: remove filters from
> > > /Authn/ servlets and put the ArpFilter in front of the
> > > ProfileHandlerServlet (and include the 'forward' dispatcher here,
> > > because the profile handler servlet gets the second request from the
> > > authentication engine with servlet forward - when the authentication
> > > is succeeded).
> > >
> > >
> > > I am looking forward to hearing your opinion about this.
> > >
> > > thanks,
> > >  Adam
> > --
> > SWITCH
> > Serving Swiss Universities
> > --------------------------
> > Chad La Joie, Software Engineer, Net Services
> > Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
> > phone +41 44 268 15 75, fax +41 44 268 15 68
> > ,
> >  http://www.switch.ch

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
,
 http://www.switch.ch