Can we also validate these certificates using CRLs and OSCP endpoints provided in certificate ?. Also better if this validation can be made optional and can be governed through a configuration. This configuration will just be a handler property.
*@Indunil : *Do we have this feature bundled in product (Certificate validation using OSCP and CRL) ? On Fri, Feb 9, 2018 at 12:20 PM, Sathya Bandara <[email protected]> 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. > > > 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> > > -- Hasintha Indrajee WSO2, Inc. Mobile:+94 771892453
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
