Kerberized authorization service

[Jos Backus]

On Tue, Jan 22, 2008 at 06:38:50PM +1300, Edward Murrell wrote:
> Sounds like something that would be better served using LDAP groups,
> that way it could hook into existing infrastructure.
 
Well, currently I'm using PADL's support for the pam_filter keyword in
/etc/ldap.conf but it feels like a hack. I haven't been able to figure out how
to do this otherwise with the existing software. The O'Reilly LDAP book makes
some suggestions in this area but they don't scale well.

> However, the current PADL pam implementation (last I looked anyway)
> wasn't especially brilliant at providing control for lots of hosts with
> lots of users. It was possible to cobble something together
> using /etc/security/access.conf, but it always felt... odd. Maybe look
> into updating that?
 
Well, I'd rather not have to edit files on each machine as I have to do today
(each machine will have its own customized version of ldap.conf) as it means
that the authorization decision is no longer truly centralized.

I'm really looking for a lightweight security mechanism I can hook into PAM: a
small client which securely connects to one of a set of authorization servers,
passing the chosen server some data and receiving back an authorization
decision. The authorization server in turn can be very simple as it is just a
Kerberized conduit for passing the data from the client to some backend and
passing the backend's decision back to the client. The backend can use any
data store; I'd rather net tie it to LDAP directly as it would require me to
mess with LDAP objects and schema's, something I'm trying to avoid.

To paraphrase, I'm looking for something akin to a Kerberized
tcpclient/tcpserver (part of djb's ucspi-tcp). That might be close enough for
this purpose that only minor modifications would be necessary.

Cheers,
Jos

> Cheers,
> Edward
> 
> On Mon, 2008-01-21 at 14:36 -0800, Jos Backus wrote:
> > 
> > The server:
> > - accepts some client-generated request (containing service,
> >   principal/username, hostname, etc.) over TCP;
> > - sends this data to a backend application;
> > - receives the response ('authorized' or 'not authorized') from the
> > backend;
> > - relays the response to the client.
> > 
> > The client is called by pam_exec from the account group, so it has
> > access to
> > the username; the realm could be supplied on the command line. The
> > client
> > could try multiple authorization servers to ensure availability.
> > 
> > The backend application could simply query a database which is
> > maintained by
> > another application (presumably with an easy to use web frontend).
> > 
> > Thoughts? Would I be better off using GSSAPI instead?
> 

-- 
Jos Backus
jos at catnook.com