[Freeipa-devel] URI in HBAC - design page

Rob Crittenden rcritten at redhat.com
Thu Mar 24 13:39:11 UTC 2016


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:
>>>
>>> http://www.freeipa.org/page/URI-based-HBAC-design
>> 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
>>
>>     http://www.example.com/
>>     https://www.example.com/
>
> 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
> applicable.
>
>
>  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
> resources"
> 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
>> for
>>
>>     www.example.com
>>
>> 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 
http[s]?://www.example.com[/]? ...

But when a pattern emerges then perhaps the design should just take care 
of that for the user.

rob




More information about the Freeipa-devel mailing list