3:12 a.m.
On Wed, 27 Jun 2018 at 09:31, Marek Posolda <mposolda(a)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.
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> 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
>