@chicco785, I'm not sure if we need this representation but just reuse the representations we have for each type of policy.

I think that the payload should change to something like this:

{
    "scopes": [
        "read"
    ],
    "policies": [
	{
            "type": "group",
            "groupsClaim": "groups",
            "groups": [
                {
                    "id": "abc",
                    "path": "abc",
                    "extendChildren": true
                }
            ]
        }
     ]
}

If we do that way, I think it is easier to map the different configuration options for each policy type as well avoid unecessary parsing from UmaPolicyRepresentation to a GroupPolicyRepresentation (considering the example above).

in this way we would not "simplify" the payload as discussed in first instance. i understand that this may simplify lot of coding, but may be less friendly from the point of view of creating policies. as you prefer.

I'm not sure either :) Let me think a bit more about that, maybe we can come up with something even easier. For instance, if we are supporting user, role, group and client policies, we could just use something like:

{
    "scopes": ["read"],
    "users": ["a", "b"],
    "groups": ["c", "d"],
    "roles": ["e", "f"]
}

while at creation time many things can be implied, the internal representation is still richer, and some how we have to deal with that (or with assumptions, or with "optional fields").

currently, for example to share with more groups, you will create something like that via the api:

{
    "scopes": [
        "read"
    ],
    "policies": [
	{
        "type": "group",
        "subjects": [
            "a759a3a2-95b9-4f88-9c5e-c2b9ea2f1211",
            "d14d66e5-3341-439a-9da4-60944487a158"
        ]
    }
    ]
}

or for users

{
    "scopes": [
        "read"
    ],
    "policies": [
	{
        "type": "user",
        "subjects": [
            "a759a3a2-95b9-4f88-9c5e-c2b9ea2f1211",
            "d14d66e5-3341-439a-9da4-60944487a158"
        ]
    }
    ]
}

The response will include the enriched json (including optional parameters - but probably we can have a way to not return them, unless they are different from the "default"):

{
    "logic": "POSITIVE",
    "decisionStrategy": "UNANIMOUS",
    "scopes": [
        "read"
    ],
    "policies": [
        {
            "id": "94c61cd8-6d64-4e08-91e7-7066809db190",
            "type": "group",
            "logic": "POSITIVE",
            "decisionStrategy": "UNANIMOUS",
            "subjects": [
               "a759a3a2-95b9-4f88-9c5e-c2b9ea2f1211",
               "d14d66e5-3341-439a-9da4-60944487a158"
            ],
            "options": {
                "groupsClaim": [
                    "groups"
                ]
            }
        }
    ],
    "id": "d59d7e08-1448-4a65-894a-ee921987b348"
}

Yeah, I'll agree with you. Let's keep this structure.

+1 to not return "options" if they are basically the defaults. And I think does not make sense to return "id" and "decisionStrategy". The "id" because if you want to update the "group" policy above we could just update the existing "group" policy, right ?

If we remove UmaPolicyRepresentation we probably don't need this method.

We could also avoid this method if we remove UmaPolicyRepresentation.

Here we could just return the representation that we already have for each policy if we remove UmaPolicyRepresentation.

this is true, but current representation is very verbose, that was the reason to have an intermediary representation.

You should override getType and return "uma" just like we do with other types of permissions. See https://github.com/pedroigor/keycloak/blob/54ebc1918c0249384877a9d6b2c3f12919cbff36/core/src/main/java/org/keycloak/representations/idm/authorization/ResourcePermissionRepresentation.java#L22.

If you override getType you don't need to use setType here.

To create a UMA permission/policy, you should first create a PermissionTicket and then mark it as granted. Once you do that, the policy will be created automatically so you could just update the policy associated with the ticket accordingly.

My PR already deals with the management of UMA permissions, so you just need to worry about creating permission tickets and grant/revoke/delete them accordingly in order to have the policy updated.

Don't we also need to know the requester to which the permission will grant access to the resource ?

the idea is that uma-policy api allows to create policies from the owner point of view.
which means the requester is not needed. e.g.

1. if owners of resource a create a policy, there is no an actual requester, but still, of course we can assume the requester to be the user to which the owner granted access.
2. if the policy does not deal with authorising a user, but for example a role or a group, who should be the requester?

So we have now two types of UMA permissions:

• Those created through a permission ticket as part of an authorization flow using UMA
• Those created by the resource server on behalf of an user

My main concern here is how we are going to handle permissions created by the resource server when the user is managing his permissions using Account Services ? How they will be revoked ? What will happen if you have a UMA permission created from a ticket and others created by the resource server ?

