Description
Before reporting an issue
- I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.
Area
authorization-services
Describe the bug
When using the authorization, if multiple resources match the same URI, the authorization process only considers one of these resources, leading to unexpected response.
For example, similar configuration we use:
Resource A:
- URI: /resource
- Scope: read
Resource B:
- URI: /resource
- Scope: write
Permission A (Resource-based):
- Resource A
- Policy: user with role ROLE_READ has access
Permission B (Resource-based):
- Resource B
- Policy: user with role ROLE_WRITE has access
User has role ROLE_READ.
When permission "/resource#read" requested, 200 http code response received.
When permission "/resource#write" requested, 400 http code response received, but 403 code expected.
After some debugging, seems like permission evaluation does not happen. Authorization request ends on permission search for evaluation.
Version
26.2.5
Regression
- The issue is a regression
Expected behavior
When permission "/resource#write" requested, 403 http code response received.
Actual behavior
When permission "/resource#write" requested, 400 http code response received.
{
"error": "invalid_resource",
"error_description": "Resource with id [{id}] does not exist."
}
How to Reproduce?
Create Client with Authorization On.
Create Client roles: ROLE_READ, ROLE_WRITE.
Add authorization config:
Scopes:
- read
- write
Resource A:
- URI: /resource
- Scope: read
Resource B:
- URI: /resource
- Scope: write
Policy A:
- Role based, has role ROLE_READ
Policy B:
- Role based, has role ROLE_WRITE
Permission A (Resource-based):
- Resource A
- Policy A
Permission B (Resource-based):
- Resource B
- Policy B
Execute similar authorization request, 200 http code received
curl -X POST
http://{HOST}:{PORT}/realms/{REALM}/protocol/openid-connect/token
-H "Authorization: Bearer ${ACCESS_TOKEN}"
--data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket"
--data "permission_resource_format=uri"
--data "permission_resource_matching_uri=true"
--data "audience={RESOURCE_SERVER_ID}" \
--data "permission=/resource#read"
After that, execute similar request, 400 http code received
curl -X POST
http://{HOST}:{PORT}/realms/{REALM}/protocol/openid-connect/token
-H "Authorization: Bearer ${ACCESS_TOKEN}"
--data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket"
--data "permission_resource_format=uri"
--data "permission_resource_matching_uri=true"
--data "audience={RESOURCE_SERVER_ID}" \
--data "permission=/resource#write"
Sample realm for reproduce
Anything else?
Issue in same context was introduced there #30270