2:30 a.m.
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://issues.jboss.org/browse/KEYCLOAK-6768
[2] https://github.com/keycloak/keycloak/pull/5779
Marek
2:18 a.m.
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(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org> On
Behalf Of Marek Posolda
Sent: Friday, May 31, 2019 4:31 PM
To: keycloak-dev(a)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%2...
[2]
https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2...
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?u=https%3A%2F%2...
7:31 a.m.
+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(a)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(a)lists.jboss.org <
keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Marek Posolda
Sent: Friday, May 31, 2019 4:31 PM
To: keycloak-dev(a)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%2...
[2]
https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2...
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?u=https%3A%2F%2...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:27 a.m.
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(a)hitachi.com
<mailto:takashi.norimatsu.ws@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(a)lists.jboss.org
<mailto:keycloak-dev-bounces@lists.jboss.org>
<keycloak-dev-bounces(a)lists.jboss.org
<mailto:keycloak-dev-bounces@lists.jboss.org>> On Behalf Of Marek
Posolda
Sent: Friday, May 31, 2019 4:31 PM
To: keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@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%2...
[2]
https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2...
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?u=https%3A%2F%2...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:37 a.m.
I would do Keys and rename saml keys to keys.
On Wed, 5 Jun 2019, 15:27 Marek Posolda, <mposolda(a)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(a)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(a)lists.jboss.org <
> keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Marek Posolda
> Sent: Friday, May 31, 2019 4:31 PM
> To: keycloak-dev(a)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%2...
> [2]
>
https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2...
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
>
https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?u=https%3A%2F%2...
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
2032
days inactive
2037
days old
4 comments
3 participants
participants (3)
-
Marek Posolda -
Stian Thorgersen -
乗松隆志 / NORIMATSU，TAKASHI