You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Sander Striker <st...@apache.org> on 2001/09/07 15:36:19 UTC
Authentication and Authorization
Hi,
I've been going through the modules/aaa directory
and found that modules there seem to implement both
authentication and authorization.
IMO this should be split. Auth and authz are
completely different things and it would be nice
to have different modules to do authentication
in a different way, but still utilize the same
authorization method.
To accomplish this, an extra field would be needed
in request_req (and that's probably not going
to happen): request_req->groups, which holds
a string with all the groups the authenticated
user belongs to.
Or, there could be a new hook which is used to
lookup the groups a user belongs to, or, if
a user belongs to a certain group. This hook
will be called whenever the framework equivalent
of this function is called.
Thoughts?
Sander
/me hides from the 'core stabilizers' that probably
are going to hate me for bringing this up.
Re: Authentication and Authorization
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Sander Striker wrote:
>
> I've been going through the modules/aaa directory
> and found that modules there seem to implement both
> authentication and authorization.
Yar, that's a right bugger. I have had a replacement
system in my head for a couple of years now, but it
requires some substantial changes (like a new structure
and an additional field in the request_rec).
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
RE: Authentication and Authorization
Posted by Sander Striker <st...@apache.org>.
[replying to my own msg]
>> Sander Striker wrote:
>>
>>> IMO this should be split. Auth and authz are
>>> completely different things and it would be nice
>>> to have different modules to do authentication
>>> in a different way, but still utilize the same
>>> authorization method.
>>
>> I'm not sure if splitting them will accomplish this though. From the
>> LDAP auth stuff, the authentication phase and the authorisation phase
>> are separate, but share common configuration parameters (LDAP bind info,
>> for example), so splitting them wouldn't make much sense.
>
> In all the modules the phases are seperate, because they all hook
> check_user_id and check_user_access. There is no way however to
> determine the group a user is in from check_user_id in a non module
^^
this should ofcourse be 'access'.
> specific way. I would like _that_ to be possible, since now, the
> authz part (check_user_access) is doing stuff auth should do: checking
> for group membership.
>
>> Also - there isn't a clear line over what constitutes an authentication
>> token - again, the LDAP authenticator converts a provided username into
>> a DN, which the authorisation phase uses to apply to the require
>> directives. If you have to mix up the different modules, you would need
>> to make sure they are all talking the same language (so to speak).
>
> Yes, but I don't see that as a problem. Right now, the same is
> true for the FakeBasicAuth feature of mod_ssl which provides a one line
> DN as the username.
>
>> Regards,
>> Graham
>
> Sander
RE: Authentication and Authorization
Posted by Sander Striker <st...@apache.org>.
> Sander Striker wrote:
>
> > IMO this should be split. Auth and authz are
> > completely different things and it would be nice
> > to have different modules to do authentication
> > in a different way, but still utilize the same
> > authorization method.
>
> I'm not sure if splitting them will accomplish this though. From the
> LDAP auth stuff, the authentication phase and the authorisation phase
> are separate, but share common configuration parameters (LDAP bind info,
> for example), so splitting them wouldn't make much sense.
In all the modules the phases are seperate, because they all hook
check_user_id and check_user_access. There is no way however to
determine the group a user is in from check_user_id in a non module
specific way. I would like _that_ to be possible, since now, the
authz part (check_user_access) is doing stuff auth should do: checking
for group membership.
> Also - there isn't a clear line over what constitutes an authentication
> token - again, the LDAP authenticator converts a provided username into
> a DN, which the authorisation phase uses to apply to the require
> directives. If you have to mix up the different modules, you would need
> to make sure they are all talking the same language (so to speak).
Yes, but I don't see that as a problem. Right now, the same is
true for the FakeBasicAuth feature of mod_ssl which provides a one line
DN as the username.
> Regards,
> Graham
Sander
Re: Authentication and Authorization
Posted by Graham Leggett <mi...@sharp.fm>.
Sander Striker wrote:
> IMO this should be split. Auth and authz are
> completely different things and it would be nice
> to have different modules to do authentication
> in a different way, but still utilize the same
> authorization method.
I'm not sure if splitting them will accomplish this though. From the
LDAP auth stuff, the authentication phase and the authorisation phase
are separate, but share common configuration parameters (LDAP bind info,
for example), so splitting them wouldn't make much sense.
Also - there isn't a clear line over what constitutes an authentication
token - again, the LDAP authenticator converts a provided username into
a DN, which the authorisation phase uses to apply to the require
directives. If you have to mix up the different modules, you would need
to make sure they are all talking the same language (so to speak).
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Authentication and Authorization
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Can we get to a release candidate? Either that, or we branch, and make someone
responsible for porting forward all 2.0 patches to 2.1. I don't know of anyone
who has the time or inclination to monitor and take responsiblity for applying
all such patches forward ;) Tomcat's repository contains several parallel
branches, but that requires maintenance, and since the same half-dozen committers
work and maintain all branches in parallel, this isn't too bad.
But note that several security fixes were backported very late from the 3.3 branch
back to the Tomcat 3.2.2 branch, nearly slipping past the GA release. It's a bit
of dicey busniess for a 'want to'. Can I suggest you write the code to split them
and propose it, let others hack on it, while a few of us try to take 2.0 to GA?
Then we can branch, continue security and bug fixes to both the 2.0 and 2.1 branch
past its initial GA release, and authn/authz hackers can go a little crazy on the
2.1 branch?
Bill
----- Original Message -----
From: "Graham Leggett" <mi...@sharp.fm>
To: <de...@httpd.apache.org>
Sent: Sunday, September 09, 2001 8:06 AM
Subject: Re: Authentication and Authorization
> "William A. Rowe, Jr." wrote:
>
> > -1 (veto) for 2.0 development. I'd love to see this happen.
> > Not in the current cycle. I was actually contemplating an entire
> > split between the authn/authz storage and methods. But that can't
> > happen in this cycle either if we ever want to get to release.
>
> >From what it seems the focus of v2.0 has shifted from being a pure
> development track to a get-it-out-of-the-door track.
>
> Is it not time to start up a v2.1 development track for people to play
> around in without affecting the stabilising efforts of people in v2.0?
>
> Regards,
> Graham
> --
> -----------------------------------------
> minfrin@sharp.fm "There's a moon
> over Bourbon Street
> tonight..."
Re: Authentication and Authorization
Posted by Graham Leggett <mi...@sharp.fm>.
"William A. Rowe, Jr." wrote:
> -1 (veto) for 2.0 development. I'd love to see this happen.
> Not in the current cycle. I was actually contemplating an entire
> split between the authn/authz storage and methods. But that can't
> happen in this cycle either if we ever want to get to release.
>>From what it seems the focus of v2.0 has shifted from being a pure
development track to a get-it-out-of-the-door track.
Is it not time to start up a v2.1 development track for people to play
around in without affecting the stabilising efforts of people in v2.0?
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Authentication and Authorization
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Sander Striker" <st...@apache.org>
Sent: Friday, September 07, 2001 6:36 AM
> I've been going through the modules/aaa directory
> and found that modules there seem to implement both
> authentication and authorization.
>
> IMO this should be split. Auth and authz are
> completely different things and it would be nice
> to have different modules to do authentication
> in a different way, but still utilize the same
> authorization method.
>
> Thoughts?
-1 (veto) for 2.0 development. I'd love to see this happen.
Not in the current cycle. I was actually contemplating an entire
split between the authn/authz storage and methods. But that can't
happen in this cycle either if we ever want to get to release.
Apache 2.0 in 2004 will be a really, really bad joke if we can't
at least focus on giving end users an optimized and stable end result.
Bill
RE: Authentication and Authorization
Posted by Sander Striker <st...@apache.org>.
> From: sterling [mailto:sterling@covalent.net]
> Hi -
>
> IMHO, there is no apache dependency that requires auth and authz to be in
> the same module.... usually, it is just logical that the application
> handle both phases - but that is on the module writer.
Yes, but the choice of doing group lookups using a file/db/whatever
is tied in with the authz phase. I'd like to be able to reuse the
check if a user (belonging to a certain group) is authorized to
access a certain url.
> On Fri, 7 Sep 2001, Sander Striker wrote:
>
>> Hi,
>>
>> I've been going through the modules/aaa directory
>> and found that modules there seem to implement both
>> authentication and authorization.
>>
>> IMO this should be split. Auth and authz are
>> completely different things and it would be nice
>> to have different modules to do authentication
>> in a different way, but still utilize the same
>> authorization method.
>>
>> To accomplish this, an extra field would be needed
>> in request_req (and that's probably not going
>> to happen): request_req->groups, which holds
>> a string with all the groups the authenticated
>> user belongs to.
>
> welp, authorization does NOT imply groups... it could require all sorts
> of information to authorize.
> Authentication is simply 'who is this person' and authorization is 'are
> they authorized to receive the requested location'.
Yes, but when looking at the aaa modules, all of them seem to authenticate
the user in check_user_id (which is good). In auth_checker, the group is
looked up and then authz is checked. The last part is highly duplicated
(I don't care too much about that). What I would like to see is that a
_common_ thing as group lookups be seperated out of the authz part. Ie,
let there be a hook get_user_groups(?), which is invoked when
ap_get_user_groups is called.
> Hence, the authorization phase (read auth_checker) is responsible for
> reading the requirements and trying to validate them (given usually a
> valid-user in the r->user field). If that means check if they are part of
> a group, so be it. If it means check if they have red hair - that works
> too.
Doh! :)
> Group lookup is NOT part of authentication IMHO. Many authz solutions
> have nothing to do with 'groups'.
Although many do not, it is common (you only have to look at the aaa
modules).
>> Or, there could be a new hook which is used to
>> lookup the groups a user belongs to, or, if
>> a user belongs to a certain group. This hook
>> will be called whenever the framework equivalent
>> of this function is called.
>>
>> Thoughts?
>>
>> Sander
>>
>> /me hides from the 'core stabilizers' that probably
>> are going to hate me for bringing this up.
>
>
> I don't think this should be skipped because of 'stabilization'. I think
> it should be skipped because it is not the right architecture.
I think I agree with you when it comes to adding fields to request_req, but
to introduce a new hook should be ok IMO. But, this won't be touched anyhow
very quickly, looking at the ~'hold off until 2.1' reactions.
> sterling
Sander
Re: Authentication and Authorization
Posted by sterling <st...@covalent.net>.
Hi -
IMHO, there is no apache dependency that requires auth and authz to be in
the same module.... usually, it is just logical that the application
handle both phases - but that is on the module writer.
On Fri, 7 Sep 2001, Sander Striker wrote:
> Hi,
>
> I've been going through the modules/aaa directory
> and found that modules there seem to implement both
> authentication and authorization.
>
> IMO this should be split. Auth and authz are
> completely different things and it would be nice
> to have different modules to do authentication
> in a different way, but still utilize the same
> authorization method.
>
> To accomplish this, an extra field would be needed
> in request_req (and that's probably not going
> to happen): request_req->groups, which holds
> a string with all the groups the authenticated
> user belongs to.
welp, authorization does NOT imply groups... it could require all sorts
of information to authorize.
Authentication is simply 'who is this person' and authorization is 'are
they authorized to receive the requested location'.
Hence, the authorization phase (read auth_checker) is responsible for
reading the requirements and trying to validate them (given usually a
valid-user in the r->user field). If that means check if they are part of
a group, so be it. If it means check if they have red hair - that works
too.
Group lookup is NOT part of authentication IMHO. Many authz solutions
have nothing to do with 'groups'.
>
> Or, there could be a new hook which is used to
> lookup the groups a user belongs to, or, if
> a user belongs to a certain group. This hook
> will be called whenever the framework equivalent
> of this function is called.
>
> Thoughts?
>
> Sander
>
> /me hides from the 'core stabilizers' that probably
> are going to hate me for bringing this up.
I don't think this should be skipped because of 'stabilization'. I think
it should be skipped because it is not the right architecture.
sterling
Re: Authentication and Authorization
Posted by Graham Leggett <mi...@sharp.fm>.
Joshua Slive wrote:
> Just as a point of information, a relatively frequent request that I hear
> from users is to provide group information in an env variable (REMOTE_GROUPS
> analagous to REMOTE_USER). This would certainly facilitate that.
I am about to add something like this to mod_auth_ldap - putting group
memberships in environment variables. This empowers you to use the #if
functionality of mod_include to either display or not display certain
HTML depending on group membership.
Ideally though this should be implemented consistently over all modules.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
RE: Authentication and Authorization
Posted by Joshua Slive <jo...@slive.ca>.
> -----Original Message-----
> From: Sander Striker [mailto:striker@apache.org]
> I've been going through the modules/aaa directory
> and found that modules there seem to implement both
> authentication and authorization.
>
> IMO this should be split. Auth and authz are
> completely different things and it would be nice
> to have different modules to do authentication
> in a different way, but still utilize the same
> authorization method.
I believe this has been on the "future" list for apache for a very long
time. I'd like to see it happen. It is nuts that the dozens of mod_auth_*
modules need to redo all that logic.
>
> To accomplish this, an extra field would be needed
> in request_req (and that's probably not going
> to happen): request_req->groups, which holds
> a string with all the groups the authenticated
> user belongs to.
>
Just as a point of information, a relatively frequent request that I hear
from users is to provide group information in an env variable (REMOTE_GROUPS
analagous to REMOTE_USER). This would certainly facilitate that.
Joshua.