[Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Simo Sorce]

On Fri, 2016-09-09 at 13:14 +0200, Standa Laznicka wrote:
> On 09/03/2016 06:25 PM, Jan Pazdziora wrote:
> > On Thu, Sep 01, 2016 at 11:18:45AM -0400, Simo Sorce wrote:
> >> The thing is we (and admins) will be stuck with old client s for a loong
> >> time, so we need to make it clear to them what works for what. We need
> >> to allow admins to create rules that work for both new and old client
> >> w/o interfering with each other.
> >> In your scheme there must be a way to create a set of rule such that old
> >> clients can login at any time while newer clients use time rules.
> >> that was easy to accomplish by adding an auxiliary class and simply
> >> defining a new type.
> >> Old clients would see old stuff only, new clients would add time rules
> >> if present.
> >> If we have 2 completely different objects because the admin has to
> >> create both, then old clients still care only for the old rule, new
> >> clients instead have an interesting challenge, what rule do they apply ?
> > You use host groups to serve the old rule to old clients and time-based
> > rule to new clients. Each client will apply the rule they see.
> >
> > If you happen to serve the old rule to the new client, access will
> > be allowed no matter what the other, time-based rule says.
> >
> > You do not use magic to interpret one rule differently, one way on
> > one version of client and other way on different client version.
> >
> >> How do you make sure a new client will enforce time restriction when it
> >> looks up the old rule as well ?
> > You make sure the new client does not see the old rule.
> >
> >> Of course admins can always create very barrow host groups and apply
> >> rules only to them, but this is burdensome if you have a *lot* of
> >> clients and some other people are tasked to slowly upgrade them. It is
> >> possible though, so having 2 separate objects that new clients know
> >> about is potentially ok. I would prefer a scheme where they could be
> >> combined though for maximum flexibility with as little as possible
> >> ambiguity.
> > I agree that managing separate host group membership might be
> > and extra work. But it seems to be the only way to remove the ambiguity.
> >
> I also believe there's no way avoiding that (if we want to be somehow 
> backward compatible).
> 
> I would just love us to come to a consensus as I am growing weary of 
> this discussion and am willing to go with just anything as long as it's 
> somehow OK with most people. Could we therefore decide to go with 
> something, please?

As long as the tooling does not try to replace object classes I am ok
with the solution most people agree on.

Simo.


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