richardb@drives.rta.nsw.gov.au (Richard Begg) writes: > Julian, > > We are interested in whether nntpcache will support user authentication > (username/password) for client access. There seems to be some support for > this in the access file, but nothing in the code. Is this planned in the > near future? > > Cheers, > Richard Begg. I'm re-implementing this feature for the next minor release. I removed it from 2.3.*, because the code was not well tested and there was very little call for it and a mountain of conceptual issues to deal with. A few people have now petitioned (;) to have user authentication back in, but it's important to first understand what user authentication *is* in a multi-server caching environment. It's not as simple as authentication in apache -- multi-server news caching is at least an order of magnitude more complex than http caching. First off - who's doing the authentication? nntpcache or the news server? what if there are multiple servers? nntpcache AND the news server(s)? what if you have a three level cache hierarchy? *who* is being authenticated? the user? the server running nntpcache? If the news servers are doing the authentication, how does that fit in with our delayed group binding and caching? what if the server requires authentication only for particular groups? how do we *know* this in advance? should we be caching successful authentication requests? what if otp's are used? how can we store cached plaintext password authentication requests securely? sha? My view is that server side authentication is such a mire of issues, that one should avoid it entirely, and let nntpcache handle all authentication requests without referral, but this in itself leads to administration problems. i.e how does nntpcache get access to the authentication data? /etc/passwd? nis? kerberos? tacacs? radius? What if the nntpcache administrator doesn't have control over the news server? How are these sub-systems configured and how to they co-operate? Comments welcome :) Cheers, Julian. I
