Re: [Freeipa-devel] URI in HBAC - design page

2016-03-30 Thread Jakub Hrozek
(Sorry to come late into this thread..)

On Thu, Mar 24, 2016 at 02:49:39PM +0100, Jan Pazdziora wrote:
> On Thu, Mar 24, 2016 at 02:30:06PM +0100, Petr Spacek wrote:
> > 
> > I really do not like 'excludes'... Was an approach with longest prefix match
> > considered as an option? I do not see it in the design page.
> > 
> > E.g. imagine we have rules:
> > / -> allow anyone
> > /users -> allow all authenticated users
> > /users/edit -> allow admins
> > 
> > If the matching engine always selects rule with matchine prefix and evaluate
> > only that rule, it would nicely express who is allowed to access what and 
> > did
> > not require deny rules (or even rule merging).

This is more or less what was proposed in another discussion:

https://lists.fedorahosted.org/archives/list/sssd-de...@lists.fedorahosted.org/thread/GRWONQ3FGGJDVHHD2D2GOO6PJEJQM3Z6/
So I tend to agree with Petr.

> 
> The "Prefix" Evaluation item talks about it.
> 
> The perceived issue is, if for some reason you miss the longest
 ~~
What would be the reasons? During an IRC conversation Jan mentioned
operational reasons (like size limit exceeded, timeout during the search
etc..) which is something that Jan's automatic-excludes would solve.

I don't agree with what the design page says about the inability to make
stricter matches work:
"""
The problem is, in web applications, the longer URI usually means
stricter access rules: it would be hard to make rules such that
"/users" is accessible by all users and "/users/admin" is only
accessible by admin (we can't exclude a subset of some matching
set).
"""

I think the longest-match-wins would solve this, what am I missing?

> record when evaluating, you will use the previous shorter one and
> allow more access than intended. So from certain POV it's similar to
> DENY rules -- if you miss the DENY rule for some reason, you will go
> with the allow rule.
> 
> If the excludes are kept up-to-date automatically for each URI
> record, matching the next longer prefix, whatever record you find will
> include in some attribute information about limits of its validity.
> That might address the concern of security implication of exclude /
> deny / longest record not found.
> 
> I don't like manual excludes either.

My preference would be either the longest match or alternatively the
automatic exludes. My only complaint about the automatic excludes is
that it adds additional complexity, so the question is whether the
additional complexity is worth spending time on. If we could make the
excludes work in a reliable and simple way, then sure.

But to be honest, I don't like regular expressions either, they are too
fragile and a nightmare to set up and maintain IMO.

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Jan Pazdziora
On Tue, Mar 29, 2016 at 11:21:05AM +0200, Lukáš Hellebrandt wrote:
> 
> Right, we only have to deal with path as the protocol is already in HBAC
> rules.

I don't see protocol in HBAC rules -- there are HBAC (~ PAM) service
name and canonical hostname of the machine. But there isn't protocol
(scheme) there, there isn't service host name there, and there isn't
port there.

Can you please show (here or in the design page) how you envision
the situation

https://www.redhat.com/archives/freeipa-devel/2016-March/msg00462.html

would be modeled?

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Jan Pazdziora
On Tue, Mar 29, 2016 at 10:59:13AM +0200, Lukáš Hellebrandt wrote:
> 
> No change compared to how it works now: if the public part doesn't
> require any authorization at all, the application won't even ask for
> authorization.

In other words, it won't be possible to enable unauthenticated access
centrally (in IPA)?

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Lukáš Hellebrandt
On 03/24/2016 02:39 PM, Rob Crittenden wrote:
> 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.
> 

Right, we only have to deal with path as the protocol is already in HBAC
rules.


-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Jan Pazdziora
On Tue, Mar 29, 2016 at 10:50:08AM +0200, Lukáš 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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Lukáš Hellebrandt
On 03/24/2016 01:41 PM, 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
> 
> Could you please elaborate on unauthenticated accesses?
> 
> Many web applications have completely public parts, and then
> authenticated sections, with more restricted access to subsections
> underneath. How do you envision configuration to look like, and how
> will the (missing) user identity be handled in that case?
> 

No change compared to how it works now: if the public part doesn't
require any authorization at all, the application won't even ask for
authorization.

