[keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication

Thu Aug 2 08:41:59 EDT 2018

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