Re: svn commit: r354141 - /httpd/httpd/branches/authz-dev/modules/aaa/mod_auth.h

[Brad Nicholes <BN...@novell.com>]

> {
> 
>>>> On 12/5/2005 at 12:37:33 pm, in message
> <09...@st-augustin.local>, justin@erenkrantz.com
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: Authz refactoring discussion

[Geoffrey Young <ge...@modperlcookbook.org>]

Justin Erenkrantz wrote:
> --On December 6, 2005 11:04:13 AM -0700 Brad Nicholes
> <BN...@novell.com> wrote:
> 
>> Good, then I am +1 on the authz providers only returning AUTHZ_GRANTED
>> or AUTHZ_DENIED.  I don't see a need for anything else.
> 
> 
> FWIW, I do see a case for returning 'uh-oh, an error occurred'.

I'm planning on reviewing the rest next weekish, as I've written a few auth
provider hooks and I'm interested in seeing what happens to them with all of
this.  but here I'll agree - an error condition is nice to have.
additonally, though, chaining providers together with DECLINED conditions is
really useful.  I haven't looked closely enough to see whether this can be
accomodated, but it's nice to have and returning DENIED isn't intuitive in
this case.

fwiw

--Geoff

Re: Authz refactoring discussion (was: Re: svn commit: r354141)

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On December 6, 2005 11:04:13 AM -0700 Brad Nicholes 
<BN...@novell.com> wrote:

> Good, then I am +1 on the authz providers only returning AUTHZ_GRANTED
> or AUTHZ_DENIED.  I don't see a need for anything else.

FWIW, I do see a case for returning 'uh-oh, an error occurred'.

> I'm good with mod_authn_core and mod_authz_core.  Since I already added
> mod_authn.c and mod_authz.c to SVN I'm not sure how to rename them.
> Could you rename the files in SVN and I'll take care of the rest.

Sure.  I've done it in the branch.  For future reference:

svn mv mod_authn.c mod_authn_core.c
svn mv mod_authz.c mod_authz_core.c

For bonus points, you can even do it via URLs.  =)  -- justin

Authz refactoring discussion (was: Re: svn commit: r354141)

[Brad Nicholes <BN...@novell.com>]

>>> On 12/6/2005 at 12:04:47 am, in message
<20...@scotch.ics.uci.edu>, justin@erenkrantz.com
wrote:
> On Mon, Dec 05, 2005 at 02:17:09PM -0700, Brad Nicholes wrote:
>> 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.
> 

Good, then I am +1 on the authz providers only returning AUTHZ_GRANTED
or AUTHZ_DENIED.  I don't see a need for anything else.


> 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

I'm good with mod_authn_core and mod_authz_core.  Since I already added
mod_authn.c and mod_authz.c to SVN I'm not sure how to rename them. 
Could you rename the files in SVN and I'll take care of the rest.

Brad

Re: svn commit: r354141 - /httpd/httpd/branches/authz-dev/modules/aaa/mod_auth.h

[Justin Erenkrantz <ju...@erenkrantz.com>]

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

[Justin Erenkrantz <ju...@erenkrantz.com>]

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

Re: svn commit: r354141 - /httpd/httpd/branches/authz-dev/modules/aaa/mod_auth.h

[Joost de Heer <jo...@sanguis.xs4all.nl>]

> 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