variable part in the subject and resource in ladon policy to be filled by request

[devdavidkarlsson]

Is it currently possible to have variable for the subject and resource in a policy and populate these from the call to /allowed:

If not a feature request would be:

Policy: For example "templateable" type of policy where tada is replaced by the subject in the allowed call:

{
         “id”: “666",
         “description”: “thing-admins.“,
         “subjects”: [“groups:thing-{tada}-admins”],
         “actions” : [“delete”],
         “effect”: “allow”,
         “resources”: [
           “resources:olt:things:{tada}:users:”
         ]
       }

/allowed request: The request would consist of a user, assuming the user is already member of a group called: groups:thing-99-admins

{
          "subject: "users:apa",
          "action": "get",
          "resource": "resources:olt:thing:99:users:"
        }

Expected behaviour:

The /allowed request triggers an evaluation of the policy id:666 (where 99 replaces the {tada} variable). and apa gets access allowed to the resource.

[andreasblomqvist]

Could this be a custom condition ?

For example someone wants to do a lookup on them self on a user-service. We want to check that the subject is the same as in the resource

[aeneasr]

I'm not sure I understand the question

[aeneasr]

Users are automatically resolved to their respective groups (if they are assigned to one) and the policies attached to those groups are also checked. Is that what you're looking for?

[andreasblomqvist]

If we have a service: users That returns all users for /user/ that would only be allowed for admins That returns a specific user for /user/id that would be allowed for admins OR if you are the user that you are querying for

How do we do the check that you are the user you are quering for? is that best done as a custom condition ?

[aeneasr]

https://ory.gitbooks.io/hydra/content/access-control.html#subject-condition

[andreasblomqvist]

Is there a Slack for Hydra ?

[aeneasr]

[devdavidkarlsson]

What I wanted to know initially was: If I have "groups:thing-{tada}-admins"

where {tada} varies (1-1000) yielding a couple of 1000 different groups.

groups:thing-1-admins
groups:thing-2-admins
groups:thing-3-admins
..
groups:thing-n-admins

Where the groups would allow access to :"resources:olt:things:{tada}:users" also here {tada} indicating 1-1000.

ie. each group should get allowed to access it's own users.

groups:thing-1-admins --->"resources:olt:things:1:users" allowed groups:thing-2-admins --->"resources:olt:things:2:users" allowed ... groups:thing-n-admins --->"resources:olt:things:n:users" allowed

Would I need to create a policy for each of the 1000 different groups?

[aeneasr]

Ah I see, that is currently not possible natively. It might be solvable using conditions though.

Adding that functionality to the the way policies are used wouldn't make a lot of sense as it's a very specific use case and it would further complicate the template language.

[devdavidkarlsson]

Is it correct that all "conditions" are based upon a context?

You can't write conditions based on subject->resource only.

[aeneasr]

Is it correct that all "conditions" are based upon a context?

Yes

You can't write conditions based on subject->resource only.

You can't, but you can use some of the resource information in the context

[aeneasr]

If there are open questions left feel free to comment / reopen :)