For option 1, it seems validating the DN of the received certificate against the one which we have stored for the service provider is enough. For option 2 we can validate the public key of the certificate which is received, against the public key of the certificate we store for the SP. AFAIU this should be fine. We don't need to worry about validating certificate since it happens in the container level AFAIK. But we may need to call to CRL and OCSP endpoints and validate the certificate. Again this is an improvement and should be optional.
On Wed, Feb 21, 2018 at 11:25 AM, Johann Nallathamby <joh...@wso2.com> wrote: > Hi Sathya, > > On Fri, Feb 9, 2018 at 7:50 AM, Sathya Bandara <sat...@wso2.com> wrote: > >> Hi all, >> >> Mutual TLS is a widely used, secure, authentication technique in >> enterprise environments to ensure the authenticity of the clients to server >> and vice versa. It facilitates authentication via certificates followed by >> the establishment of an encrypted channel between the parties. >> >> The OAuth 2.0 Authorization Framework allows the use of additional client >> authentication mechanisms. One such is the mechanism of client >> authentication utilizing mutual TLS certificate-based authentication [1]. >> We can add this support for WSO2 Identity Server by providing an additional >> OAuth client authenticator. In order to utilize TLS for OAuth client >> authentication, the TLS connection between the client and the authorization >> server must have been established with mutual X.509 certificate >> authentication (i.e. the Client Certificate and Certificate Verify messages >> are sent during the TLS Handshake). >> >> >> The specification defines two ways of binding a certificate to a client >> as two distinct client authentication methods [2]. >> 1. PKI Mutual TLS OAuth Client Authentication Method >> >> Uses a subject distinguished name (DN) and validated certificate chain to >> identify the client. The client is successfully authenticated if the subject >> information in the certificate matches the expected DN configured or >> registered for that >> particular client. >> >> 2. Self-Signed Certificate Mutual TLS OAuth Client Authentication Method >> Mutual >> >> support client authentication using self-signed certificates. As >> pre-requisite, the client registers an X.509 certificate or a trusted >> source for its X.509 certificates (such as the "jwks_uri"). The client is >> successfully authenticated, if the subject public key info of the >> certificate matches the subject public key info of one of the certificates >> configured or registered for that particular client. >> >> In both approaches, TLS is utilized to validate the client's possession >> of the private key corresponding to the public key presented within the >> certificate in the respective TLS handshake during authentication. >> >> We will follow the approach #2 since it prevents the necessity to >> validate the certificate chain in contrast to the PKI method. >> > > Validating the certificate chain and having only the root certificate in > the truststore is considered a more scalable architecture rather than > configuring individual self-signed certs for each service provider. > > Isn't validation of the chain anyway happening at the container level? Do > we have to anything in our code apart from verifying the DN with the > client? I couldn't understand what is the difficulty in supporting option 1? > > >> >> Also since the client cert authentication happens as part of the mutual >> TLS handshake, it will happen at the web container level. Hence if the >> authentication is successful, client's public certificate will be available >> as a request attribute at the CXF servlet. Hence the Mutual TLS Client >> Authenticator can be engaged by inferring the existence of the client cert >> as a request attribute. >> >> As we currently have the capability to upload Service Provider specific >> public certificates, clients can register their public certificates during >> service provider configuration. Within the authenticate method of the >> MutualTLSClientAuthenticator, we can compare the registered certificate's >> public key against the public key of the certificate presented in the TLS >> handshake. If these two matches we can successfully authenticate the >> client. >> > > This can be used to support option 2 above. So as I understand we can > support both options easily from a UX PoV. What am I missing? > > Regards, > Johann. > > >> For all requests to the authorization server utilizing mutual TLS client >> authentication, the client MUST include the "client_id" parameter as >> described in OAuth 2.0 specification [3]. With the "client_id" parameter we >> can easily obtain the client's registered certificate for authenticating >> the client. >> >> Highly appreciate your thoughts and suggestions. >> >> [1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 >> [2] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1 >> [3] https://tools.ietf.org/html/rfc6749#section-2.2 >> >> Thanks, >> Sathya >> >> -- >> Sathya Bandara >> Software Engineer >> WSO2 Inc. http://wso2.com >> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >> >> > > > -- > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile: *+94 77 7776950* > LinkedIn: *http://www.linkedin.com/in/johann-nallathamby > <http://www.linkedin.com/in/johann-nallathamby>* > Medium: *https://medium.com/@johann_nallathamby > <https://medium.com/@johann_nallathamby>* > Twitter: *@dj_nallaa* > -- Hasintha Indrajee WSO2, Inc. Mobile:+94 771892453
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
