Re: svn commit: r354141 - /httpd/httpd/branches/authz-dev/modules/aaa/mod_auth.h
--On December 5, 2005 7:31:26 PM + [EMAIL PROTECTED] wrote: Still need AUTHZ_DECLINED for now, The converted mod_authz_user is referencing it I think those references should be switched to AUTHZ_DENIED. AUTHZ_DECLINED has no purpose in a provider scheme, IMHO. Declined is saying, Um, doofus, you shouldn't have called me as I can't do anything with this. With the explicit providers, we should be able to prevent that. For the specific cases with mod_authz_user, since the invoker has the method_mask, it can do the check before invocation of the provider - hence, we can abstract that away from the providers themselves. I'd prefer the providers not to even know about the method mask. -- justin
Re: svn commit: r354141 - /httpd/httpd/branches/authz-dev/modules/aaa/mod_auth.h
{
On 12/5/2005 at 12:37:33 pm, in message
[EMAIL PROTECTED], [EMAIL PROTECTED]
wrote:
Still need AUTHZ_DECLINED for now, The converted mod_authz_user is
referencing it
I think those references should be switched to AUTHZ_DENIED.
AUTHZ_DECLINED has no purpose in a provider scheme, IMHO. Declined is
saying, Um, doofus, you shouldn't have called me as I can't do
anything
with this. With the explicit providers, we should be able to prevent
that.
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:
require user foo1, foo2
require group foogroup
require ldap-user whoever
require owner
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
For the specific cases with mod_authz_user, since the invoker has the
method_mask, it can do the check before invocation of the provider -
hence,
we can abstract that away from the providers themselves. I'd prefer
the
providers not to even know about the method mask. -- justin
Agreed, I think that method mask can easily be checked before calling
the provider so that the provider doesn't have to worry about it.
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.
Brad
Re: svn commit: r354141 - /httpd/httpd/branches/authz-dev/modules/aaa/mod_auth.h
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. Perhaps 'AUTH_NEGATIVE'? That implies that the authorisation check gave a negative answer, and the reason for it (unable to authorise because this user can't be authorised with this provider, or the provider said 'no, this user isn't authorised', or...) is irrelevant. Joost
Re: svn commit: r354141 - /httpd/httpd/branches/authz-dev/modules/aaa/mod_auth.h
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
Re: svn commit: r354141 - /httpd/httpd/branches/authz-dev/modules/aaa/mod_auth.h
On Mon, Dec 05, 2005 at 11:10:20PM +0100, Joost de Heer wrote: Perhaps 'AUTH_NEGATIVE'? That implies that the authorisation check gave a negative answer, and the reason for it (unable to authorise because this user can't be authorised with this provider, or the provider said 'no, this user isn't authorised', or...) is irrelevant. That's why I'm claiming that having only one real 'negative' return value (AUTHZ_DENIED) makes sense. -- justin
