1:52 a.m.
Hello.
I've sent the PR for RFC7636 (PKCE) supporting implementation both server side and
client side (only for Servlet OAuth) along with arquillian test cases.
Besides, I'm now updating design documents. I'll report it after wrapping up
them.
I've found you are currently busy for preraring Keycloak 3.x. Hope you'll review
this PR afterward.
Best Regards
Takashi Norimatsu
Hitachi, Ltd.
----------
From: Stian Thorgersen [mailto:sthorger@redhat.com]
Sent: Tuesday, January 17, 2017 4:39 PM
To: 乗松隆志 / NORIMATSU，TAKASHI
Cc: keycloak-dev(a)lists.jboss.org
Subject: [!]Re: [keycloak-dev] Proposal of RFC7636 (PKCE) support
You can send the PR whenever it's ready from your POV and we'll review. FIY we
can't accept this until we start on Keycloak 3.x, but that should be fairly soon
(sometime in Feb probably).
On 17 January 2017 at 06:38, 乗松隆志 / NORIMATSU，TAKASHI
<takashi.norimatsu.ws(a)hitachi.com> wrote:
Thank you very much.
I'm now writing tests for the new testsuite(testsuite/integration-arquillian),
refining documents and codes for a PR.
After completing these tasks, hopefully in this week, I'd like to post mail to ask you
whether I can send a PR.
Best Regards
Takashi Norimatsu
Hitachi, Ltd.
We'd welcome a contribution.
Tests would need to be written and added to the new testsuite
(testsuite/integration-arquillian). If you are able to send updates to
documentation as well that'd be good.
On 13 January 2017 at 11:59, 乗松隆志 / NORIMATSU，TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:
> Hello.
>
> I've been using keycloak 2.4.0.FINAL.
> I've implemented codes for RFC 7636 for Proof Key Code Exchange
> experimentally.
> (https://tools.ietf.org/html/rfc7636)
>
> [Background: Why RFC7636 is necessary]
> RFC 7636 is important for industries where high level security is
> required because it can prevent Authorization Code Interception and
> Substitution attacks for OAuth2.0. For example, it is required for both
> confidential and public clients in draft specification of Financial API of
> OpenID foundation. By implementing RFC 7636, keycloak will be used more
> widely.
>
> [Description of the implementation]
> My implementation is about 90steps for Authorization Server, 90steps for
> Client(only Servlet-OAuth), both excluded debug log codes in step counts.
> Please see the detail in below links.
> * The implementation:
> https://github.com/keycloak/keycloak/commit/
> 9e3d2d1e5e8c3b30ddc9ccd5083ba18adcb4c564
> It is based on 2.4.0.FINAL. Hope we'll refine and rebase it onto master
> branch for PR if you accept our implementation proposal.
> * Design document:
> https://github.com/Hitachi/contributions/wiki/Description-of-RFC7636-for-
> keycloak
> * PoC test:
> I've validated my implementation and found worked well in following
> scenarios.
> [1]
> Flow: Authorization Code Flow
> Client: RFC 7636 not supported
> [2]
> Flow: Authorization Code Flow
> Client: RFC 7636 supported and operate properly
> [3]
> Flow: Authorization Code Flow
> Client: RFC 7636 supported but operate illegally
> (send invalid code_verifier to Token Endpoint)
> For detail of PoC test, please see:
> https://github.com/Hitachi/contributions/wiki/PoC-Test-Result-of-RFC7636
>
> I am also willing to add tests to community’s testsuites according to the
> process as described in “Hacking on Keycloak”.
>
> I've known that related ticket had already been issued as KEYCLOAK-2604.
> https://issues.jboss.org/browse/KEYCLOAK-2604
>
> Would you mind if I contribute this RFC 7636 support to Keycloak related
> with KEYCLOAK-2604 ticket ?
>
> Best Regards
> Takashi Norimatsu
> Hitachi, Ltd.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>