Re: RFD: authentication/access control

[Christophe Kalt <kalt@xxxxxxxxxxx>]

On Jun 13, Andrew Snare wrote:
| 
| It would be much nicer to have a sibling process that was used for
| this kind of authentication -- rather than invoke the same process
| over and over for each connection, it would make more sense to have a
| single process that was asked about each connection.
| 
| It could be possible to use/extend the existing SERVICE features of
| ircd for this kind of thing, which would be kind of nice/neat and
| allow authentication to be done on a separate machine. An alternative
| might be to modify the semantics of the R-line to allow for a single
| process.

Because ircd should be in control, I'm more thinking of a
slave rather than sibling process.  And for the same reason
I don't think a SERVICE would be appropriate.
Altho, putting authentication on a separate machine can be a
problem. (identd lookups wouldn't work..)

| Eventually it might even be possible to replace I/Y/K/R lines (in
| terms of user-authentication and access-control) with this single
| sibling process. This would have the advantage of shifting policies
| out of the ircd and into what could become a separate "management"
| module. It would have the disadvantage of problems if the process
| died, and that policy wouldn't be as readily available via /stats
| (although that's currently true for policy implemented via R-lines
| anyway).

I wonder what the control freaks will think of this (not
being able to see who/what can access a server).

Now that I have given this some more thoughts, I think that
mostly what is needed is more flexibility to do some
authentication.  If successful, this authentication can
lead to 2 results: the username associated with the
connection and/or the indication that the connection should
be rejected.

the first part corresponds to ident lookups (and more),
the second part corresponds to R lines (K line delegation).

Y lines need information known by ircd only, and should
probably remain there; I also don't see any advantage in
taking I/K lines outside ircd.