Hello guys. I would like to ask you help with the following. I’m currently looking at on-behalf-of scenario with Keycloak. In this case we have ‘web app’ calling ’svc-1’, which in turn calls another service ‘svc-2’. That is, we have: web —> svc-1 —> svc-2. The idea is to let svc-2 know who is actual initiator of the call chain (end-to-end identity propagation). The question is about how to do that with Keycloak. First, in order to propagate caller identity we could exchange tokens in ‘svc-1’. In this case we can have correct audience and, thus, control token usage. Second, we need is to remove any excessive permissions (client roles) that are not related to ‘svc-2’ call in order to reduce potential harm in case this token is intercepted by someone. And if I know how to exchange tokens, I cannot find how to downgrade the token during the exchange. As I see in documentation, ‘scope’ parameter is not supported for token exchange. So, my questions are: Is token exchange a right tool for this task? Is it possible to downgrade exchanged token? And how, if so? Thank you, Alexey _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hi Pedro! Thank you for answer! I’m would like to be able to control all aspects: audience, scope and roles. Today I also found that exchanged token may contain more roles than it is defined through on Scope tab for svc-1, if caller has some additional roles. So, after token echange svc-1 can have more rights than it would be possible without token exchange. Alexey. On 27 Feb 2019, at 18:50, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: Hi, The token exchange should be the right tool. Are you trying to downgrade scopes or just remove the client roles that are not related with svc-2 ? Regards. Pedro Igor On Tue, Feb 26, 2019 at 5:33 AM Alexey Titorenko <titorenko(a)dtg.technology&gt; wrote: > Hello guys. > > I would like to ask you help with the following. I’m currently looking at > on-behalf-of scenario with Keycloak. In this case we have ‘web app’ calling > ’svc-1’, which in turn calls another service ‘svc-2’. That is, we have: > web —> svc-1 —> svc-2. > > The idea is to let svc-2 know who is actual initiator of the call chain > (end-to-end identity propagation). The question is about how to do that > with Keycloak. > > First, in order to propagate caller identity we could exchange tokens in > ‘svc-1’. In this case we can have correct audience and, thus, control token > usage. Second, we need is to remove any excessive permissions (client > roles) that are not related to ‘svc-2’ call in order to reduce potential > harm in case this token is intercepted by someone. > > And if I know how to exchange tokens, I cannot find how to downgrade the > token during the exchange. As I see in documentation, ‘scope’ parameter is > not supported for token exchange. > > > So, my questions are: > Is token exchange a right tool for this task? > Is it possible to downgrade exchanged token? And how, if so? > > > Thank you, > Alexey > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user

Yes, I tried. It seems, that scope parameter is ignored and this is also said in the documentation ( https://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exch... ): scope NOT IMPLEMENTED. This parameter represents the target set of OAuth and OpenID Connect scopes the client is requesting. It is not implemented at this time but will be once Keycloak has better support for scopes in general. Other settings for client applications do not work. Below are tokens which I got for calling client and after token exchange in my test application. It has a bit more complex structure than I described before. It is: user —> jsp-web-app —> docs-svc —> facade-svc —> svc-1 —> svc-2 Token exchange happens when facade-svc calls svc-2. Below are two tokens: 1. First is a token which is used to call from jsp-web-app to facade-svc 2. Second is a token which I have after token exchange in facade-svc to call svc-2. For this test I configured facade-svc so that it cannot call ’svc-2’ at all (svc-2 is absent in Scope and Client Scope tabs). But after token exchange ’svc-2’ is successfully called. Note, how wide scope, roles and audience of the exchanged token are. facade-svc is only allowed to call ’ svc-1’. Also, in the exchanged token I see audiences and scopes which were not present in the original caller’s token. { "jti": "863d8801-dd28-4314-8b50-4ddefe97c380", "exp": 1551344900, "nbf": 0, "iat": 1551344600, "iss": "http://localhost:8180/auth/realms/DTGOpenIDDemoApp", "aud": [ "facade-svc", "docs-svc" ], "sub": "6d312ba3-aa9e-4646-af57-95a9e965b8a9", "typ": "Bearer", "azp": "jsp-web-app", "auth_time": 1551343339, "session_state": "3606845e-9f85-4dc7-8edb-41ce3ab67268", "acr": "0", "allowed-origins": [ "http://localhost:8080" ], "resource_access": { "facade-svc": { "roles": [ "user" ] }, "docs-svc": { "roles": [ "user" ] } }, "scope": "openid profile email", "email_verified": false, "organization": "Org-1", "preferred_username": "user" } { "jti": "cef6ae27-0e98-491d-9ef2-69850b664766", "exp": 1551341466, "nbf": 0, "iat": 1551341166, "iss": "http://localhost:8180/auth/realms/DTGOpenIDDemoApp", "aud": [ "facade-svc", "docs-svc", "account", "svc-2" ], "sub": "6d312ba3-aa9e-4646-af57-95a9e965b8a9", "typ": "Bearer", "azp": "facade-svc", "auth_time": 1551341150, "session_state": "dcfa21cc-57a2-4302-a459-d772b5f79f13", "acr": "1", "realm_access": { "roles": [ "offline_access", "uma_authorization", "user" ] }, "resource_access": { "facade-svc": { "roles": [ "user" ] }, "docs-svc": { "roles": [ "user" ] }, "account": { "roles": [ "manage-account", "manage-account-links", "view-profile" ] }, "svc-2": { "roles": [ "user" ] } }, "scope": "openid profile email", "email_verified": false, "preferred_username": "user" } On 27 Feb 2019, at 19:22, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: IIRC, you can use a scope parameter when doing a token exchange. Other aspects could be managed by setting up client scopes to your client applications, did you try that ? On Wed, Feb 27, 2019 at 12:59 PM Alexey Titorenko < titorenko(a)dtg.technology&gt; wrote: > Hi Pedro! > > Thank you for answer! > > I’m would like to be able to control all aspects: audience, scope and > roles. > > Today I also found that exchanged token may contain more roles than it is > defined through on Scope tab for svc-1, if caller has some additional > roles. So, after token echange svc-1 can have more rights than it would be > possible without token exchange. > > > Alexey. > > On 27 Feb 2019, at 18:50, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > Hi, > > The token exchange should be the right tool. Are you trying to downgrade > scopes or just remove the client roles that are not related with svc-2 ? > > Regards. > Pedro Igor > > On Tue, Feb 26, 2019 at 5:33 AM Alexey Titorenko < > titorenko(a)dtg.technology&gt; wrote: > >> Hello guys. >> >> I would like to ask you help with the following. I’m currently looking >> at on-behalf-of scenario with Keycloak. In this case we have ‘web app’ >> calling ’svc-1’, which in turn calls another service ‘svc-2’. That is, we >> have: web —> svc-1 —> svc-2. >> >> The idea is to let svc-2 know who is actual initiator of the call chain >> (end-to-end identity propagation). The question is about how to do that >> with Keycloak. >> >> First, in order to propagate caller identity we could exchange tokens in >> ‘svc-1’. In this case we can have correct audience and, thus, control token >> usage. Second, we need is to remove any excessive permissions (client >> roles) that are not related to ‘svc-2’ call in order to reduce potential >> harm in case this token is intercepted by someone. >> >> And if I know how to exchange tokens, I cannot find how to downgrade the >> token during the exchange. As I see in documentation, ‘scope’ parameter is >> not supported for token exchange. >> >> >> So, my questions are: >> Is token exchange a right tool for this task? >> Is it possible to downgrade exchanged token? And how, if so? >> >> >> Thank you, >> Alexey >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > >

Hi! I will look more carefully on how mappers work in this case. I can create JIRA case if this can help. I’m not sure that this is a bug. I’m just trying to understand how much flexibility I have in this case. Do you think it make sence? Creating JIRA? On 28 Feb 2019, at 16:16, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: The wider scope may be related on how the protocol mappers are being run, especially those associated with the client scopes you are using by default (or for a particular client). For instance, you have all those audiences because your user is granted with roles to those clients and the mapper is just include any of these clients in the audience. I need to look at this in more details. I will not say that you are using a wrong setting because if even you are, I don't think documentation is clear enough to get it right. Do you mind creating a JIRA to track this? Regards. Pedro Igor On Thu, Feb 28, 2019 at 6:21 AM Alexey Titorenko <titorenko(a)dtg.technology&gt; wrote: > Yes, I tried. It seems, that scope parameter is ignored and this is also > said in the documentation ( > https://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exch... > ): > > scope > NOT IMPLEMENTED. This parameter represents the target set of OAuth and > OpenID Connect scopes the client is requesting. It is not implemented at > this time but will be once Keycloak has better support for scopes in > general. > > > Other settings for client applications do not work. Below are tokens > which I got for calling client and after token exchange in my test > application. It has a bit more complex structure than I described before. > It is: > > user —> jsp-web-app —> docs-svc > —> facade-svc —> svc-1 > —> svc-2 > > Token exchange happens when facade-svc calls svc-2. Below are two tokens: > > 1. First is a token which is used to call from jsp-web-app to > facade-svc > 2. Second is a token which I have after token exchange in facade-svc > to call svc-2. > > > For this test I configured facade-svc so that it cannot call ’svc-2’ at > all (svc-2 is absent in Scope and Client Scope tabs). But after token > exchange ’svc-2’ is successfully called. Note, how wide scope, roles and > audience of the exchanged token are. facade-svc is only allowed to call ’ > svc-1’. Also, in the exchanged token I see audiences and scopes which > were not present in the original caller’s token. > > { > "jti": "863d8801-dd28-4314-8b50-4ddefe97c380", > "exp": 1551344900, > "nbf": 0, > "iat": 1551344600, > "iss": "http://localhost:8180/auth/realms/DTGOpenIDDemoApp", > "aud": [ > "facade-svc", > "docs-svc" > ], > "sub": "6d312ba3-aa9e-4646-af57-95a9e965b8a9", > "typ": "Bearer", > "azp": "jsp-web-app", > "auth_time": 1551343339, > "session_state": "3606845e-9f85-4dc7-8edb-41ce3ab67268", > "acr": "0", > "allowed-origins": [ > "http://localhost:8080" > ], > "resource_access": { > "facade-svc": { > "roles": [ > "user" > ] > }, > "docs-svc": { > "roles": [ > "user" > ] > } > }, > "scope": "openid profile email", > "email_verified": false, > "organization": "Org-1", > "preferred_username": "user" > } > > > { > "jti": "cef6ae27-0e98-491d-9ef2-69850b664766", > "exp": 1551341466, > "nbf": 0, > "iat": 1551341166, > "iss": "http://localhost:8180/auth/realms/DTGOpenIDDemoApp", > "aud": [ > "facade-svc", > "docs-svc", > "account", > "svc-2" > ], > "sub": "6d312ba3-aa9e-4646-af57-95a9e965b8a9", > "typ": "Bearer", > "azp": "facade-svc", > "auth_time": 1551341150, > "session_state": "dcfa21cc-57a2-4302-a459-d772b5f79f13", > "acr": "1", > "realm_access": { > "roles": [ > "offline_access", > "uma_authorization", > "user" > ] > }, > "resource_access": { > "facade-svc": { > "roles": [ > "user" > ] > }, > "docs-svc": { > "roles": [ > "user" > ] > }, > "account": { > "roles": [ > "manage-account", > "manage-account-links", > "view-profile" > ] > }, > "svc-2": { > "roles": [ > "user" > ] > } > }, > "scope": "openid profile email", > "email_verified": false, > "preferred_username": "user" > } > > > > > > > On 27 Feb 2019, at 19:22, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > IIRC, you can use a scope parameter when doing a token exchange. Other > aspects could be managed by setting up client scopes to your client > applications, did you try that ? > > On Wed, Feb 27, 2019 at 12:59 PM Alexey Titorenko < > titorenko(a)dtg.technology&gt; wrote: > >> Hi Pedro! >> >> Thank you for answer! >> >> I’m would like to be able to control all aspects: audience, scope and >> roles. >> >> Today I also found that exchanged token may contain more roles than it >> is defined through on Scope tab for svc-1, if caller has some additional >> roles. So, after token echange svc-1 can have more rights than it would be >> possible without token exchange. >> >> >> Alexey. >> >> On 27 Feb 2019, at 18:50, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: >> >> Hi, >> >> The token exchange should be the right tool. Are you trying to downgrade >> scopes or just remove the client roles that are not related with svc-2 ? >> >> Regards. >> Pedro Igor >> >> On Tue, Feb 26, 2019 at 5:33 AM Alexey Titorenko < >> titorenko(a)dtg.technology&gt; wrote: >> >>> Hello guys. >>> >>> I would like to ask you help with the following. I’m currently looking >>> at on-behalf-of scenario with Keycloak. In this case we have ‘web app’ >>> calling ’svc-1’, which in turn calls another service ‘svc-2’. That is, we >>> have: web —> svc-1 —> svc-2. >>> >>> The idea is to let svc-2 know who is actual initiator of the call chain >>> (end-to-end identity propagation). The question is about how to do that >>> with Keycloak. >>> >>> First, in order to propagate caller identity we could exchange tokens >>> in ‘svc-1’. In this case we can have correct audience and, thus, control >>> token usage. Second, we need is to remove any excessive permissions (client >>> roles) that are not related to ‘svc-2’ call in order to reduce potential >>> harm in case this token is intercepted by someone. >>> >>> And if I know how to exchange tokens, I cannot find how to downgrade >>> the token during the exchange. As I see in documentation, ‘scope’ parameter >>> is not supported for token exchange. >>> >>> >>> So, my questions are: >>> Is token exchange a right tool for this task? >>> Is it possible to downgrade exchanged token? And how, if so? >>> >>> >>> Thank you, >>> Alexey >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >