6:47 a.m.
Hello,
I am trying to setup a keycloak configuration for my use case which goes like this:
- I have an api called test-api, written in python and using oauth2/oicd.
- Simple endpoints can be accessed if the access token's scope contains
"test-api-read-write". This scope is granted to admin and api users.
- Admin endpoints can be accessed if the access token's scope contains
"test-api-admin". This scope is granted only to admin users.
- All other users requesting an access token should not be granted any of the scopes.
Now I've set it up like this in keycloak:
1. Create new realm "test"
2. Create user "norights".
3. Create new client scopes "test-api-read-write" and "test-api-admin"
(display consent = off).
4. Create new client "test-api" (confidential, openid-connect).
5. Add "test-api-read-write" to default client scopes of "test-api",
add "test-api-admin" to optional client scopes.
6. Under "Scope" set "Full scope allowed" = off.
To test the setup I go to the test-api client scopes page and click "Evaluate"
with
- optional client scopes: test-api-admin
- user: norights
This returns a generated access token like shown at the bottom of this mail. Especially,
it contains the line
"scope": "openid profile test-api-admin email test-api-read-write"
This is really suprising to me, I expected "scopes" to *not* contain any of the
"test-api-*" scopes. After all the user norights does not have any roles or
permissions setup yet. Quoting from a previous mail on this list:
"If full scope is disabled: access token, issued to specific client will have
intersection of user own roles with client scope, defined in scope section of client
configuration"
Here, the intersection with the users own roles/scopes seems to be missing.
I've looked at the code here:
https://github.com/keycloak/keycloak/blob/49407c2e4f870659e1d5a00c7fd6cf1...
.
It seems initToken does "token.setScope(clientSessionCtx.getScopeString());"
which seems to merely copy the scopes from the request. There's also this applyScope()
method that sees to do the intersection thing, but doesn't seem to be called in this
case.
Is my understanding of client scope just plain wrong? I could get it to work if I use the
"Authorize" tab and setup all this complicated policies stuff, but client scopes
just seem so much easier.
Thanks for creating such an impressive open source SSO solution!
-Matthias
Generated access token:
{
"jti": "14f8a8e5-b39f-4092-aaa8-25ce62ceac2e",
"exp": 1529408429,
"nbf": 0,
"iat": 1529408129,
"iss": "http://localhost:8080/auth/realms/test",
"aud": "test-api",
"sub": "f4ecc77a-45ad-4dbf-9295-87d2fa4518c9",
"typ": "Bearer",
"azp": "test-api",
"auth_time": 0,
"session_state": "35140ca3-6107-4a79-8f46-b1b298d4bb58",
"acr": "1",
"allowed-origins": [],
"resource_access": {},
"scope": "openid profile test-api-admin email test-api-read-write",
"email_verified": true,
"preferred_username": "norights"
}