Had an offline discussion with Sathya. Following are the UX level features we need at high level. Sathya will reply with the technical approaches we discussed. We also discussed some possible solutions for the technical problems Sathya has raised above, which Sathya will explain.
Basically we should be able to support both options above mentioned by Sathya. *Option 1 - PKI Mutual TLS OAuth Client Authentication Method* This is important for large organizations with centralized governance where adding individual certs for service providers won't scale. Such organizations generally have an internal CA who issues certificates to all the clients. Therefore having the root CA in our trust store should be enough. However we need to validate the exact client of the request. We discussed following two options. 1. Organization can decide that all the certificates they are going to issue for this purpose will have the client_id as the CN. This will externally guarantee that the certificates sent by the clients are verified by a trusted 3rd party. 2. Register the expected CN/DN of the client when registering the OAuth2 client. If we are able to retrieve the client by the registered CN/DN, then we don't even need to send the client_id as an additional parameter. Otherwise we need to send the client_id parameter separately. Since the spec is not very concrete here both options should be fine. *Option 2 - Self-Signed Certificate Mutual TLS OAuth Client Authentication Method Mutual* Import the certificate for each service provider. Generally considered less scalable. But good to support for smaller organizations with less centralized governance. To identify the exact client, both options suggested above will work, but doesn't make a significant difference because we are anyway storing the entire certificate per service provider. As mentioned above for option 2, either we can lookup the client by CN/DN in the uploaded cert, or send the client_id as an additional parameter. CRL/OCSP can be easily supported now, because we have a service to do this. We just need to get the registered OSGi service and validate the certs. Shouldn't take anything more than a day to integrate this code ideally. Regards, Johann. On Wed, Feb 21, 2018 at 7:54 AM, Hasintha Indrajee <hasin...@wso2.com> wrote: > 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 <+94%2077%20189%202453> > > -- *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*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
