Apache 2.4
Cantor, Scott
I've done a preliminary examination, and I believe I have the module close to building, if untested. However, I can't do a build until I essentially recode (or eliminate) all of the authz logic in the module.
Apache 2.2 introduced what was supposed to be a new provider-based architecture for authn/authz plugins, but they did essentially a halfway job of it, which is why the 2.0 module worked almost unmodified. The 2.3 (and now 2.4) version completed this change, and it breaks any existing module that does classic require-line parsing of authz rules. This is because they've implemented AND/OR logic directly inside Apache, and they don't allow modules to just walk the require list anymore.
I need to reimplement that code to support the new features and APIs, and eliminate the ShibRequireAll command in a 2.4 build. I don't think this is unfeasible in a short amount of time.
I also need to evaluate the wisdom of continuing to directly implement "require user" and the other legacy require types, but I think the differing semantics I have for them make it impossible for me to eliminate that code. I will probably eliminate support for "require group" because that's supported better by the new pluggable features in Apache without me muddying that up.
As for the rest of their architectural shift, it's quite specific to HTTP authentication methods, and I doubt that redesigning the authentication half of the module is going to be terribly useful, if it's even possible.
-- Scott
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net
Jim Fox
> I need to reimplement that code to support the new features and
> APIs, and eliminate the ShibRequireAll command in a 2.4 build. I
> don't think this is unfeasible in a short amount of time.
You mean you "don't think this is feasible in a short amount of time?"
I have a few authz type modules with the same problems.
Jim
Cantor, Scott
> > APIs, and eliminate the ShibRequireAll command in a 2.4 build. I
> > don't think this is unfeasible in a short amount of time.
>
> You mean you "don't think this is feasible in a short amount of time?"
I should have said infeasible, but I used a double negative; I'm saying I think it's feasible, hopefully. The main problem I think I have is that currently the authz hook runs as a single call and allows me to pass control through to the RequestMap for any plugins attached there or implement the htaccess enforcement.
I'm not sure how to emulate that yet.
But it's high time I broke up the various require rules into separate functions anyway, so this is just an excuse to do that.
-- Scott
Cantor, Scott
So "require affiliation student" will have to become "require shib-attr affiliation student".
I'd have to add that option in for <V2.4 as a migration aid.
-- Scott
Michael R. Gettes
Do you recall back in 2007 when I was doing the initial COmanage work we had a few go-arounds regarding how Apache handles authZ - I was wanting to get Apache to do shib for authN but then LDAP group based authZ. I have not looked at any of the 2.4 stuff but I was wondering about your thoughts as to whether or not this sort of thing will finally be possible with 2.4?
/mrg
On Mar 19, 2012, at 12:15, Cantor, Scott wrote:
> Apache 2.4 is out in the wild and of course I've already gotten questions on supporting it.
>
> I've done a preliminary examination, and I believe I have the module close to building, if untested. However, I can't do a build until I essentially recode (or eliminate) all of the authz logic in the module.
>
> Apache 2.2 introduced what was supposed to be a new provider-based architecture for authn/authz plugins, but they did essentially a halfway job of it, which is why the 2.0 module worked almost unmodified. The 2.3 (and now 2.4) version completed this change, and it breaks any existing module that does classic require-line parsing of authz rules. This is because they've implemented AND/OR logic directly inside Apache, and they don't allow modules to just walk the require list anymore.
>
> I need to reimplement that code to support the new features and APIs, and eliminate the ShibRequireAll command in a 2.4 build. I don't think this is unfeasible in a short amount of time.
>
> I also need to evaluate the wisdom of continuing to directly implement "require user" and the other legacy require types, but I think the differing semantics I have for them make it impossible for me to eliminate that code. I will probably eliminate support for "require group" because that's supported better by the new pluggable features in Apache without me muddying that up.
>
> As for the rest of their architectural shift, it's quite specific to HTTP authentication methods, and I doubt that redesigning the authentication half of the module is going to be terribly useful, if it's even possible.
>
Cantor, Scott
> had a few go-arounds regarding how Apache handles authZ - I was wanting
> to get Apache to do shib for authN but then LDAP group based authZ. I have
> not looked at any of the 2.4 stuff but I was wondering about your thoughts as
> to whether or not this sort of thing will finally be possible with 2.4?
As far as I remember, it's possible now, that's what the AuthzShibAuthoritative command is for. Today, each authz module has to expose a flag like that so that if they don't understand some of the require options, control will be passed to a later module. If you want to combine them today, you have to select one module to be the final authority, and you have to avoid things Apache doesn't support, like AND logic between rules handled by separate modules.
At the time you asked about it, there was no flag supported. Once I understood the undocumented convention that module writers were expected to follow to get around the limitation, I added it.
With 2.4, that need goes away, and support for AND/OR containers is provided by the core. There's no single module that's considered authoritative because the logic tree is implemented by mod_authz_core. In return, they broke all older authz modules.
Michael R. Gettes
My personal belief is if we could demonstrate to people this functionality then maybe they would find shib even more attractive for use in simple cases of protecting non-app web sites. Just my humble opinion.
/mrg
On Mar 19, 2012, at 15:23, Cantor, Scott wrote:
>> Do you recall back in 2007 when I was doing the initial COmanage work we
>> had a few go-arounds regarding how Apache handles authZ - I was wanting
>> to get Apache to do shib for authN but then LDAP group based authZ. I have
>> not looked at any of the 2.4 stuff but I was wondering about your thoughts as
>> to whether or not this sort of thing will finally be possible with 2.4?
>
> As far as I remember, it's possible now, that's what the AuthzShibAuthoritative command is for. Today, each authz module has to expose a flag like that so that if they don't understand some of the require options, control will be passed to a later module. If you want to combine them today, you have to select one module to be the final authority, and you have to avoid things Apache doesn't support, like AND logic between rules handled by separate modules.
>
> At the time you asked about it, there was no flag supported. Once I understood the undocumented convention that module writers were expected to follow to get around the limitation, I added it.
>
> With 2.4, that need goes away, and support for AND/OR containers is provided by the core. There's no single module that's considered authoritative because the logic tree is implemented by mod_authz_core. In return, they broke all older authz modules.
>
Cantor, Scott
> considering as long as funky modules aren't needed and hopefully
> mod_auth_ldap (and variants) will get updated - maybe I will take a stab at
> them in my copious spare time :-)
LDAP authn/authz is supported out of the box. I have no idea how robust it is. I would think that if there were problems, getting them to fix the built-in modules is a better idea than writing your own.
Michael R. Gettes
/mrg
On Mar 19, 2012, at 16:13, Cantor, Scott wrote:
>> Well, this is certainly good news! It makes apache 2.4 worth really
>> considering as long as funky modules aren't needed and hopefully
>> mod_auth_ldap (and variants) will get updated - maybe I will take a stab at
>> them in my copious spare time :-)
>
> LDAP authn/authz is supported out of the box. I have no idea how robust it is. I would think that if there were problems, getting them to fix the built-in modules is a better idea than writing your own.
>
Peter Schober
> Okey dokey! THANKS! I'd be happy to test anything you put out for
> shib to evaluate shib+ldap.
As Scott said, this is possible now with released code, i.e. it has
been possible for a while now. So don't wait for httpd 2.4 and any
updated (experimental) Shib packages.
I also wouldn't expect httpd 2.4 to make any difference to deployers
in this regard (because they could have done this all along).
And as one such deployer: we switched over to attributes/authZ via
SAML (instead of LDAP) the same time we changed to Shibboleth from a
WebSSO that only provided REMOTE_USER.
-peter
Cantor, Scott
with extensive htaccess use:
I think I will clearly need to either drop or deprecate/ignore the
ShibRequireAll and AuthzShibAuthoritative commands, as they simply don't
work in the 2.4 authz model. They aren't even implementable.
It seems to me that in at least the ShibRequireAll case, trying to
"ignore" an existing command in a configuration is exactly wrong. The user
is trying to intend that the rules be ANDed together, and 2.4 won't do
that unless you configure that using the new syntax they provide for rule
combining. Ignoring the old option would at best lead to the wrong
behavior.
I'm inclined to say the same for the other option. I don't like breaking
configs, but I don't think there's a better choice here. If you want to
move, you really can't leave existing policy alone and breaking outright
on those commands seems like the best way to make sure the Require rules
get fixed to do what they're supposed to.
I think something similar may end up the case for the ShibAccessControl
option I added. With the new model, I can directly create a "require
shib-plugin" feature and just support external plugins that way, and I
think it's best to just force a migration from the old way to the new way
so that Apache's boolean logic between these different approaches works
properly.
(Note: I'm not saying SP 2.5 will break SP 2.4 config, I'm saying SP on
Apache 2.4 won't support the same authz commands as on < Apache 2.4.)
-- Scott
Michael R. Gettes
/mrg