httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: 2.4 API changes for AAA
Date Tue, 22 Mar 2011 20:11:47 GMT
On Friday 18 March 2011, Jeff Trawick wrote:
> after gathering pages of scribbles from comparing
> 2.2.x/modules<->2.3.x/modules and 2.2.x/include<->2.3.x/include for
> API changes and trying to describe as many as I could, I'm left
> with a list of things to research further:

I'll try to provide some bits. But I fear I don't know the 2.2 model 
well enough to provide a big picture. Let alone the 1.3/2.0 model.

> check_user_id->check_authn
> access_checker->check_access
> auth_checker->check_authz

These three allow to select if a module wants to be called per per-
dir-config or per URL. If a module makes a decision only based on the 
per-dir-config, this can save a lot of overhead for requests with many 
sub-requests (DAV propfind, etc.).

In the 2.4 model, the latter two hooks should normally not be used 
directly. Instead, a module should register authn/authz providers 
which are called by mod_authz_core or by the modules implementing 
authentication types.

access_checker/check_access is really deprecated in favor of *_ex

> AUTHN_PROVIDER_VERSION?

Don't know. I guess just a DEFINE for the "0"?

> note_basic_auth_failure

This is needed to allow a module implementing an authentication type 
to adjust the error response so that authentication is requested from 
the user when ap_note_auth_failure() is called. In 2.2.x, 
ap_note_auth_failure() only really worked for basic auth. This new 
hook allows digest and form to work, too.

> ap_register_provider->ap_register_auth_provider

Same as the first ones above, this allows an authn provider to choose 
if it wants to be called once per per-dir-config or once per URL.

> ap_authn_cache_store

? 

> ap_hook_auth_checker->register_auth_provider

This is the new way to do authorization with the 2.4 provider 
framework, see below. In 2.2, there were only providers for authn, not 
authz.

> access_checker_ex

This is the same as access_checker, but does not only allow to deny a 
request but also to finally allow a request, bypassing authentication.
access_checker is run-all and proceeds with authn if all hooks return 
DECLINED or OK. access_checker is run-first and only proceeds with 
authn if all hooks return DECLINED.

> What's the big picture here?  Is it something like
> 
> IF YOU USE THE UGLY LEGACY HTTPD 1.3/2.0 MODEL:
> * dudette, your code still works (but shame on you for not using
> the 2.2 provider framework)
> * you may be interested in switching to the 2.4 provider framework,
> which allows for XXX,YYY,ZZZ

The 2.4 provider framework treats access restrictions that are not 
based on a user name as authorization, instead of doing two distinct 
checks, one for everything that is not related to a user name (access 
checker), and one for everything that is (authorization). This allows 
the administrator much finer control on when to allow access (compared 
to the crude satisfy any/all choice in 2.2 and earlier).

It also allows merging of authz settings with the parent per-dir 
config. The admin can choose AND, OR, or no merging. In 2.2, there was 
no merging (except for the two checks for authz and access_checker 
being treated separately).

Finally it provides boolean containers (RequireAll, RequireAny) for 
authz, allowing even more control for the admin.

> * you may be interested in these new features: AAA,BBB,CCC
> 
> If you use the httpd 2.2 provider framework (ponies and rainbows):
> * change1 (e.g., "0"->AUTHN_PROVIDER_VERSION)
> * change2
> * ...
> * changen
> * you may be interested in these new features: AAA,BBB,CCC
> 
> hints?

I hope that helped a bit. If you have some specific questions, maybe I 
have some more answers. But I am not making any guarantees.


Mime
View raw message