Is there a way we can utilize the existing sssd implementation for this? It seems like major code duplication (and risk) for us to re-do this effort. We'll hear no end of "it works in <foo> and not in <bar>" where IPA and sssd can be either foo or bar.

Replying to [comment:2 rcritten]:

Is there a way we can utilize the existing sssd implementation for this? It seems like major code duplication (and risk) for us to re-do this effort. We'll hear no end of "it works in <foo> and not in <bar>" where IPA and sssd can be either foo or bar.

I do not think it will be really that much easier. SSSD would have to make this a shared component and deliver as library and then we would have do python bindings on top. There is also a but of difference where SSSD keeps the data so that part should abstracted too. And the logic seems not that complex to duplicate in Python.If they do not work exactly the same it is a bug in one that should be fixed. I think attempt to reuse code will actually be an overkill here..

Ok, this is going to be very risky then and dependent that we implement it exactly the same way that they do (and maintain bug-to-bug compatibility).

This seems like a perfect candidate for one of the sssd guys to implement.

Replying to [comment:4 rcritten]:

Ok, this is going to be very risky then and dependent that we implement it exactly the same way that they do (and maintain bug-to-bug compatibility).

This seems like a perfect candidate for one of the sssd guys to implement.

It just seems to be same but there are too many important differences:

Server - operates on all rules
SSSD - only on enabled rules targeted for the host
Server - stores data in ldap
SSSD - stores data in LDB
Server - Python
SSSD - C
Server - needs to match all rules that satisfy the event
SSSD - can bail out on any deny rule

Point is:
- input data is slightly different
- algorithm is slightly different
- language is different

Overlap is really small.

I'm arguing that one of the sssd guys should re-implement this in python for us for the framework.

There is ticket #938 for SSSD to provide validation. It might not be possible to get it in the scope of 2.1 so this ticket might be split into smaller tasks.

I'm looking into implementing this, but I disagree with the list of supported cases described in the original report. I think instead that we should support the following cases:

- Evaluate against all currently enabled rules
    - Simulates real login at this moment
- Evaluate against all currently active rules plus one named rule
    - Named rule treated implicitly as enabled (even if disabled in reality on the server)
    - Useful for prototyping a new rule being added
- Evaluate against a single named rule treated implicitly as enabled
    - Named rule treated implicitly as enabled (even if disabled in reality on the server)
    - Similarly useful for prototyping new rules

Agree with Stephen. I'm working on implementing hbactest plugin that will allow to evaluate available rules along the lines described by Stephen by using libipa_hbac library.

Suggested commands:

- Test login of an user coming from source host to a service on a named host using all currently enabled rules:

{{{ipa hbactest-login --user= --srchost= --host= --service=}}}

- Test user coming from source host to a service on a named host against specified rules only (treat these rules as enabled).  If --login option is specified, simulate enabling of the specified rules  in addition to already enabled ones and test the login of the user:

{{{ipa hbactest-rules rules-list [--login] --user= --srchost= --host= --service=}}}

Replying to [comment:14 abbra]:

Suggested commands:

• Test login of an user coming from source host to a service on a named host using all currently enabled rules:

{{{ipa hbactest-login --user= --srchost= --host= --service=}}}

• Test user coming from source host to a service on a named host against specified rules only (treat these rules as enabled). If --login option is specified, simulate enabling of the specified rules in addition to already enabled ones and test the login of the user:

{{{ipa hbactest-rules rules-list [--login] --user= --srchost= --host= --service=}}}

It seems that all of the above can be accomplished using one command:

{{{ipa hbactest --user= --srchost= --host= --service= [--rules=rules-list] }}}

I seems a bit simpler and more logical.
This way one can test the conditions without extra --rules and then play with the value of the list.

With the removal of the deny rules this functionality is getting simpler as in the past the idea was to determine which deny rule would prevent access or the access is just not granted by allow rules. Now we know that if the evaluation failed the access is not granted through the allow rules.

I wonder what we can do in future about it to help user to solve the problem... But this is out of scope for now.

Please also discuss the design on the list and not in the ticket as not everybody who has an opinion is CCed on the ticket feed.

Yes, I'll write up proposal. Rob is also asked for a validation of rules.

Proposal and patch are send to freeipa-devel@.

master: dd296ee