[SSSD] Legacy Systems Gateway Scenario

George McCollister george.mccollister at gmail.com
Mon Jul 30 17:53:29 UTC 2012


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



More information about the sssd-devel mailing list