[Freeipa-devel] Draft: Read permissions for user

[Simo Sorce]

On Tue, 2014-04-29 at 14:21 +0200, Martin Kosek wrote:
> On 04/29/2014 01:03 PM, Petr Viktorin wrote:
> > On 04/24/2014 11:35 AM, Martin Kosek wrote:
> >> On 04/23/2014 10:53 PM, Martin Kosek wrote:
> >>> On 04/23/2014 08:07 PM, Simo Sorce wrote:
> > [...]
> >>>>
> >>>> I know, we may need to provide another permission admins can use to turn
> >>>> on anonymous searches for those attributes too.
> >>>> We may also decide that on upgrade vs new install we retain anonymous
> >>>> access.
> >>>>
> >>>> Simo.
> > 
> > This is an interesting challenge.
> > We want the permission to be set to anonymous when:
> > 1) we're creating it, and
> > 2) the updater is *not* run from ipa-server-install (which would mean we're
> > installing a new cluster).
> > Full analysis below, [0]
> > 
> > We discussed this on a meeting and it was mentioned that we can just start with
> > anonymous, and simply change to "all authenticated" at the end of
> > ipa-server-install. Thinking about it, I don't like that approach.
> > We may want an ACI audit tool [1] to list differences from defaults.
> > For uses like this, the metadata should list to up-to-date "best practices",
> > i.e. what you'd get with a fresh ipa-server-install.
> > So the metadata should list the bind type as all authenticated, and setting it
> > to anonymous should be handled as a special operation.
> > 
> > This will be somewhat harder to code but I think it's worth it.
> 
> I agree with Petr - managed permission definition should state our recommended
> and default access control that we are convinced that will fit most
> deployments. Restrictive or benevolent admins can always change the default
> with simple
> 
> $ ipa permission-mod --bindtype=(all|anonymous|permission)
> 
> call.
> 
> Maybe the easiest way after all will be to list the changes in access control
> in the release note, compared to FreeIPA 3.x, e.g.
> 
> 1) Host groups read access change from anonymous to authenticated by default
> 2) User calendar attributes read access change from anonymous to authenticated
> by default
> ...
> 
> and educate users how they can change it if it does not fit their needs. IMO it
> may be more transparent and deterministic than to come with some hard coded
> changes in ipa-server-install that will create different defaults after upgrade
> and new installation.

It will break working servers pretty badly, that's a big NO on my side.

You do not want people to scramble understanding a new ACI system at
gunpoint because their production environment is broken.

It is a little harder for us, true, but it is worth it.

Simo.

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