Re: Kerberized authorization service
- From: edward@xxxxxxxxxxxxx
- Date: Sun, 27 Jan 2008 11:35:01 +1300 (NZDT)
Hm, yes, I see where you are coming from.
I think this is an area where the OSS world has the infrastructure, but
not the details to pull off what you want. I am personally a bit loathe to
suggest adding yet another service to the mix of account management,
especially given that it's unlikely to be supported by Win/Mac any time
soon, whereas the LDAP solution is already what they do. Hence why I would
suggest something tying into that. I can see the benefit of the service
you are suggesting though.
*Diverges a bit into LDAP*
In a perfect world, I would have the machine in the LDAP tree, with
containers of some description off for various services, and/or a default.
The containers would hold a list of allow/deny groups. It would be
possible to alias groups for allow/deny lists, along with creating custom
groups just for that service on that machine if so desired.
As a simple example, the mail server could have an shell group with one
allow entry point to the 'all users' group for imap/smtp access, and shell
group with a pointer to the sysadmins group.
If this was standardized into pam_ldap, then that would utilize existing
infrastructure. If you're going to hack C code in the security libs, it
would probably be better to do it with established work, plus it would
save you writing a server. Given that GSSAPI is already support for
NSS/PAM, you could still use Kerberos to keep the data secure, and allow
machines to change thier own ACL's via their host key.
Hmm, maybe this should be a project of mine... (maybe)
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
.
- Prev by Date: Re: [lib]kadm on Windows?
- Next by Date: Re: password expiry for a principal
- Previous by thread: Re: Kerberized authorization service
- Next by thread: Re: Kerberized authorization service
- Index(es):
Relevant Pages
|
