Authentication ?

Ron Jarrell jarrell at
Fri Jul 27 03:15:11 UTC 2001

At 11:30 AM 7/26/01 -0500, qdivya1 at wrote:

>I realize that AUTHENTICATION works against LDAP w/o any problems.
>What I really wish to focus on is AUthorization. The idea I had been
>mulling over in my mind was something akin to the following:
>For each NewsGroup, create a container group listing the users
>that are allowed to access that news group.
>The listing can be of two formats, either an explicit list of users, or
>a policy/rule that describes a method of qualifying users (or a
>If a "corresponding" container group is not listed for a newsgroup, see if
>there is one that exists for its parent newsgroup ... If the parent does
>not have a container group, then check its parent etc. ...
>A default authorization rule would apply to the "root" news group.

Well, having an authorization scheme is nice, but that's potentially a *lot* of
overhead.  You're talking having to reauthorize for every group command,
since it's the group that knows who can read it, not the user who know what
he can read.

Let's say bob wants to read,
and that's not a group you particularly control, so the root rule applies.  When we check
for authority to read that group, under your design we'll need check for the existence of
8 different ldap entries before deciding that the root rule applies.  Careful use of indexes and
naming conventions might resolve that down to one failed search, but if you search for, 
say microsoft.*, and there's 100 microsoft groups you do control, but not that one, that's
still a lot of wading through groups.

It'd be completely unworkable, as well as requiring changes to support on the fly
authorization at the group command.

More reasonable is a class based system where the user know what he can do.

So "bob" wants to read news.  When he authenticates, we query his class.
We discover he's a "foobar" class user.  We check the foobar class, and it's
allowed to read "!*," in it's "allowed newsgroups" attribute.

Doug, however, is also a foobar class user, but he's got a local per-user override
of "*", so has full access, despite only being a foobar.

Thus we reduce it to at most 2 lookups, and we just carry the access mask
around in the process.

And, of course, that requires comparatively trivial extensions to what already
goes on, and, in fact, could be done entirely today by careful writing of your
readers.conf rules.  And if you were determined to stick the authorization
rules in ldap now, but didn't want to much with the inn code, you could easily
write something to every X period of time, walk your ldap directory and build
a dynamic readers.conf file based on the contents.

More information about the inn-workers mailing list