You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by di...@covalent.net on 2002/07/10 20:28:45 UTC
Auth - how much legacy to preserve ?
While doing this patch (and ending up with 3 very small modules); I found
the following legacy behaviour. Any feels as to if we shall kill these
surprizing behaviourisms in 2.0 or stay as close to 1.3 as possibe ?:
-> if there are no requires - but there is Auth happening
we actively OK.
-> If there are no requires for the method (but there are
requires for that directory for other methods)
we actively OK.
-> If we have for example a (Group,..)File but opening it failes
then we ignore any 'require group' and DECLINE to other modules.
Proposal to fixing these leaks (comment now or wait for code) and allowing
small footprint modules to take part of the process over:
-> mod_auth_file
auth UserID/passwd against file
DECLINE if no file configured
ERROR if file read error (was DECLINE/UNAUTH)
OK if ok
DECLINE if UID not found & non-authoritative
UNAUTH otherwise
-> mod_auth_groupfile
checks UserID against required 'require (valid-)group'
DECLINE if no requirements at all (was OK)
DECLINE if no group file configurued
ERROR if file read error (was IGNORE)
OK if in a group
DECLINE if no applicable method requirments (was OK)
DECLINE if no recognized method requirements
DECLINE if not authoritative and not in recognized groups.
UNAUTH otherwsie
-> mod_require_user
checks UserID against required 'require (valid-)user'
DECLINE if no requirements at all (was OK)
OK if in the list /valid user
DECLINE if no applicable method requirements. (was OK)
DECLINE if no recognized requirements
DECLINE if there are lists, not in list but non
authoritative
UNAUTH otherwise
And then - to get closer to the old apache:
-> mod_auth_default
auth DECLINE if no Basic Auth header/r->user.
DECLINE if not authoritative
UNAUTH otherwise
check DECLINE if no r->user
OK if no requires (*)
OK if no applicable method requirements (*)
DECLINE if not authoriative
UNAUTH otherwise
*: I.e. in mod_auth_default we 'fix' to get closer to the behaviour from
1.3; An alternative would be to not do this and change to always UNAUTH
then when there is r->user information provided and not authoritative.
I do want to allow fall through - so that a perl/php/java backend is able
to get access if/when needed. Thus:
-> apache core
auth OK
check OK
Of course - the mod_auth_default could also be in the core of the http
proocol handling.
Does this make sense ?
Dw.
--
Dirk-Willem van Gulik
Re: Auth - how much legacy to preserve ?
Posted by di...@covalent.net.
> > -> If we have for example a (Group,..)File but opening it failes
> > then we ignore any 'require group' and DECLINE to other modules.
>
> I don't find those surprising at all; they're what I would expect.
Hmm - but that means that if someone edits the group files, saves it as
root with the wrong umask or removes it by accident - then something like:
require group admins
suddenly gets ignored. This is especially galling if the edit was to
remove someone :-).
> > ERROR if file read error (was DECLINE/UNAUTH)
>
> No, UNAUTH if authoritative, DECLINE otherwise. The client should NOT be
> told there is a config error. Log the problem.
UNAUTH suggest that the page may be availble if the user fixes something.
Which is not the case. So we cannot give that.
But if we DECLINE - and someone then gives an UNAUTH then the client is
free to a) retry with another password -or- purge the buffered password
from its state for that realm. That can give things like a flurry of
dialog boxes when for example a stylesheet/javascript is still fetching
images. Would it not be saver in general to give a 500 ? Or something that
signals a fault - and please do not retry this unless something has
changed on -my- end; not the client end.
> UNAUTH. DON'T tell the user there's anything except a Boolean auth failure.
Not sure - I see:
-> not enough auth credentials
unauth -> i.e. try again with proper credentials or give up
OK -> you have the credentials - here is the page
ERROR -> sorry - your credentails may be right - but a
problem on my side prvents me from giving it to
you right now. (Or perhaps use Not Available).
Dw
Re: Auth - how much legacy to preserve ?
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
dirkx@covalent.net wrote:
>
> While doing this patch (and ending up with 3 very small modules); I found
> the following legacy behaviour. Any feels as to if we shall kill these
> surprizing behaviourisms in 2.0 or stay as close to 1.3 as possibe ?:
>
> -> if there are no requires - but there is Auth happening
> we actively OK.
>
> -> If there are no requires for the method (but there are
> requires for that directory for other methods)
> we actively OK.
>
> -> If we have for example a (Group,..)File but opening it failes
> then we ignore any 'require group' and DECLINE to other modules.
I don't find those surprising at all; they're what I would expect.
> Proposal to fixing these leaks (comment now or wait for code) and allowing
> small footprint modules to take part of the process over:
>
> -> mod_auth_file
> auth UserID/passwd against file
> DECLINE if no file configured
If not file configured, but Require present, UNAUTH (or 500) if authoritative;
otherwise DECLINE.
> ERROR if file read error (was DECLINE/UNAUTH)
No, UNAUTH if authoritative, DECLINE otherwise. The client should NOT be
told there is a config error. Log the problem.
> -> mod_auth_groupfile
> checks UserID against required 'require (valid-)group'
> DECLINE if no requirements at all (was OK)
> DECLINE if no group file configurued
No, similar to above.
> ERROR if file read error (was IGNORE)
UNAUTH. DON'T tell the user there's anything except a Boolean auth failure.
Et cetera.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: Auth - how much legacy to preserve ?
Posted by di...@covalent.net.
On Wed, 10 Jul 2002, William A. Rowe, Jr. wrote:
> On Wed, 10 Jul 2002, Pier wrote:
>> ...
> Very cool.
>
> Are you also considering multiple 'user' identities? E.g., If I'm using client
> cert ssl auth [one identity], with basic encryption [a different identity], it
> would be nice to walk the 'identities' list.
>
> In that, you could have several types of 'identities' in a list, e.g. 'user',
> 'group', 'role', etc. The IP and DNS of the client themselves are also
> 'identities', although they are addresses.
I've done some commercial systems in the past which used a token based
evidence scheme. Which worked very well with apache and whcih allowed very
quick integration with apache/per-user-custimization and so on. I.e. along
the lines of:
connection->request-> [ token1 ]
[ token2 ]
...
where the list of tokens would a) increase as the request was more and
more authenticated and b) where the list of tokens collected could
be cached across requests under certain conditions.
tokenX -> value (*)
[ fact1 ]
[ fact2 ]
....
fact1 -> Username 'foo'
...more key valye pairs
evidence -> evidence3 (*)
fact2 -> Password '123'
...more key valye pairs
evidence -> evidence3 (*)
fact3 -> Group 'admins'
..more key valye pairs
evidence -> evidence3 (*)
-> evidence4
fact4 -> Group 'plumbers'
..more key valye pairs
evidence -> evidence3 (*)
-> evidence4
fact5 -> address, contract number
fact6 -> SIM card # of WAP-ing phone
fact7 -> background colour preference
fact8 -> 1200 airmiles and a gold pass
evidence3 -> Source BasicAuth (*)
Date (int) (*)
Expires (int) (*)
Use (flags) (*)
evidence4 -> Source /etc/group (*)
Date (int) (*)
Expires (int) (*)
Use (flags) (*)
key1 value1
key2 value2
key3 value3
key4 value4
key5 value5
Note: evidence is not recursive; i.e. evidence itself
is not based on evidence. Which may have been
a mistake. But instead something like a GroupAuther
would insist of evidence from BasicAuth (or other
constrained vocabulaire Source values) to be
present before it would run (another problem with
ordering here!).
Note: The entries marked '*' are mandatory and have
a controlled vocabulare/value set. The
rest are simply ascii-key and UTF8 value pairs.
Note: The USE flag was not really used - see below.
It worked quite well from the side of the admins and the folks who had to
configure the webserver/radius/tacacs and the systems which integrated
with SS7 telephony layer and the API into the communication with SIM
cards. I.e. they could express what sort of controls they wanted for a
specific directory or something (and some of those where time/resource
consumption depended) and found it easy to extract audit data. Or map out
who was responsible for bad data/deceisions when, say, a complaint came
in that some unwarranted transfer was done.
But... though easy - it was a very 'inefficient' to program modules
against. And occasionaly let to 'storms' of requests to auth backends for
something as silly as fetching a transparent gif spacer.
I.e. when you had to check a 'require' this-and-this property then you had
to go through the whole token->fact (if it is my type)->value sequence for
all the tokens collected.
It was found hard to optimize with, say, a per user property table due to
lot of overlap in KEY values but with different meanings and/or evidence.
Often one set of evidence was required before another set could be based
upon it. E.g. IP address -> Dail-in modem bank slot -> CallerID of calling
line -> entity-which-has-the-phone contract for that physical line.
This lead ultimately to a scheme where one would check for the presence of
a top level token (i.e. has this request got the 'foobar' token) and with
that in handl allow access into the over-18-only gambling site or collect
your airmiles site.
The use flag indicated if evidence could be kept cross request or even
across different servers based on a crypto cookie, SSL info, etc. But over
time the 'use' style flag was used less and less; and rather evidence was
simply destroyed or made inaccessible itself - and the code would detect a
dangling reference and not follow it (at the cost of a cheap in memory
berkely db lookup). I.e. rather than say 'this evidence can only be used
on properly SSL authed connections' one would say - only provide this
evidence to this webserver instance or this set of directories which we
know only allow SSL authed connections in.
There are some paralels with SAML as it is beeing proposed now - and I see
similar problems.
But it sure would be nice to have a ->notes table which is a bit more
fancifull and an apache which has a bit more of a registry behavour when
it comes to registering and coordinating controlled values (or per module
namespaces, etc).
Dw
Re: Auth - how much legacy to preserve ?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:27 PM 7/10/2002, dirkx@covalent.net wrote:
>On Wed, 10 Jul 2002, Pier Fumagalli wrote:
>
> > Dirk, since you're working on a patch for Auth, would it be possible to
> have
> > the groups list somewhere in the request structure? It would be great with
> > web applications, where we can match groups with roles (therefore allowing
> > authentication to be processed by apache entirely)...
>
>Well - r->user, or any r->credentials are valid there; as they come from
>the protocol; i.e. are part of the request.
>
>The group information can, depending on protocol, come from more than one
>source
>
> -> provided with the credentials (e.g. like the 'account'
> dimension in ftp or your kerberos realm).
>
> -> a user can belong to N groups as returned by an
> all knowing auth system when asked.
>
> -> a check if the user was in a list of M groups can have
> yieled that he was a member of P groups which is a
> subset of M.
>
>Once you add group; there are other dimensions too; i.e. think of the
>login.conf resources on BSD, a much more mature framework like that on
>mainframes, and so on.
Very cool.
Are you also considering multiple 'user' identities? E.g., If I'm using client
cert ssl auth [one identity], with basic encryption [a different identity], it
would be nice to walk the 'identities' list.
In that, you could have several types of 'identities' in a list, e.g. 'user',
'group', 'role', etc. The IP and DNS of the client themselves are also
'identities', although they are addresses.
It would be nice to mix 'n match all of these into a single API.
Bill
Re: Auth - how much legacy to preserve ?
Posted by Pier Fumagalli <pi...@betaversion.org>.
dirkx@covalent.net <di...@covalent.net> wrote:
>
> On Wed, 10 Jul 2002, Pier Fumagalli wrote:
>
>> Dirk, since you're working on a patch for Auth, would it be possible to have
>> the groups list somewhere in the request structure? It would be great with
>> web applications, where we can match groups with roles (therefore allowing
>> authentication to be processed by apache entirely)...
>
> Well - r->user, or any r->credentials are valid there; as they come from
> the protocol; i.e. are part of the request.
>
> The group information can, depending on protocol, come from more than one
> source
>
> -> provided with the credentials (e.g. like the 'account'
> dimension in ftp or your kerberos realm).
>
> -> a user can belong to N groups as returned by an
> all knowing auth system when asked.
>
> -> a check if the user was in a list of M groups can have
> yieled that he was a member of P groups which is a
> subset of M.
>
> Once you add group; there are other dimensions too; i.e. think of the
> login.conf resources on BSD, a much more mature framework like that on
> mainframes, and so on.
>
> So this is perhaps a bit more complex than just that.
>
> What is it you would feel as most useful in the web application world -
> could you elaborate ?
Indeed it is complex...
Basically, a web application in java land specifies some "security
constraints" in the "web.xml" file (its deployment descriptor). It relies on
two main concepts: user (doh!) and a thing called "role" which is more or
less the parallel of a group. Each user can have zero-or-more of these
"roles" (can be in zero or more groups with the current mod_auth).
Given the idea that I want my entire web site to be controlled by (let's
say) a single user/groups database, I need to pass to the servlet container
the list of "roles" to which every user is associated with, therefore its
list of groups, because at any time (even if the servlet is not under any
particular security constraint), someone might call the "isUserInRole" call,
and verify if a user is actually in a particular group...
I can do that passing the list of groups to the roles to the servlet
container, or calling back Apache and if mod_auth could provide a hook to
verify a particular user/role association, that would be even great...
Does this make sense?
Pier
--
[Perl] combines all the worst aspects of C and Lisp: a billion of different
sublanguages in one monolithic executable. It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: Auth - how much legacy to preserve ?
Posted by di...@covalent.net.
On Wed, 10 Jul 2002, Pier Fumagalli wrote:
> Dirk, since you're working on a patch for Auth, would it be possible to have
> the groups list somewhere in the request structure? It would be great with
> web applications, where we can match groups with roles (therefore allowing
> authentication to be processed by apache entirely)...
Well - r->user, or any r->credentials are valid there; as they come from
the protocol; i.e. are part of the request.
The group information can, depending on protocol, come from more than one
source
-> provided with the credentials (e.g. like the 'account'
dimension in ftp or your kerberos realm).
-> a user can belong to N groups as returned by an
all knowing auth system when asked.
-> a check if the user was in a list of M groups can have
yieled that he was a member of P groups which is a
subset of M.
Once you add group; there are other dimensions too; i.e. think of the
login.conf resources on BSD, a much more mature framework like that on
mainframes, and so on.
So this is perhaps a bit more complex than just that.
What is it you would feel as most useful in the web application world -
could you elaborate ?
Dw.
Re: Auth - how much legacy to preserve ?
Posted by Pier Fumagalli <pi...@betaversion.org>.
Dirk, since you're working on a patch for Auth, would it be possible to have
the groups list somewhere in the request structure? It would be great with
web applications, where we can match groups with roles (therefore allowing
authentication to be processed by apache entirely)...
Pier
dirkx@covalent.net <di...@covalent.net> wrote:
>
> While doing this patch (and ending up with 3 very small modules); I found
> the following legacy behaviour. Any feels as to if we shall kill these
> surprizing behaviourisms in 2.0 or stay as close to 1.3 as possibe ?:
>
> -> if there are no requires - but there is Auth happening
> we actively OK.
>
> -> If there are no requires for the method (but there are
> requires for that directory for other methods)
> we actively OK.
>
> -> If we have for example a (Group,..)File but opening it failes
> then we ignore any 'require group' and DECLINE to other modules.
>
> Proposal to fixing these leaks (comment now or wait for code) and allowing
> small footprint modules to take part of the process over:
>
> -> mod_auth_file
> auth UserID/passwd against file
> DECLINE if no file configured
> ERROR if file read error (was DECLINE/UNAUTH)
> OK if ok
> DECLINE if UID not found & non-authoritative
> UNAUTH otherwise
>
> -> mod_auth_groupfile
> checks UserID against required 'require (valid-)group'
> DECLINE if no requirements at all (was OK)
> DECLINE if no group file configurued
> ERROR if file read error (was IGNORE)
> OK if in a group
> DECLINE if no applicable method requirments (was OK)
> DECLINE if no recognized method requirements
> DECLINE if not authoritative and not in recognized groups.
> UNAUTH otherwsie
>
> -> mod_require_user
> checks UserID against required 'require (valid-)user'
> DECLINE if no requirements at all (was OK)
> OK if in the list /valid user
> DECLINE if no applicable method requirements. (was OK)
> DECLINE if no recognized requirements
> DECLINE if there are lists, not in list but non
> authoritative
> UNAUTH otherwise
>
> And then - to get closer to the old apache:
>
> -> mod_auth_default
> auth DECLINE if no Basic Auth header/r->user.
> DECLINE if not authoritative
> UNAUTH otherwise
>
> check DECLINE if no r->user
> OK if no requires (*)
> OK if no applicable method requirements (*)
> DECLINE if not authoriative
> UNAUTH otherwise
>
> *: I.e. in mod_auth_default we 'fix' to get closer to the behaviour from
> 1.3; An alternative would be to not do this and change to always UNAUTH
> then when there is r->user information provided and not authoritative.
>
> I do want to allow fall through - so that a perl/php/java backend is able
> to get access if/when needed. Thus:
>
> -> apache core
> auth OK
> check OK
>
> Of course - the mod_auth_default could also be in the core of the http
> proocol handling.
>
> Does this make sense ?
>
> Dw.
--
[Perl] combines all the worst aspects of C and Lisp: a billion of different
sublanguages in one monolithic executable. It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]