<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I think you can write custom protocol
mapper, which will change the value of audience in accessToken
according to your preferences. <br>
<br>
Some more comments/options inline...<br>
<br>
On 06/01/16 09:29, Erik Mulder wrote:<br>
</div>
<blockquote
cite="mid:9A5619B792BBA041AE094585791BB71C013B9D4BE4AD@DDPEX01.DDP.dcloud.local"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="moz-cite-prefix">Bump...<br>
Can anybody shed his light on this? Thanks!<br>
<br>
<br>
On 31/12/15 12:42, Erik Mulder wrote:<br>
</div>
<blockquote
cite="mid:9A5619B792BBA041AE094585791BB71C013B9D4BE4AC@DDPEX01.DDP.dcloud.local"
type="cite"> In the JWT token there is a field 'aud', or
audience, which function is to state for which client(s) that
token is intended.<br>
Currently (TokenManager:433) this is set to the client id:<br>
<tt><br>
token.audience(client.getClientId());</tt><tt><br>
</tt><br>
This seems fine in general, but we would like to have a token
with multiple entries in the audience field. This is possible
and an array value is even claimed to be the 'general case': <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://tools.ietf.org/html/rfc7519#section-4.1.3">
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc7519#section-4.1.3">https://tools.ietf.org/html/rfc7519#section-4.1.3</a></a> (where
one single value is the 'special case')<br>
<br>
Background is that we have a Keycloak running for a login of a
frontend that talks to multiple different resource servers. We'd
prefer to use one token for all of those resource servers. The
resource servers use Spring Security, which explicitly checks
that the 'name' you give to your Spring service is matched by (a
value of) the audience field of the JWT token. So now we have to
give all resource servers the same 'name', which doesn't feel
right.<br>
</blockquote>
</blockquote>
Isn't is possible to disable this checking in Spring security on
Resource server side? I think once you verify token signature and
issuer, you should be fine.<br>
<br>
Btv. Our adapters doesn't require that. You can have same resource
server (REST service etc), which allows to serve requests from
multiple different clients with different audiences in token. For
example see our demo where "customer-portal" and "product-portal"
are different clients, but they both access same REST service (
database.war ).<br>
<br>
So another option for you might be to migrate to use our adapters?
We even have Spring adapter.<br>
<blockquote
cite="mid:9A5619B792BBA041AE094585791BB71C013B9D4BE4AD@DDPEX01.DDP.dcloud.local"
type="cite">
<blockquote
cite="mid:9A5619B792BBA041AE094585791BB71C013B9D4BE4AC@DDPEX01.DDP.dcloud.local"
type="cite"> <br>
So we need some way to influence the value of the audience
field. This could be achieved by following this RFC: <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00">
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00">https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00</a></a>
which suggests to include a parameter to the request for the
token. But that RFC does not consider multiple values for the
audience. Another option would be to add an audience field in
the settings of a Client in Keycloak. Which would, if set,
define the audience field of the JWT token. This could be a
comma separated string value that would translate to a JSON
array. A question about this could be: 'then where to leave the
client id?'. As suggested by this: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://stackoverflow.com/questions/32013835/client-id-or-multiple-audiences-in-json-web-token">https://stackoverflow.com/questions/32013835/client-id-or-multiple-audiences-in-json-web-token</a>
the best place to put the client id is in the 'azp' field
(authorized party).<br>
</blockquote>
</blockquote>
Maybe we can add it, but can't promise at 100%... Feel free to
create JIRA. But IMO the audience field in client settings shouldn't
be mandatory and if it's not set, it will default to clientId like
it's now. This will be also backwards compatible.<br>
<br>
Marek<br>
<blockquote
cite="mid:9A5619B792BBA041AE094585791BB71C013B9D4BE4AD@DDPEX01.DDP.dcloud.local"
type="cite">
<blockquote
cite="mid:9A5619B792BBA041AE094585791BB71C013B9D4BE4AC@DDPEX01.DDP.dcloud.local"
type="cite"> <br>
Does the KeyCloak team see this as a valuable addition? Will it
be implemented somewhere in the future? Or can we make a pull
request ourselves that will be merged?<br>
<br>
Thanks, Erik<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>