[keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing
Stian Thorgersen
sthorger at redhat.com
Wed May 30 03:35:23 EDT 2018
On 30 May 2018 at 07:49, 乗松隆志 / NORIMATSU,TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:
> 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.
>
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.
>
> 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?
>
We don't currently have any plans on implementing this SPI and where
holding off on it until we started work on adding ES256. The ideal here may
be that someone from the core team work on the SPI and refactoring of RSA
provider, then you can update the PR for ES256. Unless you feel that you
may be able to contribute that as well? If so I would prefer a separate PR
for the SPI and refactoring.
>
> Best regards,
> Takashi Norimatsu
> Hitachi Ltd.,
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Sent: Tuesday, May 29, 2018 4:40 PM
> To: 乗松隆志 / NORIMATSU,TAKASHI <takashi.norimatsu.ws at hitachi.com>
> Cc: keycloak-dev at 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 at hitachi.com> 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 at 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
>
>
More information about the keycloak-dev
mailing list