Hello, Thank you for your comments. 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.

As for existing Key Provider, I've already implemented ECDSA Key Provider (for only signing) in this PR. Therefore, I could contribute it. As for Token Signature SPI, I agree with you. I hope I would like to implement this SPI's provider for ES256 at first and PS256 in the future. I think it is the best way that keycloak's core committers design and implement this Token Signature SPI. However, if they do not have yet such a plan to do that at this time and in the future, I would like to give some ideas on Token Signature SPI. How do you think about that?

Best regards, Takashi Norimatsu Hitachi Ltd., From: Stian Thorgersen <sthorger(a)redhat.com&gt; Sent: Tuesday, May 29, 2018 4:40 PM To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com&gt; Cc: keycloak-dev(a)lists.jboss.org Subject: [!]Re: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing Hi, I haven't had time to look at your PR in detail yet, but the way it should work is: * We need to add a Token Signature SPI that can sign and validate token signatures * RSA signing should be refactored into a Token Signature provider * Realm should have a default signing algorithm. Admin console should allow admins to select from any supported algorithm by listing TokenSignatureSPI providers * Clients should be able to override the signing algorithm * When verifying signatures in the Keycloak server we should check what the method is for the client (or realm if client doesn't override) and only allow that specific algorithm and nothing else * We may want to consider adding an option to client adapters to specify the expected signing algorithm as well * We also need additional key providers. It looks like you've already added this * We need to make sure that keys are only used for the correct purpose (correct algorithm and if it's for signing or encrypting). I think this is already covered though On 25 May 2018 at 05:26, 乗松隆志 / NORIMATSU，TAKASHI <mailto: takashi.norimatsu.ws(a)hitachi.com&gt; wrote: I'd like to use more secure JWS signature algorithm in the environment where the high security level is required such as the financial industry. According to the following RFCs, RSASSA-PSS to which PS256 follows is recommended on behalf of RSASSA-PKCS1-v1_5 to which RS256 follows. https://clicktime.symantec.com/a/1/fIIShrle28DIlWvWduZOOVGDLk3xC_ -rnn6V7E4iCwU=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYH m1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1L qudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7Tu Rlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj- ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimq TmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL24 8j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_ uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u= https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3447%23section-8 However, according to the following RFC, ES256 is "Recommended+" while PS256 is "Optional". https://clicktime.symantec.com/a/1/s_2w8zdHH2DoCkMCU7h9NMxUrcVZyNji GxV6Meq8vTM=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYH m1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1L qudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7Tu Rlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj- ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimq TmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL24 8j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_ uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u= https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7518%23section-3.1 Moreover, it is said that Elliptic Curve based algorithms have an advantage against RSA base algorithms in volume of its computation. Therefore, I've tried to make keycloak support ES256 JWS signature along with existing RS256 one. I've found that it seemed to be relatively easy to implement software components for ES256 JWS signature such as Signature Provider and Key Provider. However, it seemed to be difficult to implement codes actually calling these providers. The reasons is as follows. * a lot of places have called these singing and verifying providers. * such the places have been hard-coded in RSA algorithm specific. To deal with them, the following ideas have hit on me 1. replace RSA algorithm specific codes with signature algorithm independent codes. 2. re-design JWS signing and verifying scheme on high level. I'm not familiar with keycloak internals, so I've implemented ES256 JWS signature support on #1 basis experimentally. I'm not sure whether this way is appropriate or not. I'm very happy if keycloak specialists consider #2 or review my implementation based on #1. I've issued PR as WIP. Please refer to the following in detail. https://clicktime.symantec.com/a/1/G-XuERmswRIcQ_ MQA72oK1EJuT0Y48iac1LbbsWkrOU=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYH m1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1L qudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7Tu Rlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj- ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimq TmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL24 8j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_ uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u= https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F5225 Best regards, Takashi Norimatsu Hitachi Ltd., _______________________________________________ keycloak-dev mailing list mailto:keycloak-dev@lists.jboss.org https://clicktime.symantec.com/a/1/LBlgE63-JxZCbiegUCPqUTy7Oeq2A8tzZfOiWv p-KfM=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYH m1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1L qudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7Tu Rlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj- ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimq TmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL24 8j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_ uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u= https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev

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

+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.

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.

[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&gt; 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 >

On 28/06/18 10:12, Stian Thorgersen wrote: On Wed, 27 Jun 2018 at 09:31, Marek Posolda <mposolda(a)redhat.com&gt; 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&gt; 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 >> > > >