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

[Jan Pazdziora]

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.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat