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. 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. 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>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
