[Freeipa-devel] More types of replica in FreeIPA

[Simo Sorce]

On Thu, 2012-04-19 at 15:00 -0400, Dmitri Pal wrote:
> Local server is the central hub for the authentications in the remote
> office. The client machines with SSSD or LDAP clients might not have
> access to the central datacenter directly. Another reason for having
> such login server is to reduce the traffic between the remote office
> and
> central data center by pointing to the clients to the login server for
> the identity lookups and cached authentication via LDAP with pam proxy
> and SSSD under it.
> 
> The SSSD will be on the server.
> 
> > Also we need to keep in mind that we cannot assume SSSD to be always
> > available on clients.
> 
> We can assume that SSSD can be used on this login server via pam
> proxy.

Sorry I do not get how SSSD is going to make any difference on the
server.

> I agree with the questions and challenges. This is something for
> Ondrej
> to research as an owner of the thesis but I would think that it should
> be up to the admin to define what to synch. We have a finite list of
> the
> things that we can pre-create filter for.
> 
> Think about some kind of the container that would define what to
> replicate.
> The object would contain following attributes:
> 
> uuid - unique rule id
> name - descriptive name
> description - comment
> filter - ldap filter
> base DN - base DN
> scope - scope of the search
> attrs - list of attributes to sync
> enabled - whether the rule is enabled
> 
> we can define (but disable by default) rules for SUDO, HBAC, SELinux,
> Hosts etc and tel admin to enable an tweak.
> 
This would be really complicated to manage. At the very least we need to
define what's the expected user experience and data set access, then we
can start devising technical solutions.

What we really want to protect here, at the core, is user keys, for user
and services not located in the branch office. All the info that is
accessible from the branch office and is not super sensitive can always
be replicated. The cost of choosing what to replicate and what not
should be deferred to a later "enhancement". I would try to get the
mechanism right for the authentication subset first, and deal with more
fine-grained 'exclusions' later, once we solved that problem and gained
experience with at least one aspect of data segregation.

Simo.

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