Mailing List Archive

Apache 2.4, AAA, Shibboleth
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.
Re: Apache 2.4, AAA, Shibboleth [ In reply to ]
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) <aw@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.
>
>
Re: Apache 2.4, AAA, Shibboleth [ In reply to ]
On 06.03.2020 17:18, Russell Lundberg wrote:
> 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?

Well, the problem is that Shibboleth is quite "invasive" (no complaint here, it works that
way it is supposed to and documented), in the sense that there are quite a few directives
for it (as you can see below), and I am not quite sure if I can configure a section "with
Shibboleth but not its handler", in order to only push the handler later.
For example, I have the feeling that just indicating "AuthType Shibboleth" (which is
required) already puts the handler in the chain.
On the other hand, if I could just insert the "require shibbolet"
dynamically (instead of in the static config), that might do it.
But there seems to be no mod_perl API to add a "require" on-the-fly. "Requires" are just a
list that the AUTHZ handler gets when called, and apparently each such handler only gets
its own.
For example, the "Require UMA-user valid-user" below, results in our AUTHZ function
"AUTH::UMA2->authz_user" being called, but in the list of requires we just get (our own)
"valid-user".

But thanks for the suggestion. It /is/ the kind of thing I'm looking for.
Only maybe the opposite : how to "pop" the Shibboleth handler when it's there, and just
for the current request.


>
> Russell
>
> Sent from my iPhone
>
>> On Mar 6, 2020, at 08:26, André Warnier (tomcat/perl) <aw@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.
>>
>>
Re: Apache 2.4, AAA, Shibboleth [ In reply to ]
Thanks.
That's an interesting idea, and I'm quite sure that we could make that work, if only as a
proof of concept.
The main issue I see with it, is that it would basically double a lot of our configuration
sections - of which we have many - and make our configuration even more obscure than what
it already is. My application developers and support people would not be so keen on that.

Does anyone have an idea how I could do the equivalent of a "pop the 'require shibboleth'
but just for this request" ?
(from within my mod_perl handler of course)
Or is that simply impossible, given the current mod_perl API ?

(Note: It doesn't have to be a guaranteed thing. Whatever idea there is, I'll try it, and
if it causes a segfault or other nasty things, I'll drop it. The only requirement for me
is that it has to be perl code..)



On 06.03.2020 21:14, Paul B. Henson wrote:
> Generally in SAML apps that want to convert the SSO auth into their own
> token and not require a SAML session to be established every time they
> have a different URL for the auth case.
>
> For example, you could have /esearchs-sso/ have both shibboleth and your
> auth type enabled. When someone hits that, you generate your own
> session state and then redirect them to /esearchs/, which only has your
> auth enabled.
>
> If someone hits /esearchs/ without your auth session, it sends them to
> /esearchs-sso/ to do auth, which then sends them back to /esearchs/ with
> the proper session.
>
> --
> Signet - The Art of Access
> https://www.signet.id/
>
>
> On Fri, Mar 06, 2020 at 04:26:06PM +0100, André Warnier (tomcat/perl) 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.
>>
>>
Re: Apache 2.4, AAA, Shibboleth [ In reply to ]
Genius !
Yes, I'll try that.
Why did I not think of that myself ?
If anything, it'll be fun to watch the log lines of authz_core and try to make sense of them.
I don't even think that I have to extend our module, it should work just as well with
"require UMA-user valid-user" in both cases.

One more question : why the top-level <RequireAll> ?

On 07.03.2020 00:59, Paul B. Henson wrote:
> On Sat, Mar 07, 2020 at 12:22:35AM +0100, André Warnier (tomcat/perl) wrote:
>
>> Does anyone have an idea how I could do the equivalent of a "pop the
>> 'require shibboleth' but just for this request" ?
>
> Would you be willing to extend your local custom module to achieve this?
>
> You could do something like:
>
> <RequireAll>
> <RequireAny>
> Require UMA-token
> <RequireAll>
> Require shibboleth
> Require UMA-user valid-user
> </RequireAll>
> </RequireAny>
> </RequireAll>
>
> Your custom module would get called first, which would check to see if
> your custom session token was valid. If so, it would return success and
> nothing else would be processed. Otherwise, the shibboleth module would
> run, then your custom module which would establish your session token so
> on the next access the shib auth would be bypassed.
>
>>>> 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.
>>>>
>>>>
>>