[Bug] Sharing and Obtaining Permissions

Getting advice
1

Hello together,

I noticed a strange behaviour when obtaining permissions. Firstly, I shared a resource as a resource owner with a different user via the following:

curl -X POST \
     http://${host}:${port}/auth/realms/${realm_name}/authz/protection/permission/ticket \
     -H 'Authorization: Bearer '$access_token \
     -H 'Content-Type: application/json' \
     -d '{
       "resource": "{resource_id}",
       "requester": "{user_id}",
       "granted": true,
       "scopeName": "view"
     }'

Now, when obtaining permissions as the user who receives the shared resource I get two different results, depending on using the Resource Name or the Resource ID in the permissions parameter, to obtain permissions without a ticket. I use the following to obtain permissions one time with Resource ID in the permissions parameter and one time with Resource Name (following is example with Resource ID):

curl --location --request POST 'http://localhost:8080/auth/realms/proceed/protocol/openid-connect/token' \
--header 'Authorization: Bearer '$access_token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:uma-ticket' \
--data-urlencode 'audience=proceed-ms-backend' \
--data-urlencode 'permission=96a038cc-5b48-41fe-a38d-ac4fc0ef7885#delete' \
--data-urlencode 'response_mode=permissions'

When using the Resource ID I get the expected result:

{
    "error": "access_denied",
    "error_description": "not_authorized"
}

However, when using the Resource Name I get the following result:

[
    {
        "scopes": [
            "view",
            "edit",
            "delete"
        ],
        "rsid": "96a038cc-5b48-41fe-a38d-ac4fc0ef7885",
        "rsname": "Deployment"
    }
]

Unfortunately, I always get the full available scopes for a resource, when using the Resource Name. Now I could just use the Resource ID but for my use cases it would be a lot better to use the Resource Name, because using the Resource ID would require some workarounds.

For example, I have an Express.js server, that protects resources via policy enforcing through the Node.js Keycloak-Connect library. It expects the following syntax: keycloak.enforcer('{Resource}:{Scope}'), where I need to use the Resource Name for {Resource}. However, I only get the expected result when using the Resource ID.

Additionally, I think the documentation (Authorization Services Guide) is odd. When obtaining permissions with the permissions parameter the documentation says, to use it as RESOURCE_ID#SCOPE_ID. When using the Scope ID it doesn’t work at all and from the documentation I would expect, that it only works with Resource ID. However, it seems to work with Resource Name too but apparently returns the wrong result, as described earlier.

Obtaining permissions by a ticket instead works when using Resource Names and it also seems to work with resources, that a user has access to via policies and permissions. Maybe there is only something wrong with shared permissions by a ticket?

It would be really useful for me to have this working with Resource Names, so am I doing something wrong or is this really a bug?

Kind regards,
Kevin