Re: [Freeipa-devel] URI in HBAC - design page
(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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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