9:13 a.m.
On 28/06/18 10:12, Stian Thorgersen wrote:
On Wed, 27 Jun 2018 at 09:31, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
+1
Having the configuration in adapter (keycloak.json) won't scale
also because REST services (bearer-only clients) will need to
verify signatures by "frontend" clients, but each frontend client
can use different algorithm to sign it's token. So keycloak.json
of bearer-only clients would need to have some configuration map
to track all of this... Also "rotation" of algorithms will be
impossible (if administrator changes the algorithm for client in
admin console, the adapter configuration in keycloak.json will
need to be updated and hence application restarted...)
But I think we don't need to add any new endpoint, but just re-use
existing client registration endpoints for that? OIDC Client
registration has various metadata for clients like
id_token_signed_response_alg, id_token_encrypted_response_alg,
userinfo_signed_response_alg etc. See [1]. Also we have support
for Dynamic client registration management [2], so client
applications are able to "download" the client's metadata from the
endpoint.
I wasn't thinking adding a new endpoint. We should use OIDC well-known
endpoint. However, that doesn't include any attributes for the access
token, only ID token. Which is of course due to the fact that the
access token is opaque in OIDC. We could for instance add
"access_token_signed_response_alg".
Clients would by default check the OIDC well-known endpoint for what
algorithm to use, but it should also be possible to override in
keycloak.json as that OIDC well-known would say the realm default, but
we want to be able to override the algorithm for individual clients.
IMO OIDC
well-known endpoint is not good for that. It's not the endpoint
to be useful for retrieve metadata of specific client, rather it's
global for a realm. Even for ID token, there is not single signature
algorithm. There is just list of supported algorithms in
id_token_signing_alg_values_supported .
I wonder that for our adapters, we can just use the Client Registration
(Management) endpoint of our own representation - the endpoint of
DefaultClientRegistrationProvider.getDefault() . That's our own rep, so
we are fine to return the accessToken signature algorithm. We can ensure
that algorithm is always returned (We will return client specific
algorithm or fallback to realm default algorithm if client doesn't have
one set). We can invoke that endpoint with the bearer-token, which
adapter will always have - it can just use the token it wants to verify
signature for. Any reason why it won't work?
I wouldn't add anything to keycloak.json. IMO it would suck because:
- If algorithm is changed by admin in KC admin console, adapter will
need to be re-configured in keycloak.json and restarted (no automatic
algorithm "rotation" support)
- Configuration of algorithm will be duplicated on both adapter and server
- Bearer-only clients can be invoked with tokens of various "frontend"
clients signed by various different algorithms. So the configuration in
keycloak.json would be quite complicated here.
Marek
The specification enforces that requests are authenticated by
Client Registration Access Token. But ATM we also support
authentication by bearer tokens, which is great. When application
sees the bearer token signed/encrypted by unknown algorithm, it
can send the request to KC registration/management endpoint of
particular client to download the client's metadata. This will
work fine also for bearer-only clients. The bearer-only client can
parse the token and send the request to the
registration/management endpoint of particular "frontend" client
the token was issued for to determine the right algorithms etc.
Same as well-known. Dynamic client registration metadata from OIDC
doesn't specify anything for access token sign algorithm. So we would
have to add our own.
[1]
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
[2] https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05
Marek
On 26/06/18 18:25, Stian Thorgersen wrote:
> I don't really like the idea of having to reconfigure to make the
> adapter accept new signature. I know oidc well known endpoint
> doesn't have signature algorithm for access token, but we could
> add one and have adapters pull from the server what algorithms to
> accept.
>
> On Tue, 26 Jun 2018, 11:00 Marek Posolda, <mposolda(a)redhat.com
> <mailto:mposolda@redhat.com>> wrote:
>
> On 30/05/18 09:35, Stian Thorgersen wrote:
>>> I think it might be better to determine which kind of Token
Signature
>>> Provider be used by not parsing JWS, for example, looking up Client
or
>>> Realm settings.
>>> This PR might have impacts on keycloak's performance because it
has parsed
>>> JWS to determine it every time keycloak receives JWS Token.
>>>
>> On the server-side that is easy. On the adapter side that would probably
>> require adding a property to keycloak.json to set the algorithm. In
either
>> case it should probably default to RSA for existing realms at least, but
we
>> could consider setting it to ES256 for new realms.
>>
> +1
>
> Parsing token signature to determine algorithm should be
> avoided IMO. AFAIR Some OAuth/OIDC vendors had security
> issues in the past, that they parsed the header with "none"
> algorithm and then client applications automatically trust
> unsigned tokens. We should make sure this is not possible.
>
> Marek
>