-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Lukáš Hellebrandt
On 03/24/2016 01:31 PM, Jan Pazdziora wrote:
> On Wed, Mar 23, 2016 at 06:39:45PM +0100, Petr Vobornik wrote:
>> On 03/23/2016 04:41 PM, Lukáš Hellebrandt wrote:
>>> I created a design page for the feature:
>>>
>>> http://www.freeipa.org/page/URI-based-HBAC-design
>>
>> 1. The design page doesn't mention if mod_authnz_pam will be extended or
>> some new 'pam_sss' Apache module will be created. Or is it actually
>> mod_hbacauthz_pam as said in 'how to test'?
> 
> If PAM is used and pam_sss is extended to accept the URL in PAM
> environment for pam_acct_mgmt, I'd expect patch would be proposed
> against mod_authnz_pam.
> 
> If that turns out not to be a viable option, using SSSD's D-Bus
> interface might the way to go, in which case it would likely be new
> module, something like mod_authz_sssd.
> 

I have created my own Apache module serving just for this purpose
(mod_hbacauthz_pam), but extending mod_authnz_pam is a matter of minutes
and I will likely do that, too.

-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Lukáš Hellebrandt
On 03/24/2016 10:31 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
> 
> In the document, you say
> 
>   In all of them [ approaches ], I use only the part of URI
>   after hostname as hostname and service are already matched
>   as part of selecting HBAC rules to evaluate in terms of
>   matching URI. 
> 
> This is not correct.
> 
> The hostname of the machine may be
> 
>   cloud-123-567.example.com
> 
> The service (principal) might be HTTP/cloud-123-567.example.com.
> 
> The HBAC service (== PAM service) might be 'application', or 'httpd'.
> 
> But the URL might be
> 
>   http://wiki.example.com/wiki
> 
> or
> 
>   https://issues.example.com/
> 
> or
> 
>   http://www.example.com:8080/
> 
> Distinct applications and content, with completely distinct URLs,
> locations, and security requirements, hosted on the same machine and
> under the same HBAC service.
> 
> The full URL needs to be taken into account. There can be situations
> like
> 
>   http:///wiki
> 
> where the hostname is ommitted in the rule but it has to be an
> explicit decision of the user (admin) editing the rules, not something
> built into the mechanism.
> 

Actually, admin can specify whatever he wants in URI attribute. The only
question here is what the application should send. So this is merely a
matter of the Apache module in my case.

-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Lukáš Hellebrandt
On 03/24/2016 10:24 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
> 
> The way most web applications (that I see as the first use for this
> feature) are structured, they have more openly accessible areas at
> "top" URLs like
> 
>   /application/
> 
> which might have unrestricted access, with authenticated or otherwise
> narrowed access underneath, like
> 
>   /application/users/
> 
> with yet more restricted areas in sub-URLs, for example
> 
>   /application/users/admin/
> 
> Since obviously allow rule for /application/users/ would match access
> to /application/users/admin/ as well and we don't want that, there
> needs to be a way to "override" the /application/users/ rule with
> a more specific one.
> 
> You present two solutions to the problem -- deny rules, and regular
> expressions.
> 
> Having to use
> 
>   ^/application/users/(?!admin/).*
> 
> rule to make sure it does not match /application/users/admin/ means
> that when you add
> 
>   /application/users/helpdesk/
> 
> you will not only have to edit that rule, but also amend the
> 
>   ^/application/users/(?!admin/).*
> 
> rule and add helpdesk there. That will be extremely volatile and
> error-prone if you have dozens of sub-locations that require
> separate, more restrictive access. Users cannot be expected to keep
> these separate rules in sync.
> 
> My preferred solution would be to treat the URL as left prefix, and
> maintain for each URL/rule list of/links to sub-URLs/sub-rules for
> which the URL/rule no longer applies.
> 
> So when you have rule for
> 
>   /application/users/
> 
> and add rule for
> 
>   /application/users/admin/
> 
> the first one gets automatically amended to be
> 
>   /application/users/ [ admin/ ]
> 
> And when you add
> 
>   /application/
> 
> it will automatically get
> 
>   /application/   [ users/ ]
> 
> because there is already a rule that limits the scope.
> 
> 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
"/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.

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
unknown or infinite or large number of those users. Regular expressions
seem to be more powerful.

-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Fraser Tweedale
On Thu, Mar 24, 2016 at 01:09:24PM +0100, Jan Pazdziora wrote:
> On Thu, Mar 24, 2016 at 11:39:17AM +1000, Fraser Tweedale wrote:
> >
> > Further to Rob's points, what about including the method being used
> > (HTTP GET/POST/PUT/PATCH)?  In a RESTful world this seems like an
> > important aspect to include.
> > 
> > How deep does this rabbit-hole go? :)
> 
> The work, while focused primarily on web use-cases, should be usable
> outside of HTTP protocol. The rabbit hole might include questions
> about mapping FTP commands into some sensible list of methods that
> could be easily managed. In his work Lukáš seemed concerned by DENY
> rules not being supported (were removed from IPA), hence his regexp
> proposal with negative lookaheads to avoid
> 
>   /   all users
>   /admin  admins
> 
> where of course both URLs would match for access to /admin/edit but
> the longer one should win, thus serving as DENY.
> 
> For FTP that has the potential of having to list long list of
> commands:
> 
>   long-list-of-all-cmds-except-write-cmds /   all users
>   long-list-of-write-commands /   admins
> 
> If we could specify
> 
>   *   /   all users
>   long-list-of-write-commands /   admins
> 
> and the situation was not considered as introduction of DENY
> mechanism, it might be more feasible. We might still want to have
> "metacommands" like 'FTP:read', 'FTP:write' to group the underlying
> commands for easy maintenance and presentation.
> 
> My preference would be not to do the methods at this time but have
> the data structured in such a way that it's easy to extend later.
> 
This story:

  ``
  As an administrator, I want to allow any user to "GET /posts" and
  "GET /posts/\w+" but only users who are members of group "authors"
  to "POST /posts" or "(PUT|DELETE) /posts/\w+"
  ''

will be the very first story if we release without method support.
IMO it is too obvious and important a thing to omit from the initial
implementation.

Cheers,
Fraser

-- 
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

Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Jan Pazdziora
On Thu, Mar 24, 2016 at 02:30:06PM +0100, Petr Spacek wrote:
> 
> I really do not like 'excludes'... Was an approach with longest prefix match
> considered as an option? I do not see it in the design page.
> 
> E.g. imagine we have rules:
> / -> allow anyone
> /users -> allow all authenticated users
> /users/edit -> allow admins
> 
> If the matching engine always selects rule with matchine prefix and evaluate
> only that rule, it would nicely express who is allowed to access what and did
> not require deny rules (or even rule merging).

The "Prefix" Evaluation item talks about it.

The perceived issue is, if for some reason you miss the longest
record when evaluating, you will use the previous shorter one and
allow more access than intended. So from certain POV it's similar to
DENY rules -- if you miss the DENY rule for some reason, you will go
with the allow rule.

If the excludes are kept up-to-date automatically for each URI
record, matching the next longer prefix, whatever record you find will
include in some attribute information about limits of its validity.
That might address the concern of security implication of exclude /
deny / longest record not found.

I don't like manual excludes either.

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Rob Crittenden

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

--
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Jan Pazdziora
On Thu, Mar 24, 2016 at 02:08:22PM +0100, Martin Kosek wrote:
> 
> I agree it is complicated. While Deny HBAC rules is something we do not want,
> allowing exclusive rules for an HBAC URI rule may be acceptable. This would be
> the same approach we chose with Exclusive Time rules in Time-Based HBAC:
> 
> http://www.freeipa.org/page/V4/Time-Based_Account_Policies#Time_Policies_Storage

Right. The accessTimeExclude effectively seems to be DENY, in a sense
that you need to evaluate it to "override" other accessTime records
that might have allowed the access. And if you miss the record with
accessTimeExclude, you've allowed access that shouldn't have been
allowed.

> For the URI identifiers, we should also try to reinvent the wheel here. Can
> adopt an approach used in some of the most common frameworks for URL matching?
> Take Django for example:
> 
> https://docs.djangoproject.com/en/1.9/topics/http/urls/

