[SSSD] Legacy Systems Gateway Scenario

Simo Sorce simo at redhat.com
Fri Jul 27 14:02:11 UTC 2012


On Thu, 2012-07-26 at 14:47 -0500, George McCollister wrote:
> I'd appreciate any feedback/ideas anyone might have on a possible 
> solution for a scenario I'm finding quite frequently when FreeIPA is 
> proposed for centralized security.
> 
> In this scenario legacy systems which don't support centralized access 
> control (or are hopelessly incompatible) co-exist with modern Linux 
> systems. One possible solution is to place the legacy systems behind a 
> gateway server to meet increased security requirements until they can be 
> phased out. For each legacy system the gateway would have an Apache 
> vhost front-end which would be exposed on the enterprise network. The 
> intent is to control access to individual front-ends using FreeIPA HBAC 
> rules as if they were real hosts. When a user attempts to login to the 
> front end the front end would use a currently non-existent sss client 
> library to perform authentication and check if the user has access to 
> the service on the vhost. In order to do this, the sss client library 
> must be able to pass the hostname of the vhost to SSSD. SSSD must then 
> use the passed hostname instead of the machine's actual hostname when 
> performing access checks. Currently SSSD's struct pam_data doesn't 
> include a field for destination host so even if a custom client library 
> and responder where created that were capable of passing on the hostname 
> the responder would have no way of passing the hostname to the data 
> provider (ipa).
> 
> The front-end application running under the Apache vhost forwards client 
> requests to the legacy host over an isolated vlan or other link and then 
> forwards responses from the legacy host back to the client.
> 
> Does anyone oppose the idea of changing struct pam_data to include a 
> field for the destination host and modifying the ipa provider (and other 
> if appropriate) to fill such requests?
> 
> A similar approach could be used to provide remote terminal access to 
> legacy hosts.
> 
> Has anyone else seen a need to do something like this?
> 
> Alternative Solutions (may not be feasible in some or all situations):
> Use a hypervisor to run separate OS instances for each legacy system 
> front-end.
> 
> A custom solution could be created to retrieve and cache the necessary 
> information from FreeIPA and perform the checks instead of using SSSD 
> but this is undesirable for many reasons.

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 ?

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 ?

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 ?

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 ?

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.

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.

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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list