[keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication

Tue Aug 7 03:09:10 EDT 2018

On Tue, Aug 7, 2018 at 9:05 AM 乗松隆志 / NORIMATSU，TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

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

Yes, I would advocate for this approach. We need the first part for
OpenShift Integration whereas the second part (the dynamic client) is
optional in this context.

>
> Best regards,
> Takashi Norimatsu
> Hitachi Ltd.,
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org <
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Sebastian Laskawiec
> Sent: Monday, August 06, 2018 6:12 PM
> To: Sebastien Blanc <sblanc at redhat.com>
> Cc: keycloak-dev at 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
>