I think that probably the solution is as follow:

1. if user create a permission via ticket, when the permission is removed also the ticket is removed.
2. if user modifies a permission created via a ticket, the change is rejected.

of course in case a permission is created directly using APIs, there is no issue in "revoking" them. right?

My point is that the user won't be able to revoke permissions created using APIs if they are using Account Services. By Account Services I mean this https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_authorization_api_aapi.

If you look that documentation you`ll see that we allow users to manage permissions to their resources through Keycloak Account Service. But there we only allow users to revoke the permissions created as consequence of approving/granting a permission ticket.

Makes more sense now ?

I understand now, you are referring the user Account UI not "Service Accounts" auth flow :)
UI should also support management of other user defined policies.

Yeah and that is a big thing, you know :)

And there are some things to consider that are not so simple or don't make sense:

• How the UI will look like in order to allow users to manage these additional policies ?
• Does it makes sense to allow users (we are talking about end-users) to manage role, group and client policies. Think about it, as a end-user I really don't need to know about roles in the application I'm using.

• client, i agree, it does not make sense in the ui.
• role, may have, depending on the complexity of roles in your app.
• groups, makes definitively sense.

Why pass the policyId if user-managed resources have a single UMA permission associated with it ?

To update a UMA permission (considering you are creating accordingly with my comments to the create method) you basically need to grab the policy from any permission ticket with status granted.

Don't we also need to know the requester to which the permission will grant access to the resource ?

if i recall correctly from the gdoc, we agreed that for flexibility a resource could have more "permissions" associated. so that each permission in the end is evaluated like an "or".

In this case, we can just update the "decision strategy" of the user-managed permission to "affirmative" as ti will work like an "or".

correct, but then either we support (which we agreed to remove) aggregated policies, or we won't be able to say things as:

authorise if

• permission1 user role A

  or

• permission2 user role B and group Z

That is fine because you are creating a uma permission type. This type of policies should be associated with multiple "policies". To achieve the "or" behavior you just set the decision strategy to AFFIRMATIVE when creating the "uma" permission type.

In other words, you don't need to manage multiple permissions for a single resource, but just a single one by updating the scopes and associated policies.

mmm, i am confused now...

I tested the behaviour of your code.

1. If user A ask for READ permission on resource Z of user B. A UMA permission is created attached to resource Z.
2. If user C ask for WRITE permission on resource Z of user B. An additional UMA permission is created attached to resource Z.

so if i want to see, remove, or edit only one of the two created uma permissions for resource Z i need the id that identify such permission.

also, if we would have a single uma permission per resource, how we would be able to assign different scopes for the same resource to different users?

My changes are all about the "normal" UMA flow, where a requester is asking access to the owner of a resource.So, yeah, we have different UMA permissions for Resource Z each one specific for User A and User C. It is easier to identify those permissions, as you just need to know the resource and the requester, so you can obtain a ticket which is then associated with the UMA permission.

That is what I have commented here about adding the requester to your /uma-policy, so you could manage a specific policy for a specific requester/user. But that won't work for you, as you need to define additional policies to a resource that are not necessarily linked to a requester. For instance, if you define group or role policies.

Now think about this scenario. You have created a UMA permission using /uma-policy granting access to a specific role or group. Now you want to check if a user has access to the resource associated with this permission. As you know, you can ask for permissions using a ticket (UMA flow), using a permission request and passing the resource(s) or just obtain all permissions from the server. The two first methods are OK since you know the resource you need to check for permissions. But what about the last method ? Obtain all permissions from the server ? How we would perform this evaluation without iterating over all existing resources in the server ? That may impact performance ....

1. we can add requester for ticket permission generated UMA permissions as query parameter.
2. we can use in a "tricky" way requester for the other policies. e.g. if it is not a uma permission, requester is used to find all the policy where related to "requesterId" via user, group or role.

I think I understand 1. And that would allow users to manage their policies created using UMA flow through a permission ticket (or sharing via Account Services).

But did not understand 2.

i proposed that to have a quick way from a ui to see which resources "using" uma a user is related to so that they can be displayed in the ui without obtaining all permissions.

Why pass the policyId if user-managed resources have a single UMA permission associated with it ?

Also when you delete a policy, does that means you are also revoking access to a requester ?

1. see above
2. if the policy is part of a ticket, then the ticket should be removed.

We should also allow querying by requester. For example, give me all uma permissions associated with this resource and related with the requester XPTO.

1. make sense in case the policy is originated from a PermissionTicket