On 07/27/2012 09:02 AM, Simo Sorce wrote:
Hi George, I guess one of the reasons you want to tie this into SSSD
is
the caching capabilities we get for free with it ?
correct. custom security
solution also tend to be full of holes, to the
extent possible it's better to rely on something standard.
As a general concept it would seem like a useful idea, however I am
not
sure I can think of many other applications beyond HTTP ?
For other protocols IP
based virtual hosting could be used.
Also what elements do you want to consider for this interface ?
Are you going to use it as an authenticated (reverse) proxy and use only
user/dest pairs ? Or would you take in account also src address/other ?
Also
account, src address would be nice to have.
You are also talking about Apache, why not squid ? Not that it
really
matters, but squid has some specific interfaces and I guess this should
be a generic library and interface ?
As long as there was a C library to perform
the operations that decision
could be delegated to the application designer. If the legacy system
wasn't designed with a security mind set in the first place, directly
forwarding requests could be risky.
In general it would be nice to have a comprehensive library that can
do
a number of functions: authentication (with kerberos, fallback to LDAP,
and maybe other options like Oauth/BrowesrID ..), authorization,
including fetching groups from a MS-PAC and/or LDAP, and finally HBAC.
Agreed.
We could do some of it via the current PAM interface, but it looks
like
if we look at the general problem what we need is a bit more complex
interface into SSSD.
Either an entirely new responder and client could be created
or the pam
responder could be extended and versioned as v4 (currently its at v3)
and a new generic library could be written to use the v4 pam interface.
Finally, changing the client protocol is generally frowned on as it
can
easily break installation on upgrade (some processes may have the old
plugin in memory and sssd starts requiring the new format). In general
any change in the client protocol should be backward compatible, or use
a completely new interface.
By client protocol I'm assuming you mean the
protocol used between the
responder and the client. I wasn't suggesting modifying the pam
responder or client, rather:
1) Modifying the responder to data provider DBUS interface to
include destination host (pam_data is the data structure used)
2) Modifying existing data providers such as IPA to accept (or
reject) requests with destination host
3) Creating a new responder that communicated with a new general
purpose library.
Simo.
George