[keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication

Mon Aug 6 05:11:54 EDT 2018

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