Not sure which part of the approach you have in mind. Django uses 
a list url()s, which gives explicit order in which they are evaluated 
/ matched. To emulate that in IPA, using some mechanism to give the
LDAP records stable ordering (unique integer attribute?) might work.
But that might be perceived as foreign concept in otherwise
"declarative" nature of HBAC rule (and LDAP in general).

> Using the pattern approach you mentioned elsewhere could work, I am just
> worried how much user friendly it would be for non-developers. But we can also
> make use these patterns as the raw storage format and build some nice UI/CLI 
> on
> top of it.

I actually prefer left prefix to regular expression patterns.

> Can we do the same as with current default "allow all" rule?

> I.a. allow "/" for

I'm not really fond of the allow_all rule because starting with the
default setup when it is enabled (and HBAC in effect not playing any
role) and wanting to start using HBAC just for one machine means
pretty big manual effort:

http://www.freeipa.org/page/Howto/HBAC_and_allow_all

> all sites by default and let admin to remove that for sites with access
> controlled and restricted by FreeIPA HBAC.

The question is, how do you know that a site is access controlled? If
a rule (with URL part) does not match the requested URL, it doesn't
mean there isn't such a rule and that access should be allowed.

Maybe the right approach is to make "sites" a first-class citizen, so
that you can be explicit about using the URL-based access controll for
a particular site or not.

> This would mean admin would
> typically need to define some general rule the site accessible by all with the
> exceptions defined in "exclude" access rules and then build the rules specific
> to these excluded parts of the application URL tree.

Right, and we also need to give admin a very easy way to define those
excludes implicitly, by having the additional (sub-URL) rules
automatically populate those excludes for the "parent" URLs.

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Petr Spacek
On 24.3.2016 14:08, Martin Kosek wrote:
> On 03/24/2016 01:24 PM, Jan Pazdziora wrote:
>> On Thu, Mar 24, 2016 at 12:38:37PM +0100, Martin Kosek wrote:
>>> On 03/24/2016 10:24 AM, Jan Pazdziora wrote:
 On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
>>> ...
 You present two solutions to the problem -- deny rules, and regular
 expressions.
>>>
>>> For the record, HBAC deny rules is something we will want to avoid. Deny 
>>> HBAC
>>
>> Certainly. And for the current HBAC's model of user (groups), host
>> (groups), service (groups), you can tell the admin to structure their
>> environment and groups in such a way that they are not needed.
> 
> Right.
> 
>> But the question is, if you want for the admin to be able to control
>> access to a website where longer URLs often need to be more restricted
>> than the shorter ones, what mechanism do you propose? It is not
>> possible to positively (for allow purposes) list only exhaustive list
>> of URL prefixes that should have the broader access allowed -- new
>> versions of the web application can introduce additional URLs into the
>> namespace, and the URLs are not identities like users or hosts that
>> FreeIPA would be aware of that that you could easily manage by putting
>> them to groups.
> 
> I agree it is complicated. While Deny HBAC rules is something we do not want,
> allowing exclusive rules for an HBAC URI rule may be acceptable. This would be
> the same approach we chose with Exclusive Time rules in Time-Based HBAC:
> 
> http://www.freeipa.org/page/V4/Time-Based_Account_Policies#Time_Policies_Storage
> 
> For the URI identifiers, we should also try to reinvent the wheel here. Can
> adopt an approach used in some of the most common frameworks for URL matching?
> Take Django for example:
> 
> https://docs.djangoproject.com/en/1.9/topics/http/urls/
> 
> Using the pattern approach you mentioned elsewhere could work, I am just
> worried how much user friendly it would be for non-developers. But we can also
> make use these patterns as the raw storage format and build some nice UI/CLI 
> on
> top of it.
> 
>> The natural way to think about access to web URLs is to say "I only
>> want admins to access /application/users/admin/". Which of course
>> means "I want to deny everyone who has otherwise access to other URLs,
>> except for admins".
> 
> Can we do the same as with current default "allow all" rule? I.a. allow "/" 
> for
> all sites by default and let admin to remove that for sites with access
> controlled and restricted by FreeIPA HBAC. This would mean admin would
> typically need to define some general rule the site accessible by all with the
> exceptions defined in "exclude" access rules and then build the rules specific
> to these excluded parts of the application URL tree.

