New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Policies could be dependent on any user attribute #1436

Open
cornelinux opened this Issue Feb 8, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@cornelinux
Copy link
Member

cornelinux commented Feb 8, 2019

The conditions for a policy to apply could depend on any arbitrary user attribute (like a group membership)

See https://community.privacyidea.org/t/resolver-and-user-token-relation/941

@cornelinux

This comment has been minimized.

Copy link
Member Author

cornelinux commented Feb 14, 2019

Also the event handler conditions should be triggered via such user attributes.
The interesting thing is, that then there is no need to be depent on the resolver, since the resolver can very well also be such an attribute.

@cornelinux

This comment has been minimized.

Copy link
Member Author

cornelinux commented Feb 14, 2019

To be more flexible in policies we would need to untangle the policy-table, which currently contains

  • The policy skeleton
    • the name
    • the scope
  • all the conditions
    • user
    • time
    • client IP
    • active
  • the action ("action")

We should probably split it up like the eventhandler.
THis way it would be much easier, to add new conditions for policies.
Split into the DB tables:

  • Policy
  • PolicyCondition
  • PolicyAction (Already now a policy can contain several actions, comma separated - how nasty is that!)

Also check, if conditions for policies and event handlers can have the same logic? (see #1435)

  • probably not.
@fredreichbier

This comment has been minimized.

Copy link
Member

fredreichbier commented Feb 18, 2019

I think, conceptually, wouldn't it be cool if policy conditions and event handler conditions could have the same logic? In the end, they both match on some properties of the current request.

In terms of DB tables, I agree with your thoughts above: I think it would be more sensible to store the policy conditions and actions in their own tables.

... but this could potentially make policy queries a bit slower. I don't know :-)

@cornelinux

This comment has been minimized.

Copy link
Member Author

cornelinux commented Feb 18, 2019

As far as the speed is concerned: Currently the policies are fetched at the beginning of the request. This problably would not be changed. We then have a request wide policy object. (We can even keep the policy-object without rereading it from the database too often - I think we already do this)

Condition Handling: At the first glance it might look the same. But at a second it is rather different since the logic of how events are triggered and how policies are fetched (think of get_action_value) are different. So we need to take a third look! ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment