qdivya1 at avnika.corp.mot.com
qdivya1 at avnika.corp.mot.com
Fri Jul 27 15:28:57 UTC 2001
If I were to implement authorization purely in LDAP, you are correct.
If you relax the authorization inheritance, then this becomes much more
Is there a function in INN that manages authorization for newsgroups -
i.e. checks to see if the newsgroup access is permitted? It should be
possible to use an alternative method of access control by rewriting this
to use, for example, a policy engine ... and that is the model that I was
looking at when I made the initial enquiry.
On Thu, 26 Jul 2001, Ron Jarrell wrote:
> Date: Thu, 26 Jul 2001 23:15:11 -0400
> From: Ron Jarrell <jarrell at solaris.cc.vt.edu>
> To: qdivya1 at avnika.corp.mot.com, graeme+inn-workers at mathie.cx
> Cc: inn-workers at isc.org
> Subject: Re: Authentication ?
> At 11:30 AM 7/26/01 -0500, qdivya1 at avnika.corp.mot.com 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 microsoft.public.es.espanol.soporte.entre.usuarios.internet,
> 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 "!*,local.info" 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.
Divya Sundaram ----------------------------- CONDITUR IN PETRA
We don't need more strength, or greater opportunity. What we
need is to use what we have. - BASIL S. WALSH
--------- Motorola OneIT -- Enabling the Enterprise ----------
More information about the inn-workers