[inn-workers] innd 2.x LDAP authorization support

Todd Olson tco2 at cornell.edu
Mon Aug 25 19:49:48 UTC 2008


Hi

At 14:51 -0400 2008-08-25, Jonathan Siegle wrote:
>    Here at Penn State, we use kerberos to authenticate users and ldap for authorization information. I'm considering writing this type of authorization procedure for nnrpd so that I don't need to write 8k userids for the staff group, 90k for students, etc. I would rather create a new token for readers.conf that implies an ldap group. For now, I'll say the token is LDAP_GROUP.

Here at Cornell University I have a very similar need.
I believe the answer is to use one of the   perl_access / python_access
features described in the readers.conf man page.


However, because I have only a small number of authorization possibilities
I have actually implemented my solution some what differently.

What I am currently doing is

   1) use 'auth:' and or 'res:' in an 'auth' block to run
      a script that runs auth_krb5.c  to get the identity of the user

   2) that script caches the identity to a file on disk

   3) and FAILS
      this causes nnrpd to run additional 'auth:' and 'res:' scripts
      from additional 'auth' blocks that examines this cached information

   4) I have one auth block set up for each authorization possibility,
      one of them will succeed for the user in question

   5) I use the 'key:' tag to bind this auth block to a particular 'access'
      block which then sets the read/write lists of news groups that
      user can access.
           (note that I could have used different domains for this
           (but since I write the user at domain in to the headers
           (when they post I and I wanted to not expose the detailed
           (authorization information I had to use the 'key:' feature

note that step (2) is a performance optimization.
I could have just had many auth blocks and let each one run auth_krb5.c
but that would put an needed load on the KDC.


Most likely this is very unclear.
Here is a simplified readers.conf of what I have had running for
a couple of years.

auth "rization01" {
    key: "rization01"
    hosts: "*"
    res:   "evaluate_for rization01"
    auth:  "evaluate_for rization01"
}

auth "rization02" {
    key: "rization02"
    hosts: "*"
    res:   "evaluate_for rization02"
    auth:  "evaluate_for rization02"
}

auth "realwork" {
    key: "never_match_an_access"
    hosts: "*"
    res:   "res_gather_save_fail"
    auth:  "auth_gather_save_fail"
}


access "rization01" {
    key: "rization01"
    users: "*@cornell*"
    read:  "*,!cornell.special.*"
}

access "rization02" {
    key: "rization02"
    users: "*@cornell*"
    read:  "*"
    post:  "*,!cornell.special.*"
}


= = = = = = =
The auth_gather_save_fail script calls auth_krb5
and then looks up the authorization for that user
and caches it to disk in a file with the pid of that nnrpd and fails

The evaluate_for  script finds the cached information based on the pid of
that nnrpd, and checks if the authorization matchs that implied by the
command line argument to evaluate_for.  If it does it succeeds.
If not then it fails.   Hum ... also this script cleans up the cache
when appropriate ... which is always after it succeeds, and since
in my case at least one of the evaluate_for runs succeeds I'm okay.
Otherwise I'd add another auth block at the top to run a script to
do the cleanup and fail.

= = = = =
I've also had to deal with clauses where not authentication is required
at which point laying out the readers.conf file is a bit counter intuitive
but can be made to work ... at least for me.

=====
This is a real distortion of what readers.conf was intended for
but it works (!) for me for several years.

It does not scale well to may authorization groups.

I would be much happier if I were using  perl_access or python_access
but I have not had time to build an nnrpd with perl or python.

If you have questions please feel free to contact me.

Regards,
Todd Olson
Cornell University


More information about the inn-workers mailing list