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            HBAC rule name 1        HBAC rule name 1        HBAC rule name 2        HBAC rule name 2    HBAC rule name 3    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)://        HBAC rule name 1
    http(s)://        HBAC rule name 2
        User group: core-employees
    http(s)://    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 http[s]?://[/]? ...

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:

Reply via email to