Date: Tue, 29 Mar 2016 11:20:24 +0200
From: Jan Pazdziora <jpazdziora@redhat.com>
To: =?iso-8859-2?B?THVr4bk=?= Hellebrandt <lhellebr@redhat.com>
Message-ID: <20160329092024.GT16196@redhat.com>
Mail-Followup-To: =?iso-8859-2?B?THVr4bk=?= Hellebrandt <lhellebr@redhat.com>, 
	freeipa-devel <freeipa-devel@redhat.com>
References: <56F2B93D.5090202@redhat.com> <20160324092447.GR16196@redhat.com>
	<56FA41C0.9040705@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <56FA41C0.9040705@redhat.com>
Organization: Red Hat Czech s.r.o., =?iso-8859-2?Q?Purky?=
	=?iso-8859-2?Q?=F2ova_99=2F71=2C_612_45_Brno=2C_Czech_Republic=3B_registe?=
	=?iso-8859-2?Q?red?= in Brno under identification number CZ27690016
User-Agent: Mutt/1.5.24 (2015-08-30)
Cc: freeipa-devel <freeipa-devel@redhat.com>
Subject: Re: [Freeipa-devel] URI in HBAC - design page
Precedence: junk
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Sender: freeipa-devel-bounces@redhat.com
Errors-To: freeipa-devel-bounces@redhat.com

On Tue, Mar 29, 2016 at 10:50:08AM +0200, Luk=E1=B9 Hellebrandt wrote:
> > =

> > The benefit of this approach is that if you need to evaluate access
> > to say
> > =

> > 	/application/data/
> > =

> > and you already have rule for
> > =

> > 	/application/			[ users/ ]
> > =

> > cached either in SSSD or in the application (Apache module), you know
> > you don't have to refetch additional rules because if they existed,
> > their existence would be noted in the sub-URL "exclusion" list.
> > =

> > You will achieve similar functionality to what you propose with the
> > regular expression approach, except the computers will do the work
> > of keeping things in sync, not users.
> =

> This solution would, effectively, mean DENY rules. Without them, adding

Well, yes, but addressing the inherent problem of DENY rules, which is
"if you miss the record for the DENY rule", you will go with the ALLOW
rule. Because every ALLOW rule would have the automatically-maintained
list of "excludes" or "scope limits", if you see the ALLOW rule, you
will know that it does not apply to what it shouldn't apply to.

> "/application/users/admin/" wouldn't change anything as the first rule
> would allow "/application/users/.*" and the added rule would explicitly
> allow "/application/users/admin/.*", changing nothing.

My proposal is for IPA to do automatically the housekeeping,
maintaining the information about

	/application/users/admin/

existence in the "parent" rule (/application/users/).

> Furthermore, in some cases you might, for example, allow access to any
> user except users starting with "admin_", which is a problem if there is

How do you proposed to do that? You'd have to have a user group.

> unknown or infinite or large number of those users. Regular expressions
> seem to be more powerful.

More powerful: certainly. But your proposal also makes them much more
complex and dangerous to use, if you want to be able to address
typical Web applications and their layout.

-- =

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

-- =

Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code