NNRP Perl Auth and LDAP Authentication

[Jeffrey M. Vinocur]

On Mon, 25 Feb 2002, Sundaram Divya-QDIVYA1 wrote:

> 	I would additionally like to control access to
> 	newsgroups based upon the subscribers' membership
> 	in an LDAP group associated with the newsgroup.

Ahh.  This you will not be able to do with pamckpasswd.


> For example, for the newsgroup "foobar.forsale", there would
> be a group in LDAP "cn=foobar.forsale,ou=newsserver,ou=groups,
> dc=foo,dc=com". If this group does not exist, then all users
> who authenticate properly would have access. If this group
> exists, then you'd have to be a member of this group to read
> this group.

If this is what you want, then yeah, you're going to need to use the perl
hooks.


> In reality, this is useful only when we are providing access
> control to "local" newsgroups. I wouldn't expect that this
> is how I'd control access to public Usenet newsgroups. I'd
> want to use regular readers.conf style access control for
> those.

This part makes me think that you should try the new perlhooks in 2.4, but
I'm not sure you'll be able to use readers.conf even in that case.


> There are two ways to approach this problem. One is to have
> a cron job that peruses the groups and builds a readers.conf
> and then executes a "ctlinnd reload readers.conf" on a periodic
> basis.

You could do this -- if the groups don't change very often, it might be
easiest.  Kinda ugly, though.


Note that you don't need to reload readers.conf, it is reread by nnrpd on
every connection.  (Mmm, unless you're using nnrpd -D, I don't know about
that case.)


> The other way is to use LDAP for access control as well.

This is probably more work, but a bit cleaner.  If you do something like
this, for dynamically generating access groups, we'd be happy to see it.


> I would like to build a way that can be re-used by future
> deployments of INND. (In fact, this feature was the primary
> reason for us choosing to go with Netscape Collabra in
> the first place).

Well.  The only thing I have to say here is that if you end up using the
perl hooks, you should probably work off of CURRENT, because otherwise
you'll have to port your code to the new system when you upgrade.


-- 
Jeffrey M. Vinocur
jeff at litech.org