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:
First is a token which is used to call from jsp-web-app to facade-svc
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>
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>
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
<mailto:psilva@redhat.com>> 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
<mailto:titorenko@dtg.technology>> 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 <mailto:keycloak-user@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
<
https://lists.jboss.org/mailman/listinfo/keycloak-user>