On Mon, Dec 05, 2005 at 02:17:09PM -0700, Brad Nicholes wrote: > This was one of the question that I had when I added the AUTHZ_* status > types. I couldn't decide whether AUTHZ_DECLINED made sense or > AUTHZ_DENIED. To me AUTHZ_DENIED means no matter what, that we are done > checking and authorization is denied. While AUTH_DECLINED means that > the provider checked and it can't authorize the user so continue down > the list to see if something else can. I'm looking at this in the case > when we have multiple 'require' types listed:
The only question the provider should be able to answer is: "Do you think this user is authorized to access resource foo?" I believe what the implication of having multiple authz providers say "No" is something outside of the provider framework. (Somehow, satisfy may play into this, too.) > Ignoring SATISFY <whatever> for now, we still want each provider to be > called in the listed order and whether authorization is GRANTED or > DENIED may not be known until each one has been called. Until then the > status is simply DECLINED. We can assume that DENIED and DECLINED mean > the same thing as long as we get rid of the AuthzXXXAuthoritative > directives. If not then each authz module has to be able to communicate > the difference between DECLINED and DENIED" I do think we need to get rid of Authoritative, yes. > BTW, I am starting to lean much closer to adding new mod_authn and > mod_authz modules. I just haven't been able to come up with a better > home that makes sense for some of the directives. > > mod_authn - general authentication directives > authtype - for now until we decide to complete eliminated it > authname > > mod_authz - general authorization directives > require > satisfy - looks like it would make sense here after moving it out of > core. I'd prefer slapping 'core' on their names than leaving an undecorated 'mod_authn' here. Another alternative would be to just have them both in 'mod_auth_core'. Even if it were split out, mod_authn_core really wouldn't perform too much heavy lifting as the basic/digest mechanisms do the heavy lifting w.r.t. authn providers. But, for authz, because no one really 'owns' require or satisfy, a mod_authz/mod_authz_core would do most of the provider invocations - unless we can come up with a better module ownership of the 'core' authz directives. -- justin
