[keycloak-user] Client scopes not checked?

[Matthias Kesternich]

Hi Marek,



thanks for your answer.



>    - The client scopes are those, which are referenced in OAuth2 scope 

>    parameter. There are 2 types of this:



Yes, OAuth2 scope parameters are the ones I actually want to use.



>     -- Default client scopes: they are always assigned used and will be in 

>    access token even if you don't use any special value of "scope" 

>    parameter sent from the application



Ok, this is what was irritating me. According to this section in the spec

https://tools.ietf.org/html/rfc6749#section-3.3 :



"The authorization server MAY fully or partially ignore the scope

   requested by the client, based on the authorization server policy or

   the resource owner's instructions."



I assumed that Keycloak would exercise some "authorization server policy"

to restrict the scopes that are returned. Right now it seems to restrict the 

value of "scope" only to the client scopes, but it does make any further 

scope restrictions based on e.g. the user's roles.



This leads me to my next question: If I want to return only the scopes that

a user actually may acquire, how do I do this in Keycloak? Do I use the

"Authorization" tab and configure appropriate policies? Do I write a custom

mapper that overwrites the default "scope" value? I'm going to experiment

with this anyways, but I'd like to know if I'm abusing the wrong machinery 

to achieve this goal.



> - The "Full Scope Allowed" in the tab "Scope" of the client is unrelated 

>    to the Client Scopes. These point to Role Scope Mappings. I've tried to 

>    clearify this a bit in the recent docs for 4.0.0.Final [1]. Let me know 

>    if it's still unclear.



Yes, I've read that paragraph before and actually it helps me to know that

there are different scopes, but it's not always clear to me in which context

which scope is actually being referred to. I guess a diagram about the

different interactions between roles, users, policies, mappers and whatnot

could help to clear this up a bit. It's probably easier to put in a picture than

to explain with words. When I get the time and understand things, I'll draw 

one myself and share it here.



Best,

-Matthias





Am 19.06.18, 16:55 schrieb "Marek Posolda" <mposolda at redhat.com>:



    Hi Matthias,

    

    Unfortunately the word "scope" is a bit overloaded in Keycloak. Few 

    things to clarify:

    

    - The client scopes are those, which are referenced in OAuth2 scope 

    parameter. There are 2 types of this:

    -- Default client scopes: they are always assigned used and will be in 

    access token even if you don't use any special value of "scope" 

    parameter sent from the application

    -- Optional client scopes: they are added just if they are requested by 

    scope parameter. In your case, you added Optional scope "test-api-admin" 

    . So you will see that if you use scope parameter like "openid 

    test-api-admin" , it will use "test-api-admin" client scope. But if you 

    don't use any specific value of scope parameter by your adapter, then 

    "test-api-admin" won't be used

    

    - The "Full Scope Allowed" in the tab "Scope" of the client is unrelated 

    to the Client Scopes. These point to Role Scope Mappings. I've tried to 

    clearify this a bit in the recent docs for 4.0.0.Final [1]. Let me know 

    if it's still unclear.

    

    [1] 

    https://www.keycloak.org/docs/latest/server_admin/index.html#scopes-explained

    

    Marek

    

    On 19/06/18 13:47, Matthias Kesternich wrote:

    > 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/49407c2e4f870659e1d5a00c7fd6cf1fbd16f8de/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java .

    >

    >

    >

    > 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"

    >

    > }

    >

    >

    >

    > _______________________________________________

    > keycloak-user mailing list

    > keycloak-user at lists.jboss.org

    > https://lists.jboss.org/mailman/listinfo/keycloak-user