[keycloak-dev] Encrypted OIDC ID Tokens support and admin console

[Stian Thorgersen]

I would do Keys and rename saml keys to keys.

On Wed, 5 Jun 2019, 15:27 Marek Posolda, <mposolda at redhat.com> wrote:

> Thanks everyone for the feedback. Created
> https://issues.jboss.org/browse/KEYCLOAK-10462 as a follow-up JIRA on the
> initial OIDC encryption support JIRA KEYCLOAK-6768
>
> Not sure if it is better to have "OIDC Keys" or "Keys" . For the SAML
> clients, we have tab "SAML Keys" . On the other hand, at the realm level we
> have tab called "Keys"... IMO any of those two is acceptable.
>
> Marek
>
> On 05/06/2019 14:31, Stian Thorgersen wrote:
>
> +1 I also like the idea of OIDC keys, or perhaps it should just be called
> keys?
>
> +1 to separate pr as well
>
> On Wed, 5 Jun 2019, 09:21 乗松隆志 / NORIMATSU，TAKASHI, <
> takashi.norimatsu.ws at hitachi.com> wrote:
>
>> Hello,
>>
>> I think it is a good idea to have "OIDC keys" feature.
>>
>> When I wrote the PR for Support signature algorithm PS256/384/512 for
>> tokens and request object (https://github.com/keycloak/keycloak/pull/5974),
>> I encountered this matter.
>>
>> "OIDC keys" feature might be beneficial for the clients using JWS Client
>> Assertion (Signed JWT) as their authentication with signature algorithm
>> other than RS256 (e.g. ES256).
>>
>> I think this "OIDC keys" feature be realized as the separate PR because
>> the PR for ID Token Encryption is independent of how to load the client
>> public key.
>>
>> Takashi Norimatsu
>> Hitachi, Ltd.
>>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org <
>> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Marek Posolda
>> Sent: Friday, May 31, 2019 4:31 PM
>> To: keycloak-dev at lists.jboss.org
>> Subject: [!][keycloak-dev] Encrypted OIDC ID Tokens support and admin
>> console
>>
>> We have PR for introducing encryption support for OIDC ID Tokens. See [1]
>> and [2].
>>
>> IMO The PR is great contribution and is quite complete. There is support
>> for manage encryption keys through the REST API or through the OIDC client
>> registration, which is probably sufficient for have the OIDC FAPI support
>> happy. However one thing, which seems to be missing, is better admin
>> console support for seeing and managing the encryption keys of the client.
>>
>> Regarding the admin console, the PR just introduces 2 new options for the
>> client for choosing the algorithms for encryption of ID Tokens.
>>
>> For more details, admin console doesn't have support for "hardcode" the
>> client encryption key/certificate. It has support for downloading the key
>> from the client's JWKS URL, but the JWKS URL is configured on the bit
>> strange place. Right now, it is configured under tab "Credentials", then
>> you need to choose "Signed-JWT" and then you can configure the JWKS URL.
>> This was OK, when only point of JWKS URL was used just for signed-jwt
>> client authentication. But now with adding the encrypted ID tokens support,
>> this is not very appropriate place IMO. For example if you want to use
>> encrypted ID Tokens together with traditional client authentication based
>> on clientId/clientSecret, you shouldn't be required to go to "Credentials
>> -> Signed JWT Authenticator" at all.
>>
>> So not sure, if we shoud do some small re-design of admin console now?
>> For example, for SAML clients, there is tab "SAML Keys" where you can
>> see/generate/import/export keys used for SAML. I can imagine something like
>> that for OIDC clients too. We can introduce tab "OIDC Keys" or just "Keys"
>> . That will allow to have switch "Use JWKS URL" and then configure JWKS URL
>> (optional) or alternatively the client keys used for SIG and ENC, which
>> will be required just if "Use JWKS URL" is OFF similarly like it is
>> currently in the "Credentials -> Signed JWT". Then in the tab "Credentials
>> -> Signed JWT", there will be just info that you need to configure JWKS URL
>> or Signing key in the tab "Keys" - so no configuration options on this
>> page. Similarly the tooltips for the new options for ID Token support will
>> contain the tooltip, that you should configure JWKS URL or "hardcode"
>> encryption key in the tab "Keys" .
>>
>> The bonus point will be the possibility to view the keys downloaded from
>> JWKS URL and the ability to invalidate the keys of the individual client
>> from the cache (currently it's possible to invalidate just globally for the
>> whole realm AFAIK).
>>
>> TBH I am not sure whether to add admin console support in this PR or have
>> the follow-up PR.
>>
>> WDYT?
>>
>> [1]
>> https://clicktime.symantec.com/3VyqBz5ZQQnkb2zESQe6atT7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-6768
>> [2]
>> https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F5779
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>>
>> https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>