[Freeipa-devel] in-tree webUI
Hello, I am learning FreeIPA development and looking for a way to test my changes in code: so far, I have to compile, build RPMs, copy them to the machine desired, uninstall old version, install new version from RPMs - that, for every change I want to test. Which takes way too long. I know about possibility to run FreeIPA "in-tree". Does webUI work in this mode? So far, I wasn't able to connect, neither by using the public hostname or localhost (port as it says after installation). Am I doing something wrong (how to discover what?) or does FreeIPA just run without webUI in in-tree mode? Is there any better way to test my changes? -- 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 rules - patch - request for feedback
> On the patches: > > [2] you define a new attribute Url which is fine, but the actual > attribute is not ok in several way. > > - You assigned an OID from a hole in the IPAv2 Attibutes space, it > should be an assigned ID from the IPAv3 attribute space instead > > - You do not namespace the attribute, it should at least be ipaUrl > I'll look into that > - you are using case Exact matching, is this intentional? Are the URIs > in there case sensitive strings ? > > - there is an available attribute called labeledURI (with alias > labeledurl) in the standard schema (however I notice it also has > caseExactMatch) that has basically the same definition of your Url > attribute, why not use that one ? > Actually, URI is case sensitive: http://stackoverflow.com/a/26196170/1978950 I'll check labeledURI you mentioned. > [3] If I read the patch correctly failing to find a Url is a fatal > condition, this is not ok as it would fail to operate with older servers > that do not have a url on the rules. > I believe it is not a fatal condition. If you mean line 100, it is for the case of some failure of the call. If the call succeeds and there is no URI, then line 105 happens and the URI is considered empty. If you are talking about the evaluation in line 21, this will be changed, the exact string comparison is there just for testing. > It is not clear to me what happen on an older client if URL is used but > not the service? Or is service always enforced ? (It is not clear to me > that it is). > I'm not sure I understand. If there is no service, the rule must necessarily fail to allow the access before even evaluating URI, or at least I think so. URI will only reduce the set of HBAC rules matching certain request. -- 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 rules - patch - request for feedback
On 02/28/2016 11:39 AM, Jakub Hrozek wrote: > On Fri, Feb 26, 2016 at 11:33:26AM -0500, Simo Sorce wrote: >> On Fri, 2016-02-26 at 17:17 +0100, Jakub Hrozek wrote: >>> On Fri, Feb 26, 2016 at 10:58:57AM -0500, Simo Sorce wrote: >>>> On Fri, 2016-02-26 at 13:17 +0100, Lukáš Hellebrandt wrote: >>>>> Hi, FreeIPA and SSSD communities! >>>>> >>>>> I am working on adding URI to HBAC as my thesis [1]. The goal is to >>>>> control access not only based on (user, host, service), but on (user, >>>>> host, service, resource's URI). >>>>> >>>>> I created a patch for FreeIPA [2] so it is capable of storing URI as >>>>> part of HBAC rule. I created a patch for SSSD [3] so it is able to get >>>>> this URI from FreeIPA and use it in HBAC evaluation. >>>>> >>>>> I still need to develop a part of SSSD receiving URI-aware requests. It >>>>> will either be an enhancement of Infopipe or I will use PAM responder >>>>> (any suggestions?). >>>>> >>>>> I wanted to kindly ask you for review and your opinions on the patches >>>>> and generally on my approach. This would be my first contribution to >>>>> FreeIPA and SSSD so there might be bugs. What do you think? >>>>> >>>>> Btw, is there some better place to share patches than a pasting tool? >>>>> Maybe some form of pull request? >>>>> >>>>> Thanks for your opinions! >>>>> >>>>> [1] >>>>> https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa >>>>> [2] >>>>> http://pastebin.com/rsHzXeAR >>>>> [3] >>>>> http://pastebin.com/atcZMuP1 >>>>> >>>> >>>> Hi Lukas, could please post your patches here using git-format-patch or >>>> even better provide a public git tree with them applied ? >>>> (Any place github, fedorapeople, your own server, etc. is fine) >>>> >>>> >>>> First a question, what service can actually use this scheme and how ? >>>> there is no URL field in PAM. >>> >>> When Lukas started the work, we IIRC concluded that PAM is not an >>> appropriate interface and we should probably expose some DBUS methods >>> for access control. We haven't really discussed any details since then. >> >> This only shifts the question, what service would use this interface ? >> note I am not opposed to it, but would like to understand how we are >> going to test that it actually works and is useful. > > I thought it was going to be an Apache module, much like Jan's > mod_authnz_pam, so maybe something like mod_authnz_hbac. > Exactly. It could have other uses, but an example I will be using will be an Apache module. And really, the only functional difference between mod_authnz_pam and the new module would be that the new module will be URI-aware (so it will use either PAM or Infopipe to communicate with SSSD and among other things, send URI, too) and it will probably be authorization-only. I am still not sure about the Infopipe vs PAM thing. I am trying to do normal authorization as the PAM one, just add some URI parameter to the request. I am still not sure whether it is a good idea to use a PAM variable (URI is not a standard field but maybe PAM supports other than standard variables?) or whether to add more functionality to Infopipe and do not use PAM at all. That is probably my most important question for now. -- 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
[Freeipa-devel] URI in HBAC rules - patch - request for feedback
Hi, FreeIPA and SSSD communities! I am working on adding URI to HBAC as my thesis [1]. The goal is to control access not only based on (user, host, service), but on (user, host, service, resource's URI). I created a patch for FreeIPA [2] so it is capable of storing URI as part of HBAC rule. I created a patch for SSSD [3] so it is able to get this URI from FreeIPA and use it in HBAC evaluation. I still need to develop a part of SSSD receiving URI-aware requests. It will either be an enhancement of Infopipe or I will use PAM responder (any suggestions?). I wanted to kindly ask you for review and your opinions on the patches and generally on my approach. This would be my first contribution to FreeIPA and SSSD so there might be bugs. What do you think? Btw, is there some better place to share patches than a pasting tool? Maybe some form of pull request? Thanks for your opinions! [1] https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa [2] http://pastebin.com/rsHzXeAR [3] http://pastebin.com/atcZMuP1 -- Lukas Hellebrandt -- 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] [PATCH] 0001 Adding URL to HBAC rule
On 02/26/2016 01:30 PM, Martin Kosek wrote:
> Greetings, welcome!
>
> On 02/26/2016 01:17 PM, Lukáš Hellebrandt wrote:
> ...
>> Btw, is there some better place to share patches than a pasting tool?
>> Maybe some form of pull request?
>
> There is :-) Please see advise here:
>
> http://www.freeipa.org/page/Contribute/Code#Submit_a_patch
>
> It has more information on top of submitting patches. For example, I think it
> would actually make sense to start with a design page where you would describe
> the use cases, design, APIs, etc:
>
> http://www.freeipa.org/page/Contribute/Code#Prepare
>
> Martin
>
Should I send it as an attachment? Ok, sending, but do not apply it yet
(even if you don't find bugs), I just need some feedback - not
everything is done yet.
--
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com
From 001d6c90c6fd007a49a22a9d96fe31fcc5b8ba6c Mon Sep 17 00:00:00 2001
From: Lukas Hellebrandt <lhell...@redhat.com>
Date: Thu, 18 Feb 2016 18:43:59 +0100
Subject: [PATCH] Adding URL to HBAC rule
---
ACI.txt| 2 +-
API.txt| 9 ++---
VERSION| 4 ++--
install/share/60basev2.ldif| 3 ++-
install/ui/src/freeipa/hbac.js | 14 --
install/ui/test/data/ipa_init.json | 3 ++-
ipalib/plugins/hbacrule.py | 7 +--
ipalib/plugins/internal.py | 1 +
8 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/ACI.txt b/ACI.txt
index 24cb332ce6e10c82a5bfab76d084fb6c0277800d..ecacc1ca50b6203d90879dcca35fdad16f7fc15b 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -93,7 +93,7 @@ aci: (targetattr = "externalhost || memberhost || memberservice || memberuser")(
dn: cn=hbac,dc=ipa,dc=example
aci: (targetattr = "accessruletype || accesstime || cn || description || hostcategory || ipaenabledflag || servicecategory || sourcehost || sourcehostcategory || usercategory")(targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Modify HBAC Rule";allow (write) groupdn = "ldap:///cn=System: Modify HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
dn: cn=hbac,dc=ipa,dc=example
-aci: (targetattr = "accessruletype || accesstime || cn || createtimestamp || description || entryusn || externalhost || hostcategory || ipaenabledflag || ipauniqueid || member || memberhost || memberservice || memberuser || modifytimestamp || objectclass || servicecategory || sourcehost || sourcehostcategory || usercategory")(targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Read HBAC Rules";allow (compare,read,search) userdn = "ldap:///all;;)
+aci: (targetattr = "accessruletype || accesstime || cn || createtimestamp || description || entryusn || externalhost || hostcategory || ipaenabledflag || ipauniqueid || member || memberhost || memberservice || memberuser || modifytimestamp || objectclass || servicecategory || sourcehost || sourcehostcategory || url || usercategory")(targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Read HBAC Rules";allow (compare,read,search) userdn = "ldap:///all;;)
dn: cn=hbacservices,cn=hbac,dc=ipa,dc=example
aci: (targetfilter = "(objectclass=ipahbacservice)")(version 3.0;acl "permission:System: Add HBAC Services";allow (add) groupdn = "ldap:///cn=System: Add HBAC Services,cn=permissions,cn=pbac,dc=ipa,dc=example";)
dn: cn=hbacservices,cn=hbac,dc=ipa,dc=example
diff --git a/API.txt b/API.txt
index e2976e0e2897355bdb7ead438d4b67524f2fb1e8..5886e6a94bd8f25caa54c373e9ac9314e0755aff 100644
--- a/API.txt
+++ b/API.txt
@@ -1656,7 +1656,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA
output: Output('summary', (, ), None)
output: PrimaryKey('value', None, None)
command: hbacrule_add
-args: 1,16,3
+args: 1,17,3
arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, required=True)
option: StrEnum('accessruletype', attribute=True, autofill=True, cli_name='type', default=u'allow', exclude='webui', multivalue=False, required=True, values=(u'allow', u'deny'))
option: Str('addattr*', cli_name='addattr', exclude='webui')
@@ -1672,6 +1672,7 @@ option: Str('setattr*', cli_name='setattr', exclude='webui')
option: DeprecatedParam('sourcehost_host', attribute=True, cli_name='sourcehost_host', multivalue=False, required=False)
option: DeprecatedParam('sourcehost_hostgroup', attribute=True, cli_name='sourcehost_hostgroup', multivalue=False, required=False)
option: DeprecatedParam('sourcehostcategory', attribute=True, cli_name='sourcehostcategory', multivalue=False, required=False)
+option: Str('url', attribute=True, cli_name='url', multivalue=False, required=False)
option: StrEnum('usercategory', attribute=True, cli_name='user
[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
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 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 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 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 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
[Freeipa-devel] URI in HBAC - code
SSSD: https://github.com/lhellebr/sssd/commits/url_in_hbac
Apache module: https://github.com/lhellebr/mod_hbacauthz_pam
FreeIPA: http://pastebin.com/X6H9BTwk
On 04/26/2016 03:56 PM, Petr Spacek wrote:
> On 26.4.2016 15:16, Jan Pazdziora wrote:
>> On Tue, Apr 26, 2016 at 02:16:54PM +0200, Petr Spacek wrote:
>
> * For backwards compatibility, lack of URI in request means any URI is
> matched (as described in the design document). Is it a good idea? Any
> other solution?
For other attributes in HBAC rules, the lack of a value means nothing is
matched. To match anything, you have to set "${attribute}category" to
"all". I
would prefer if URI matching was consistent with this, if it's possible.
>>>
>>> My understanding is that requests lacking URI parameter should not match any
>>> HBAC rules with non-empty URI. This will be backwards compatible because old
>>> clients will simply ignore new rules which cannot be evaluated properly
>>> anyway
>>> (for lack of information in client's request).
>>
>> The problem is that old clients will not ack for the new attributes
>> (they have no idea they should ask for them), so they will only see
>> parts of the HBAC rules.
>>
>> So the question is -- what is the correct way to make sure that old
>> clients (that would not ask for the new attributes) are not served
>> any rules that have those new attributes set?
>>
BTW what is the reason to split URIs into separate fields? If it's just
case
sensitivity, I would like to point out that you can switch case
sensitivity on
and off in the middle of a Perl regex using "(?i)" and "(?-i)".
>>>
>>> Personally I would rather see host+scheme+port split into separate
>>> attributes.
>>> That would allow reporting like 'give me all rules for FTP' etc. without
>>> substring magic.
>>>
>>> And yes, I agree with Honza that multiple values should be evaluated as
>>> logical OR.
>>>
>>> E.g.
>>>
>>> schemes: {http, https, ftp, ftps}
>>> URI: /home/pspacek
>>> host: any
>>> allow: pspacek
>>> should grant user pspacek access to directory /home/pspacek on any host as
>>> long as the scheme is http/https/ftp/ftps.
>>
>> So you propose cartesian product of the schemes and URI attributes
>> to be used?
>
> Yes.
>
>
> Before we can discuss this further we need to see current LDAP schema and
> code. Lukas, please share the code with us.
>
--
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
[Freeipa-devel] URI in HBAC
http://www.freeipa.org/page/V4/URI-based_HBAC I have made some important changes to the design document of this proposed feature. The difference is mainly changing regular expression interpretation of URI to longest-prefix matching. This change was done mainly because of upstream's reactions. I value any further comments and particularly discussion about the two topics mentioned at the end of the design page: * For backwards compatibility, lack of URI in request means any URI is matched (as described in the design document). Is it a good idea? Any other solution? * How about multiple URI's in one HBAC rule? Is it a good idea? How to interpret combinations of host+scheme+port (one field) and URI paths (another field) in that 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 - code
On 04/27/2016 03:34 PM, Lukáš Hellebrandt wrote:
> SSSD: https://github.com/lhellebr/sssd/commits/url_in_hbac
> Apache module: https://github.com/lhellebr/mod_hbacauthz_pam
> FreeIPA: http://pastebin.com/X6H9BTwk
>
> On 04/26/2016 03:56 PM, Petr Spacek wrote:
>> On 26.4.2016 15:16, Jan Pazdziora wrote:
>>> On Tue, Apr 26, 2016 at 02:16:54PM +0200, Petr Spacek wrote:
>>>>>>
>>>>>> * For backwards compatibility, lack of URI in request means any URI is
>>>>>> matched (as described in the design document). Is it a good idea? Any
>>>>>> other solution?
>>>>>
>>>>> For other attributes in HBAC rules, the lack of a value means nothing is
>>>>> matched. To match anything, you have to set "${attribute}category" to
>>>>> "all". I
>>>>> would prefer if URI matching was consistent with this, if it's possible.
>>>>
>>>> My understanding is that requests lacking URI parameter should not match
>>>> any
>>>> HBAC rules with non-empty URI. This will be backwards compatible because
>>>> old
>>>> clients will simply ignore new rules which cannot be evaluated properly
>>>> anyway
>>>> (for lack of information in client's request).
>>>
>>> The problem is that old clients will not ack for the new attributes
>>> (they have no idea they should ask for them), so they will only see
>>> parts of the HBAC rules.
>>>
>>> So the question is -- what is the correct way to make sure that old
>>> clients (that would not ask for the new attributes) are not served
>>> any rules that have those new attributes set?
>>>
>>>>> BTW what is the reason to split URIs into separate fields? If it's just
>>>>> case
>>>>> sensitivity, I would like to point out that you can switch case
>>>>> sensitivity on
>>>>> and off in the middle of a Perl regex using "(?i)" and "(?-i)".
>>>>
>>>> Personally I would rather see host+scheme+port split into separate
>>>> attributes.
>>>> That would allow reporting like 'give me all rules for FTP' etc. without
>>>> substring magic.
>>>>
>>>> And yes, I agree with Honza that multiple values should be evaluated as
>>>> logical OR.
>>>>
>>>> E.g.
>>>>
>>>> schemes: {http, https, ftp, ftps}
>>>> URI: /home/pspacek
>>>> host: any
>>>> allow: pspacek
>>>> should grant user pspacek access to directory /home/pspacek on any host as
>>>> long as the scheme is http/https/ftp/ftps.
>>>
>>> So you propose cartesian product of the schemes and URI attributes
>>> to be used?
>>
>> Yes.
>>
>>
>> Before we can discuss this further we need to see current LDAP schema and
>> code. Lukas, please share the code with us.
>>
>
>
Added a patch for backwards compatibility using different objectClass
for rules containing some of the new attributes:
SSSD: https://github.com/lhellebr/sssd/commits/url_in_hbac
FreeIPA: attached patch file (works together with the previously
submitted patch)
--
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com
From 5306556007a2448a8790f963abd52c6b89233605 Mon Sep 17 00:00:00 2001
From: Lukas Hellebrandt <lhell...@redhat.com>
Date: Wed, 4 May 2016 18:33:27 +0200
Subject: [PATCH] Use new objectClass for backwards compatibility
---
ACI.txt | 10 +-
Makefile| 2 +-
install/share/60basev2.ldif | 1 +
ipalib/plugins/hbacrule.py | 25 +
4 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/ACI.txt b/ACI.txt
index 39f331264e3d724bae7d47a3bcbc9e42da93bbcd..419b90d2251086bf0b47f994041cc4ac79842214 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -85,15 +85,15 @@ aci: (targetattr = "businesscategory || cn || createtimestamp || description ||
dn: cn=groups,cn=accounts,dc=ipa,dc=example
aci: (targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Remove Groups";allow (delete) groupdn = "ldap:///cn=System: Remove Groups,cn=permissions,cn=pbac,dc=ipa,dc=example";)
dn: cn=hbac,dc=ipa,dc=example
-aci: (targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Add HBAC Rule";allow (add) groupdn = "ldap:///cn=System: Add HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetfilter = "(|(objectclass=ipahbacrule)(objectclass=i
