Andy, could your custom auth handler run before Shiboleth, test for a Shiboleth token? If not present, use push_handler to run Shiboleth? If the Shiboleth token or cookie is present, don’t run Shiboleth?
Russell Sent from my iPhone > On Mar 6, 2020, at 08:26, André Warnier (tomcat/perl) <a...@ice-sa.com> wrote: > > Hi experts. > > In our Apache 2.4(+mod_perl) setups, we use the following kind of thing : > > ... > PerlAddAuthzProvider UMA-user AUTH::UMA2->authz_user > ... > <Location "/esearchs/"> > AuthName ALUtop > AuthType shibboleth > PerlSetVar UMA_AuthType "SAML2" > ShibRequestSetting requireSession 1 > ShibRequestMapperAuthz Off > ShibUseHeaders On > ShibUseEnvironment Off > PerlSetVar UMA_Debug 3 > <RequireAll> > Require UMA-user valid-user > Require shibboleth > </RequireAll> > ... > </Location> > > which basically means : > we combine 2 AAA methods : > - one is our own (AUTH::UMA2 above, mod_perl based) > - the other is SAML, via Shibboleth (and all the directives above with "shib" > in them, correspond to the Shibboleth installation instructions) > > (The reason being : the corporate user authentication happens via SAML, but > it does not provide us enough information about the user. So we run another > additional scheme, which supplements the user information, in order to feed > more complete data to our applications.) > > Our own AAA method is such, that once the user has been authenticated once, > we set a token, such that for subsequent requests we do not need to > re-authenticate the user. > But no matter what we do at that level, the Shibboleth authentication runs > anyway.(*) > > And my question is : considering the above setup, would mod_perl provide a > way, through some mod_perl API, to disable the Shibboleth authentication (on > a request-by-request base), when our own authz module determines that we do > not need it to run anymore for the current request ? > > (replace Shibboleth by any other authentication that would be configured in > addition to our own; I'm looking for some "generic" mechanism, not only for > Shibboleth). > > Or is it so that different authentication methods/modules don't insert > themselves in any standard way which can easily be interfaced with in order > to dynamically disable them ? > > Note: Shibboleth itself does caching of its prior authentication, and it is > not really a big performance hit to re-run it each time, and we can live with > it as it is. But in the absolute, it is unnecessary for 90% of the accesses > to the applications, so it just sounds like disabling it would be a > nice/efficient thing to do. > > I thought of dynamically removing the "Require shibboleth" e.g., but there > does not seem to be an API to do that. > >
