Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication

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