Skip to content
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

use inquiries data in policies #20

Closed
ThomasChiroux opened this issue Sep 25, 2019 · 5 comments
Closed

use inquiries data in policies #20

ThomasChiroux opened this issue Sep 25, 2019 · 5 comments

Comments

@ThomasChiroux
Copy link

Hi,

Is it possible to use inquiries parameters in element of the policy ?

The use case is to limit an API call to only raws that belongs to a particular user.
(stored in the example below in 'route_instance_id')

I want to authorise the rule only if the route_instance_id in the inquiry resource match the user_id in the inquiry subject

The only way I've found for now is to add dynamic policy at each request, but it's not very efficient and hard to maintain.

ex:

inquiry = vakt.Inquiry(
                subject={"user_id": 42, "roles": ["user"]},
                action="GET",
                resource={
                        'route_endpoint': 'test_endpoint',
                        'route_instance_id': 42}
                        'query_sort': '-id',
                        'query_foo': 'bar'}
                    }
                ),
                context={"ip": "127.0.0.1"},
            )

against policy:

policy_user_test = vakt.Policy(
        uuid.uuid4().hex,
        resources=[
            {
                "route_endpoint": Eq("test_endpoint"),
                "route_instance_id": Inquiry('subject', 'user_id'),
            }
        ],  # uri
        actions=[Eq("GET")],
        subjects=[{"roles": AnyIn("user")}],
        effect=vakt.ALLOW_ACCESS,
        description="""
        Allow get for only its own instance
        """,
    )

I've seen there was a first support before 1.2 for string with SubjectEqual & co, but it has been dropped and did not support dict, is there a reason for dropping this ?

I think the use case is quite common (below is an example, but i've plenty of use-case like this one for the api).

Or perhaps there is another way to do the same thing i've overlooked ?

Thanks,
Regards,
Thomas.

@ThomasChiroux ThomasChiroux changed the title Introspection in policies use inquiries data in policies Sep 25, 2019
@kolotaev
Copy link
Owner

Hi Thomas,
Thanks for the question.

SubjectEqual & co are still there so I can't say they are dropped, but indeed they still work only in case your policies (and inquiries respectively) are String-based like it was prior to 1.2. I have underestimated their usefulness when implemented Rule-based Policies support (Policies where you can define various attributes with dicts, like in your example). Besides, as far as I remember, there were some implementation issues with composition of Rules (And, Or, ... Not, etc) for such Rules, so they remained overlooked.

Unfortunately the only way to achieve this is to deal with them in the old-fashion (like prior to 1.2), but in this case you're loosing attributes dict definition facility.

We need to add new Rules, or new way to define such cases. Something like:
SubjectKeyEqual('user_id')
I agree that there are plenty of use-cases for such functionality. So, hold on, I'll implement it as the next most important feature after we finish and merge SQLStorage support.

Please, don't close this issue - it will be the reference.

@ThomasChiroux
Copy link
Author

Hi,
thanks, that's great news.
Will follow it closely :-)
Thomas.

@kolotaev
Copy link
Owner

kolotaev commented Nov 26, 2019

@ThomasChiroux, here is the initial PR for this feature.
You can take a look. I'm gonna add some more unit-tests and merge it into 1.4-dev which is planned to be released in a week or so.

@kolotaev
Copy link
Owner

kolotaev commented Dec 5, 2019

Resolved as of vakt v. 1.4.0.

@kolotaev kolotaev closed this as completed Dec 5, 2019
@kolotaev kolotaev added question and removed WIP Work in progress labels Dec 5, 2019
@ThomasChiroux
Copy link
Author

Hi, sorry wasn't available last week.

1.4.0 works perfectly for my use case.

Thanks a lot !!
Thomas.

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

No branches or pull requests

2 participants