I really do not like 'excludes'... Was an approach with longest prefix match
considered as an option? I do not see it in the design page.

E.g. imagine we have rules:
/ -> allow anyone
/users -> allow all authenticated users
/users/edit -> allow admins

If the matching engine always selects rule with matchine prefix and evaluate
only that rule, it would nicely express who is allowed to access what and did
not require deny rules (or even rule merging).

-- 
Petr^2 Spacek

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Petr Spacek
On 24.3.2016 11:39, Jan Pazdziora wrote:
> On Wed, Mar 23, 2016 at 11:54:55AM -0400, Rob Crittenden wrote:
>>
>> I think case sensitivity might be pretty important too, though might be best
>> left as an exercise for the user.
> 
> For protocol and hostname it likely needs to be case insensitive.
> for the rest of the URL there probably should be a checkbox for the
> user to explicitly enable case-insensitivity.

Schemes are indeed case-insensitive:
https://tools.ietf.org/html/rfc3986#section-3.1

Everything else depends on scheme so user-selectable option sounds like a good
idea.

-- 
Petr^2 Spacek

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Adam Young

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.

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



--
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Martin Kosek
On 03/24/2016 01:24 PM, Jan Pazdziora wrote:
> On Thu, Mar 24, 2016 at 12:38:37PM +0100, Martin Kosek wrote:
>> On 03/24/2016 10:24 AM, Jan Pazdziora wrote:
>>> On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
>> ...
>>> You present two solutions to the problem -- deny rules, and regular
>>> expressions.
>>
>> For the record, HBAC deny rules is something we will want to avoid. Deny HBAC
> 
> Certainly. And for the current HBAC's model of user (groups), host
> (groups), service (groups), you can tell the admin to structure their
> environment and groups in such a way that they are not needed.

Right.

> But the question is, if you want for the admin to be able to control
> access to a website where longer URLs often need to be more restricted
> than the shorter ones, what mechanism do you propose? It is not
> possible to positively (for allow purposes) list only exhaustive list
> of URL prefixes that should have the broader access allowed -- new
> versions of the web application can introduce additional URLs into the
> namespace, and the URLs are not identities like users or hosts that
> FreeIPA would be aware of that that you could easily manage by putting
> them to groups.

I agree it is complicated. While Deny HBAC rules is something we do not want,
allowing exclusive rules for an HBAC URI rule may be acceptable. This would be
the same approach we chose with Exclusive Time rules in Time-Based HBAC:

http://www.freeipa.org/page/V4/Time-Based_Account_Policies#Time_Policies_Storage

For the URI identifiers, we should also try to reinvent the wheel here. Can
adopt an approach used in some of the most common frameworks for URL matching?
Take Django for example:

https://docs.djangoproject.com/en/1.9/topics/http/urls/

Using the pattern approach you mentioned elsewhere could work, I am just
worried how much user friendly it would be for non-developers. But we can also
make use these patterns as the raw storage format and build some nice UI/CLI on
top of it.

> The natural way to think about access to web URLs is to say "I only
> want admins to access /application/users/admin/". Which of course
> means "I want to deny everyone who has otherwise access to other URLs,
> except for admins".

Can we do the same as with current default "allow all" rule? I.a. allow "/" for
all sites by default and let admin to remove that for sites with access
controlled and restricted by FreeIPA HBAC. This would mean admin would
typically need to define some general rule the site accessible by all with the
exceptions defined in "exclude" access rules and then build the rules specific
to these excluded parts of the application URL tree.

Martin

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Jan Pazdziora
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

Could you please elaborate on unauthenticated accesses?

Many web applications have completely public parts, and then
authenticated sections, with more restricted access to subsections
underneath. How do you envision configuration to look like, and how
will the (missing) user identity be handled in that case?

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Jan Pazdziora
On Wed, Mar 23, 2016 at 06:39:45PM +0100, Petr Vobornik wrote:
> On 03/23/2016 04:41 PM, Lukáš Hellebrandt wrote:
> >I created a design page for the feature:
> >
> >http://www.freeipa.org/page/URI-based-HBAC-design
> 
> 1. The design page doesn't mention if mod_authnz_pam will be extended or
> some new 'pam_sss' Apache module will be created. Or is it actually
> mod_hbacauthz_pam as said in 'how to test'?

If PAM is used and pam_sss is extended to accept the URL in PAM
environment for pam_acct_mgmt, I'd expect patch would be proposed
against mod_authnz_pam.

If that turns out not to be a viable option, using SSSD's D-Bus
interface might the way to go, in which case it would likely be new
module, something like mod_authz_sssd.

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Jan Pazdziora
On Thu, Mar 24, 2016 at 12:38:37PM +0100, Martin Kosek wrote:
> On 03/24/2016 10:24 AM, Jan Pazdziora wrote:
> > On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
> ...
> > You present two solutions to the problem -- deny rules, and regular
> > expressions.
> 
> For the record, HBAC deny rules is something we will want to avoid. Deny HBAC

Certainly. And for the current HBAC's model of user (groups), host
(groups), service (groups), you can tell the admin to structure their
environment and groups in such a way that they are not needed.

But the question is, if you want for the admin to be able to control
access to a website where longer URLs often need to be more restricted
than the shorter ones, what mechanism do you propose? It is not
possible to positively (for allow purposes) list only exhaustive list
of URL prefixes that should have the broader access allowed -- new
versions of the web application can introduce additional URLs into the
namespace, and the URLs are not identities like users or hosts that
FreeIPA would be aware of that that you could easily manage by putting
them to groups.

The natural way to think about access to web URLs is to say "I only
want admins to access /application/users/admin/". Which of course
means "I want to deny everyone who has otherwise access to other URLs,
except for admins".

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Jan Pazdziora
On Thu, Mar 24, 2016 at 11:39:17AM +1000, Fraser Tweedale wrote:
>
> Further to Rob's points, what about including the method being used
> (HTTP GET/POST/PUT/PATCH)?  In a RESTful world this seems like an
> important aspect to include.
> 
> How deep does this rabbit-hole go? :)

The work, while focused primarily on web use-cases, should be usable
outside of HTTP protocol. The rabbit hole might include questions
about mapping FTP commands into some sensible list of methods that
could be easily managed. In his work Lukáš seemed concerned by DENY
rules not being supported (were removed from IPA), hence his regexp
proposal with negative lookaheads to avoid

/   all users
/admin  admins

where of course both URLs would match for access to /admin/edit but
the longer one should win, thus serving as DENY.

For FTP that has the potential of having to list long list of
commands:

long-list-of-all-cmds-except-write-cmds /   all users
long-list-of-write-commands /   admins

If we could specify

*   /   all users
long-list-of-write-commands /   admins

and the situation was not considered as introduction of DENY
mechanism, it might be more feasible. We might still want to have
"metacommands" like 'FTP:read', 'FTP:write' to group the underlying
commands for easy maintenance and presentation.

My preference would be not to do the methods at this time but have
the data structured in such a way that it's easy to extend later.

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Martin Kosek
On 03/24/2016 10:24 AM, Jan Pazdziora wrote:
> On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
...
> You present two solutions to the problem -- deny rules, and regular
> expressions.

For the record, HBAC deny rules is something we will want to avoid. Deny HBAC
rules were removed in the past for good reasons:

https://www.redhat.com/archives/freeipa-users/2011-June/msg00256.html
https://fedorahosted.org/freeipa/ticket/1432

Martin

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Jan Pazdziora
On Wed, Mar 23, 2016 at 11:54:55AM -0400, Rob Crittenden wrote:
> 
> I think case sensitivity might be pretty important too, though might be best
> left as an exercise for the user.

For protocol and hostname it likely needs to be case insensitive.
for the rest of the URL there probably should be a checkbox for the
user to explicitly enable case-insensitivity.

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Jan Pazdziora
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/

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

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Jan Pazdziora
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

In the document, you say

In all of them [ approaches ], I use only the part of URI
after hostname as hostname and service are already matched
as part of selecting HBAC rules to evaluate in terms of
matching URI. 

This is not correct.

The hostname of the machine may be

cloud-123-567.example.com

The service (principal) might be HTTP/cloud-123-567.example.com.

The HBAC service (== PAM service) might be 'application', or 'httpd'.

But the URL might be

http://wiki.example.com/wiki

or

https://issues.example.com/

or

http://www.example.com:8080/

Distinct applications and content, with completely distinct URLs,
locations, and security requirements, hosted on the same machine and
under the same HBAC service.

The full URL needs to be taken into account. There can be situations
like

http:///wiki

where the hostname is ommitted in the rule but it has to be an
explicit decision of the user (admin) editing the rules, not something
built into the mechanism.

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Jan Pazdziora
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

The way most web applications (that I see as the first use for this
feature) are structured, they have more openly accessible areas at
"top" URLs like

/application/

which might have unrestricted access, with authenticated or otherwise
narrowed access underneath, like

/application/users/

with yet more restricted areas in sub-URLs, for example

/application/users/admin/

Since obviously allow rule for /application/users/ would match access
to /application/users/admin/ as well and we don't want that, there
needs to be a way to "override" the /application/users/ rule with
a more specific one.

You present two solutions to the problem -- deny rules, and regular
expressions.

Having to use

^/application/users/(?!admin/).*

rule to make sure it does not match /application/users/admin/ means
that when you add

/application/users/helpdesk/

you will not only have to edit that rule, but also amend the

^/application/users/(?!admin/).*

rule and add helpdesk there. That will be extremely volatile and
error-prone if you have dozens of sub-locations that require
separate, more restrictive access. Users cannot be expected to keep
these separate rules in sync.

My preferred solution would be to treat the URL as left prefix, and
maintain for each URL/rule list of/links to sub-URLs/sub-rules for
which the URL/rule no longer applies.

So when you have rule for

/application/users/

and add rule for

/application/users/admin/

the first one gets automatically amended to be

/application/users/ [ admin/ ]

And when you add

/application/

it will automatically get

/application/   [ users/ ]

because there is already a rule that limits the scope.

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.

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-24 Thread Martin Kosek
On 03/23/2016 04:41 PM, Lukáš Hellebrandt wrote:
> I created a design page for the feature:
> 
> http://www.freeipa.org/page/URI-based-HBAC-design

Technicality update:

- I changed the name and moved it to consistent location:
http://www.freeipa.org/page/V4/URI-based_HBAC

- I removed "version=0.1" from the "Feature box", so that design appears in the
right category:
http://www.freeipa.org/index.php?title=Category:FreeIPA_Design_Proposal
FIY - the version denotes the target version of the FreeIPA (when accepted) and
not version of the design.

-- 
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-23 Thread Petr Vobornik

On 03/23/2016 04:41 PM, Lukáš Hellebrandt wrote:

I created a design page for the feature:

http://www.freeipa.org/page/URI-based-HBAC-design




1. The design page doesn't mention if mod_authnz_pam will be extended or 
some new 'pam_sss' Apache module will be created. Or is it actually 
mod_hbacauthz_pam as said in 'how to test'?


2. "in some location in Apache" is vague

3. If it is a conceptual design than OK but in final following needs to 
be specified:

- which LDAP object class is extended with what attribute
- which IPA object is extended with what param
- what API methods are affected
- how will CLI options look

4. what regular expression dialect will be used?

--
Petr Vobornik

--
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


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-23 Thread Rob Crittenden

LukᚠHellebrandt wrote:

I created a design page for the feature:

http://www.freeipa.org/page/URI-based-HBAC-design




Can you make the ticket reference a link?

Is it expected that a full URI will be used, including protocol? Your 
early examples are http://path/to/somewhere and later you just use 
/path/to/somewhere. Will protocol be allowed? I ask because it can be 
problematic because users would have to consider and remember http vs 
https, for example.


What happens if ftp, for example, added HBAC support and wanted to 
utilize this but wanted different access control by protocol?


I think case sensitivity might be pretty important too, though might be 
best left as an exercise for the user.


I'm not sure what you mean by the CLI section. It seems like you are 
just adding in a uri option so I'd be explicit. Showing possible usage 
would be handy too.


What kind of regex validation can be done, if any?

rob

--
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


[Freeipa-devel] URI in HBAC - design page

2016-03-23 Thread Lukáš Hellebrandt
I created a design page for the feature:

http://www.freeipa.org/page/URI-based-HBAC-design


-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
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