Hello Sebastian, I'm looking forward to your work, and I would be happy if I could make some contribution after finishing your work. Best regards, Takashi Norimatsu Hitachi Ltd., ---------- From: Sebastian Laskawiec <slaskawi at redhat.com> Sent: Thursday, July 26, 2018 5:24 PM To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws at hitachi.com> Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication Hey Takashi, Thanks a lot for the interest in contributing Keycloak! Sebi and I are working on this topic currently. We plan to reuse some bits of the User x509 Authentication and bring them to the client. We planned the implementation for this sprint, so it *should* be ready in ~3 weeks. More comments inlined. Thanks, Sebastian On Thu, Jul 26, 2018 at 1:23 AM 乗松隆志 / NORIMATSU，TAKASHI < takashi.norimatsu.ws at hitachi.com> wrote: Hello, As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who currently implements OAuth 2.0 Mutual TLS Client Authentication defined in https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ? We also have additional requirement - allow to authenticate client without "client_id" being sent (we need to extract it from the Certificate obtained during TLS Handshake). This is required for OpenShift integration. If no one does it, I would like to try to implement this feature. What do you think about it ? Also, In https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2, two types of OAuth 2.0 Mutual TLS Client Authentication are defined, for PKI and for Self-Signed Certificate. I would be happy if you who are interested in this feature tell me which you like better. As far as I know, we won't be touching self-registering clients. So maybe once we are done (let's assume that will happen in ~3 weeks), you could take it over and look into that? BTW, as for now, we will be implementing everything in this branch: https://github.com/sebastienblanc/keycloak/tree/client-x509 (currently, it contains an empty Authenticator but we will be adding bits and pieces to it). Best regards, Takashi Norimatsu Hitachi Ltd., _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Thanks Takashi, this is really useful information. Some comments inline On Mon, Jul 30, 2018 at 2:40 AM, 乗松隆志 / NORIMATSU，TAKASHI < takashi.norimatsu.ws(a)hitachi.com&gt; wrote: > Hello Sebastien, > > I've read the ticket you mentioned: https://issues.jboss.org/ > browse/KEYCLOAK-7635 > > I'm not sure what the token review endpoint is (similar to RFC 7662 OAuth > 2.0 Token Introspection?), but I inferred the following situation. > * OpenShift accesses keycloak's token review endpoint with some token, but > without client_id query parameter or client_id encoded Authorization > header. Therefore, keycloak cannot conduct client authentication. In this > situation, a client certificate might be used for client authentication in > the context of OAuth 2.0. > > Also, I'm not sure how to enclose client_id or client_id identifiable > information onto a client certificate and extract it. So I would like to > comment on other aspects other that it. > > - register client dn > According to 2.1.2. Client Registration Metadata of OAuth 2.0 Mutual TLS > Client Authentication and Certificate Bound Access Tokens ( > https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#section-2.1.2), each > client has "tls_client_auth_subject_dn" metadata parameter's value. This > has already been mentioned by @mposolda in https://issues.jboss.org/ > browse/KEYCLOAK-7512 > > In keycloak, OIDCClientRepresentation defines these OIDC Dynamic client > registration properties. > > OIDCAdvancedConfigWrapper can be used to convert these properties onto > attributes of the client model. > > DescriptionConverter can be used to convert internal representation of the > client onto external one (through OIDC Dynamic client registration) and > vice versa. > > IMO, at least, those three classes have to be modified to support this new > OIDC Client Registration property "tls_client_auth_subject_dn". > This is a nice complement to what Marek said in the ticket and makes thing clearer for me as well. But this would mean that Openshift should use dynamic client registration to make this flow works ?

> - extract client certificate > > X509ClientCertificateLookup : > https://github.com/keycloak/keycloak/blob/master/services/ > src/main/java/org/keycloak/services/x509/X509ClientCertificateLookup.java > This Client Certificate Lookup provider can be used to leverage the > feature supporting reverse proxy deployed environment mentioned in the > server admin manual (https://www.keycloak.org/docs/latest/server_admin/ > index.html#client-certificate-lookup) . > > You can consult > https://github.com/keycloak/keycloak/blob/master/services/ > src/main/java/org/keycloak/authentication/authenticators/x509/ > AbstractX509ClientCertificateAuthenticator.java#L196 > to get how to use this client certificate lookup feature. > > In order to use it, KeycloakSession and HttpRequest instances are required > to find the Client Certificate Lookup provider implementation. > > I've found that current ClientAuthenticator can get it by > ClientAuthenticationFlowContext.getSession() and .getHttpRequest() in > ClientAuthenticator.authenticateClient(ClientAuthenticationFlowContext > context). > Yes, I started to test that, exactly with this classes and methods but until now I fail to retrieve any certificate (probably because of my local setup/configuration). > - server side metadata advertisement > > OIDCConfigurationRepresentation is a server side metadata representation > and might be related to 2.1.1. PKI Authentication Method Metadata Value of > OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access > Tokens (https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#section-2.1.1 > ) > > Best regards, > Takashi Norimatsu > Hitachi Ltd., > > ---------- > From: Sebastien Blanc <sblanc(a)redhat.com&gt; > Sent: Friday, July 27, 2018 4:31 PM > To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com&gt; > Cc: Sebastian Laskawiec <slaskawi(a)redhat.com>; > keycloak-dev(a)lists.jboss.org > Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication > > Hi Takashi ! > > You can even help before if you want to :) > > The ticket is here : https://issues.jboss.org/browse/KEYCLOAK-7635 > > I created an "empty" X509ClientAuthenticator" branch here : > https://github.com/sebastienblanc/keycloak/tree/client-x509 > > And I'm investigating what we can reuse from this pacakge : > https://github.com/keycloak/keycloak/tree/master/services/ > src/main/java/org/keycloak/authentication/authenticators/x509 > > Any feedback, help, advise is welcome ! > > Sebi > > > On Fri, Jul 27, 2018 at 3:22 AM, 乗松隆志 / NORIMATSU，TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > >> Hello Sebastian, >> >> I'm looking forward to your work, and I would be happy if I could make >> some contribution after finishing your work. >> >> Best regards, >> Takashi Norimatsu >> Hitachi Ltd., >> >> ---------- >> From: Sebastian Laskawiec <slaskawi at redhat.com> >> Sent: Thursday, July 26, 2018 5:24 PM >> To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws at hitachi.com> >> Cc: keycloak-dev at lists.jboss.org >> Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication >> >> Hey Takashi, >> >> Thanks a lot for the interest in contributing Keycloak! >> >> Sebi and I are working on this topic currently. We plan to reuse some > bits >> of the User x509 Authentication and bring them to the client. We planned >> the implementation for this sprint, so it *should* be ready in ~3 weeks. >> >> More comments inlined. >> >> Thanks, >> Sebastian >> On Thu, Jul 26, 2018 at 1:23 AM 乗松隆志 / NORIMATSU，TAKASHI < >> takashi.norimatsu.ws at hitachi.com> wrote: >> Hello, >> >> As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and >> https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who >> currently implements OAuth 2.0 Mutual TLS Client Authentication defined > in >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ? >> >> We also have additional requirement - allow to authenticate client > without >> "client_id" being sent (we need to extract it from the Certificate > obtained >> during TLS Handshake). This is required for OpenShift integration. >> >> >> If no one does it, I would like to try to implement this feature. What do >> you think about it ? >> >> Also, In https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2, >> two types of OAuth 2.0 Mutual TLS Client Authentication are defined, for >> PKI and for Self-Signed Certificate. >> >> I would be happy if you who are interested in this feature tell me which >> you like better. >> >> As far as I know, we won't be touching self-registering clients. So maybe >> once we are done (let's assume that will happen in ~3 weeks), you could >> take it over and look into that? >> >> BTW, as for now, we will be implementing everything in this branch: >> https://github.com/sebastienblanc/keycloak/tree/client-x509 (currently, >> it contains an empty Authenticator but we will be adding bits and pieces > to >> it). >> >> >> Best regards, >> Takashi Norimatsu >> Hitachi Ltd., >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

So the first part , Client x509 Authentication is available here for review https://github.com/keycloak/keycloak/pull/5435 , the client_id will be lookup on the form data and the query parameters. And as Marek said I would like to follow up with another ticket for support of OIDC Dynamic Client Registration and the support of the `tls_client_auth_subject_dn`. Seb On Wed, Aug 1, 2018 at 2:43 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > On 30/07/18 09:20, Sebastien Blanc wrote: > >> Thanks Takashi, this is really useful information. Some comments inline >> >> On Mon, Jul 30, 2018 at 2:40 AM, 乗松隆志 / NORIMATSU，TAKASHI < >> takashi.norimatsu.ws(a)hitachi.com&gt; wrote: >> >> Hello Sebastien, >>> >>> I've read the ticket you mentioned: https://issues.jboss.org/ >>> browse/KEYCLOAK-7635 >>> >>> I'm not sure what the token review endpoint is (similar to RFC 7662 OAuth >>> 2.0 Token Introspection?), but I inferred the following situation. >>> * OpenShift accesses keycloak's token review endpoint with some token, >>> but >>> without client_id query parameter or client_id encoded Authorization >>> header. Therefore, keycloak cannot conduct client authentication. In this >>> situation, a client certificate might be used for client authentication >>> in >>> the context of OAuth 2.0. >>> >>> Also, I'm not sure how to enclose client_id or client_id identifiable >>> information onto a client certificate and extract it. So I would like to >>> comment on other aspects other that it. >>> >>> - register client dn >>> According to 2.1.2. Client Registration Metadata of OAuth 2.0 Mutual TLS >>> Client Authentication and Certificate Bound Access Tokens ( >>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#section-2.1.2), >>> each >>> client has "tls_client_auth_subject_dn" metadata parameter's value. This >>> has already been mentioned by @mposolda in https://issues.jboss.org/ >>> browse/KEYCLOAK-7512 >>> >>> In keycloak, OIDCClientRepresentation defines these OIDC Dynamic client >>> registration properties. >>> >>> OIDCAdvancedConfigWrapper can be used to convert these properties onto >>> attributes of the client model. >>> >>> DescriptionConverter can be used to convert internal representation of >>> the >>> client onto external one (through OIDC Dynamic client registration) and >>> vice versa. >>> >>> IMO, at least, those three classes have to be modified to support this >>> new >>> OIDC Client Registration property "tls_client_auth_subject_dn". >>> >>> This is a nice complement to what Marek said in the ticket and makes >> thing >> clearer for me as well. >> But this would mean that Openshift should use dynamic client registration >> to make this flow works ? >> > > Now I remember that few months ago, Bill implemented the support for > ClientStorage SPI. And I think he implemented it mainly because of > Openshift. It somehow allows to provision clients automatically from 3rd > party source (EG. from Openshift) without a need to manually > register/create them. So I guess (not 100% sure) that Openshift integration > will use this for client provisioning and it won't use dynamic client > registration. > > IMO using dynamic client registration will be more aligned with the OIDC > specs, but I guess we don't have a "power" to change the behaviour of > Openshift. Or do we? :-) > > But support for the OIDC Dynamic client registration, which Takashi > mentions, and which is mentioned in the specification, will be good to have > IMO even if it's not something directly useful for Openshift. If it's not > priority for you and Openshift integration, we can maybe at least create > some follow-up JIRA to add it later? > > Marek > >> >> - extract client certificate >>> >>> X509ClientCertificateLookup : >>> https://github.com/keycloak/keycloak/blob/master/services/ >>> src/main/java/org/keycloak/services/x509/X509ClientCertifica >>> teLookup.java >>> This Client Certificate Lookup provider can be used to leverage the >>> feature supporting reverse proxy deployed environment mentioned in the >>> server admin manual ( https://www.keycloak.org/docs/latest/server_admin/ >>> index.html#client-certificate-lookup) . >>> >>> You can consult >>> https://github.com/keycloak/keycloak/blob/master/services/ >>> src/main/java/org/keycloak/authentication/authenticators/x509/ >>> AbstractX509ClientCertificateAuthenticator.java#L196 >>> to get how to use this client certificate lookup feature. >>> >>> In order to use it, KeycloakSession and HttpRequest instances are >>> required >>> to find the Client Certificate Lookup provider implementation. >>> >>> I've found that current ClientAuthenticator can get it by >>> ClientAuthenticationFlowContext.getSession() and .getHttpRequest() in >>> ClientAuthenticator.authenticateClient(ClientAuthenticationFlowContext >>> context). >>> >>> Yes, I started to test that, exactly with this classes and methods but >> until now I fail to retrieve any certificate (probably because of my local >> setup/configuration). >> >> - server side metadata advertisement >>> >>> OIDCConfigurationRepresentation is a server side metadata representation >>> and might be related to 2.1.1. PKI Authentication Method Metadata Value >>> of >>> OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access >>> Tokens (https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#sectio >>> n-2.1.1 >>> ) >>> >>> Best regards, >>> Takashi Norimatsu >>> Hitachi Ltd., >>> >>> ---------- >>> From: Sebastien Blanc <sblanc(a)redhat.com&gt; >>> Sent: Friday, July 27, 2018 4:31 PM >>> To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com&gt; >>> Cc: Sebastian Laskawiec <slaskawi(a)redhat.com>; >>> keycloak-dev(a)lists.jboss.org >>> Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication >>> >>> Hi Takashi ! >>> >>> You can even help before if you want to :) >>> >>> The ticket is here : https://issues.jboss.org/browse/KEYCLOAK-7635 >>> >>> I created an "empty" X509ClientAuthenticator" branch here : >>> https://github.com/sebastienblanc/keycloak/tree/client-x509 >>> >>> And I'm investigating what we can reuse from this pacakge : >>> https://github.com/keycloak/keycloak/tree/master/services/ >>> src/main/java/org/keycloak/authentication/authenticators/x509 >>> >>> Any feedback, help, advise is welcome ! >>> >>> Sebi >>> >>> >>> On Fri, Jul 27, 2018 at 3:22 AM, 乗松隆志 / NORIMATSU，TAKASHI < >>> takashi.norimatsu.ws at hitachi.com> wrote: >>> >>> Hello Sebastian, >>>> >>>> I'm looking forward to your work, and I would be happy if I could make >>>> some contribution after finishing your work. >>>> >>>> Best regards, >>>> Takashi Norimatsu >>>> Hitachi Ltd., >>>> >>>> ---------- >>>> From: Sebastian Laskawiec <slaskawi at redhat.com> >>>> Sent: Thursday, July 26, 2018 5:24 PM >>>> To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws at hitachi.com> >>>> Cc: keycloak-dev at lists.jboss.org >>>> Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client >>>> Authentication >>>> >>>> Hey Takashi, >>>> >>>> Thanks a lot for the interest in contributing Keycloak! >>>> >>>> Sebi and I are working on this topic currently. We plan to reuse some >>>> >>> bits >>> >>>> of the User x509 Authentication and bring them to the client. We planned >>>> the implementation for this sprint, so it *should* be ready in ~3 weeks. >>>> >>>> More comments inlined. >>>> >>>> Thanks, >>>> Sebastian >>>> On Thu, Jul 26, 2018 at 1:23 AM 乗松隆志 / NORIMATSU，TAKASHI < >>>> takashi.norimatsu.ws at hitachi.com> wrote: >>>> Hello, >>>> >>>> As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and >>>> https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who >>>> currently implements OAuth 2.0 Mutual TLS Client Authentication defined >>>> >>> in >>> >>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ? >>>> >>>> We also have additional requirement - allow to authenticate client >>>> >>> without >>> >>>> "client_id" being sent (we need to extract it from the Certificate >>>> >>> obtained >>> >>>> during TLS Handshake). This is required for OpenShift integration. >>>> >>>> >>>> If no one does it, I would like to try to implement this feature. What >>>> do >>>> you think about it ? >>>> >>>> Also, In https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 >>>> , >>>> two types of OAuth 2.0 Mutual TLS Client Authentication are defined, for >>>> PKI and for Self-Signed Certificate. >>>> >>>> I would be happy if you who are interested in this feature tell me which >>>> you like better. >>>> >>>> As far as I know, we won't be touching self-registering clients. So >>>> maybe >>>> once we are done (let's assume that will happen in ~3 weeks), you could >>>> take it over and look into that? >>>> >>>> BTW, as for now, we will be implementing everything in this branch: >>>> https://github.com/sebastienblanc/keycloak/tree/client-x509 (currently, >>>> it contains an empty Authenticator but we will be adding bits and pieces >>>> >>> to >>> >>>> it). >>>> >>>> >>>> Best regards, >>>> Takashi Norimatsu >>>> Hitachi Ltd., >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hello Sebastian, I've read the follow-up JIRA ( https://issues.jboss.org/browse/KEYCLOAK-7997). It might be better to implement PKI Mutual TLS OAuth Client Authentication Method defined in the specification in https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#section-2.1 on your PR https://github.com/keycloak/keycloak/pull/5435 . Or, after your current PR is merged (namely, this PR is for OpenShift Integration), PKI Mutual TLS OAuth Client Authentication Method will be implemented over it.

Best regards, Takashi Norimatsu Hitachi Ltd., -----Original Message----- From: keycloak-dev-bounces(a)lists.jboss.org < keycloak-dev-bounces(a)lists.jboss.org&gt; On Behalf Of Sebastian Laskawiec Sent: Monday, August 06, 2018 6:12 PM To: Sebastien Blanc <sblanc(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication Hey Takashi, As the initial version is more or less done, I created a follow-up JIRA with dynamic client registration and Mutual TLS [1]. Perhaps you'd be interested in looking into it? Thanks, Sebastian [1] https://issues.jboss.org/browse/KEYCLOAK-7997 On Thu, Aug 2, 2018 at 2:45 PM Sebastien Blanc <sblanc at redhat.com> wrote: > So the first part , Client x509 Authentication is available here for review > https://github.com/keycloak/keycloak/pull/5435 , the client_id will be > lookup on the form data and the query parameters. > > And as Marek said I would like to follow up with another ticket for support > of OIDC Dynamic Client Registration and the support of the > `tls_client_auth_subject_dn`. > > Seb > > > On Wed, Aug 1, 2018 at 2:43 PM, Marek Posolda <mposolda at redhat.com> wrote: > > > On 30/07/18 09:20, Sebastien Blanc wrote: > > > >> Thanks Takashi, this is really useful information. Some comments inline > >> > >> On Mon, Jul 30, 2018 at 2:40 AM, 乗松隆志 / NORIMATSU，TAKASHI < > >> takashi.norimatsu.ws at hitachi.com> wrote: > >> > >> Hello Sebastien, > >>> > >>> I've read the ticket you mentioned: https://issues.jboss.org/ > >>> browse/KEYCLOAK-7635 > >>> > >>> I'm not sure what the token review endpoint is (similar to RFC 7662 > OAuth > >>> 2.0 Token Introspection?), but I inferred the following situation. > >>> * OpenShift accesses keycloak's token review endpoint with some token, > >>> but > >>> without client_id query parameter or client_id encoded Authorization > >>> header. Therefore, keycloak cannot conduct client authentication. In > this > >>> situation, a client certificate might be used for client authentication > >>> in > >>> the context of OAuth 2.0. > >>> > >>> Also, I'm not sure how to enclose client_id or client_id identifiable > >>> information onto a client certificate and extract it. So I would like > to > >>> comment on other aspects other that it. > >>> > >>> - register client dn > >>> According to 2.1.2. Client Registration Metadata of OAuth 2.0 Mutual > TLS > >>> Client Authentication and Certificate Bound Access Tokens ( > >>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#section-2.1.2), > >>> each > >>> client has "tls_client_auth_subject_dn" metadata parameter's value. > This > >>> has already been mentioned by @mposolda in https://issues.jboss.org/ > >>> browse/KEYCLOAK-7512 > >>> > >>> In keycloak, OIDCClientRepresentation defines these OIDC Dynamic client > >>> registration properties. > >>> > >>> OIDCAdvancedConfigWrapper can be used to convert these properties onto > >>> attributes of the client model. > >>> > >>> DescriptionConverter can be used to convert internal representation of > >>> the > >>> client onto external one (through OIDC Dynamic client registration) and > >>> vice versa. > >>> > >>> IMO, at least, those three classes have to be modified to support this > >>> new > >>> OIDC Client Registration property "tls_client_auth_subject_dn". > >>> > >>> This is a nice complement to what Marek said in the ticket and makes > >> thing > >> clearer for me as well. > >> But this would mean that Openshift should use dynamic client > registration > >> to make this flow works ? > >> > > > > Now I remember that few months ago, Bill implemented the support for > > ClientStorage SPI. And I think he implemented it mainly because of > > Openshift. It somehow allows to provision clients automatically from 3rd > > party source (EG. from Openshift) without a need to manually > > register/create them. So I guess (not 100% sure) that Openshift > integration > > will use this for client provisioning and it won't use dynamic client > > registration. > > > > IMO using dynamic client registration will be more aligned with the OIDC > > specs, but I guess we don't have a "power" to change the behaviour of > > Openshift. Or do we? :-) > > > > But support for the OIDC Dynamic client registration, which Takashi > > mentions, and which is mentioned in the specification, will be good to > have > > IMO even if it's not something directly useful for Openshift. If it's not > > priority for you and Openshift integration, we can maybe at least create > > some follow-up JIRA to add it later? > > > > Marek > > > >> > >> - extract client certificate > >>> > >>> X509ClientCertificateLookup : > >>> https://github.com/keycloak/keycloak/blob/master/services/ > >>> src/main/java/org/keycloak/services/x509/X509ClientCertifica > >>> teLookup.java > >>> This Client Certificate Lookup provider can be used to leverage the > >>> feature supporting reverse proxy deployed environment mentioned in the > >>> server admin manual ( > https://www.keycloak.org/docs/latest/server_admin/ > >>> index.html#client-certificate-lookup) . > >>> > >>> You can consult > >>> https://github.com/keycloak/keycloak/blob/master/services/ > >>> src/main/java/org/keycloak/authentication/authenticators/x509/ > >>> AbstractX509ClientCertificateAuthenticator.java#L196 > >>> to get how to use this client certificate lookup feature. > >>> > >>> In order to use it, KeycloakSession and HttpRequest instances are > >>> required > >>> to find the Client Certificate Lookup provider implementation. > >>> > >>> I've found that current ClientAuthenticator can get it by > >>> ClientAuthenticationFlowContext.getSession() and .getHttpRequest() in > >>> ClientAuthenticator.authenticateClient(ClientAuthenticationFlowContext > >>> context). > >>> > >>> Yes, I started to test that, exactly with this classes and methods but > >> until now I fail to retrieve any certificate (probably because of my > local > >> setup/configuration). > >> > >> - server side metadata advertisement > >>> > >>> OIDCConfigurationRepresentation is a server side metadata > representation > >>> and might be related to 2.1.1. PKI Authentication Method Metadata Value > >>> of > >>> OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access > >>> Tokens (https://tools.ietf.org/html/draft-ietf-oauth-mtls-10#sectio > >>> n-2.1.1 > >>> ) > >>> > >>> Best regards, > >>> Takashi Norimatsu > >>> Hitachi Ltd., > >>> > >>> ---------- > >>> From: Sebastien Blanc <sblanc at redhat.com> > >>> Sent: Friday, July 27, 2018 4:31 PM > >>> To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws at hitachi.com> > >>> Cc: Sebastian Laskawiec <slaskawi at redhat.com>; > >>> keycloak-dev at lists.jboss.org > >>> Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client > Authentication > >>> > >>> Hi Takashi ! > >>> > >>> You can even help before if you want to :) > >>> > >>> The ticket is here : https://issues.jboss.org/browse/KEYCLOAK-7635 > >>> > >>> I created an "empty" X509ClientAuthenticator" branch here : > >>> https://github.com/sebastienblanc/keycloak/tree/client-x509 > >>> > >>> And I'm investigating what we can reuse from this pacakge : > >>> https://github.com/keycloak/keycloak/tree/master/services/ > >>> src/main/java/org/keycloak/authentication/authenticators/x509 > >>> > >>> Any feedback, help, advise is welcome ! > >>> > >>> Sebi > >>> > >>> > >>> On Fri, Jul 27, 2018 at 3:22 AM, 乗松隆志 / NORIMATSU，TAKASHI < > >>> takashi.norimatsu.ws at hitachi.com> wrote: > >>> > >>> Hello Sebastian, > >>>> > >>>> I'm looking forward to your work, and I would be happy if I could make > >>>> some contribution after finishing your work. > >>>> > >>>> Best regards, > >>>> Takashi Norimatsu > >>>> Hitachi Ltd., > >>>> > >>>> ---------- > >>>> From: Sebastian Laskawiec <slaskawi at redhat.com> > >>>> Sent: Thursday, July 26, 2018 5:24 PM > >>>> To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws at hitachi.com> > >>>> Cc: keycloak-dev at lists.jboss.org > >>>> Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client > >>>> Authentication > >>>> > >>>> Hey Takashi, > >>>> > >>>> Thanks a lot for the interest in contributing Keycloak! > >>>> > >>>> Sebi and I are working on this topic currently. We plan to reuse some > >>>> > >>> bits > >>> > >>>> of the User x509 Authentication and bring them to the client. We > planned > >>>> the implementation for this sprint, so it *should* be ready in ~3 > weeks. > >>>> > >>>> More comments inlined. > >>>> > >>>> Thanks, > >>>> Sebastian > >>>> On Thu, Jul 26, 2018 at 1:23 AM 乗松隆志 / NORIMATSU，TAKASHI < > >>>> takashi.norimatsu.ws at hitachi.com> wrote: > >>>> Hello, > >>>> > >>>> As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and > >>>> https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who > >>>> currently implements OAuth 2.0 Mutual TLS Client Authentication > defined > >>>> > >>> in > >>> > >>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ? > >>>> > >>>> We also have additional requirement - allow to authenticate client > >>>> > >>> without > >>> > >>>> "client_id" being sent (we need to extract it from the Certificate > >>>> > >>> obtained > >>> > >>>> during TLS Handshake). This is required for OpenShift integration. > >>>> > >>>> > >>>> If no one does it, I would like to try to implement this feature. What > >>>> do > >>>> you think about it ? > >>>> > >>>> Also, In > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 > >>>> , > >>>> two types of OAuth 2.0 Mutual TLS Client Authentication are defined, > for > >>>> PKI and for Self-Signed Certificate. > >>>> > >>>> I would be happy if you who are interested in this feature tell me > which > >>>> you like better. > >>>> > >>>> As far as I know, we won't be touching self-registering clients. So > >>>> maybe > >>>> once we are done (let's assume that will happen in ~3 weeks), you > could > >>>> take it over and look into that? > >>>> > >>>> BTW, as for now, we will be implementing everything in this branch: > >>>> https://github.com/sebastienblanc/keycloak/tree/client-x509 > (currently, > >>>> it contains an empty Authenticator but we will be adding bits and > pieces > >>>> > >>> to > >>> > >>>> it). > >>>> > >>>> > >>>> Best regards, > >>>> Takashi Norimatsu > >>>> Hitachi Ltd., > >>>> > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> > >>>> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev