Adam Young wrote:
On 03/24/2016 05:43 AM, Jan Pazdziora wrote:
On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
I created a design page for the feature:
I try to put separate areas of concerns into separate emails to make
it easy to keep track.
The document says
There is a new field in HBAC rule details for adding URI PCRE
as plain text.
We need an easy way for the user to enter multiple URLs for the same
rule. The primary case is obviously the http / https duality
Yes, let's split up the Hostname and the URI matching into two entities.
I wasn't entirely clear when I brought this up. The design is a little
fuzzy whether the previous HBAC elements are all required but
potentially we _already_ have the hostname that this applies to. I think
dealing with just the path would be much more straightforward. Of course
that doesn't take into account virtual hosts/SNI, so maybe host is
relevant after all.
The URI matching might well be very reusable: most applications like
Wordpress, OpenStack Horizon (and all the the web services in
OpenStack), and the like have fairly regular rules that should be
From an administrators perspective, they want to say hostname has
application at suburl X
From there on, they want to say "user has acces to these kinds of
This is the Administrative pattern that seems to be working for Keystone.
but there might be other situations when additional service is being
deployed and it is supposed to use exactly the same rule as five
existing ones. In that case the user has to be able to just add
additional URL to existing HBAC rule, not be forced to create separate
new rule which will likely go out of sync from the previous ones when
they are edited.
In addition, there should be an easy way to see all HBAC rules for a
particular URL (and all sub-URLs) -- it should be possible to search
and see all the
http://www.example.com/ HBAC rule name 1
https://www.example.com/ HBAC rule name 1
http://www.example.com/auth/ HBAC rule name 2
https://www.example.com/auth/ HBAC rule name 2
http://www.example.com/auth/admin/ HBAC rule name 3
https://www.example.com/auth/admin/ HBAC rule name 3
ideally is some consise way if multiple URLs lead to the same rule
and changes between rules that differ:
http(s)://www.example.com/ HBAC rule name 1
http(s)://www.example.com/auth/ HBAC rule name 2
User group: core-employees
http(s)://www.example.com/auth/admin/ HBAC rule name 3
User group: network-admins
You better illustrated my point about protocol. This could easily
explode, though I guess it could be mitigated via regex
But when a pattern emerges then perhaps the design should just take care
of that for the user.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code