Hi all,

Please find below, the technical approaches discussed apart from the UX
level improvements mentioned above.

With the improvement in [1] we have the capability to upload multiple
truststores to the Identity Server from the management console. These
truststores will be added to the registry. With this capability we can
maintain a separate trustore per the feature (mutual TLS).

When uploading certificates for mutual TLS authentication, we can ask the
client to upload the certificate to this specific truststore from
management console. In order overcome the limitation of tomcat caching the
certificate store, we can add another tomcat connector which will override
the existing tomcat-connector. We can specifically apply this connector to
the requests directed to the oauth endpoints. And to this connector we can
specify a custom dynamic trust manager and use it to re-load the truststore
on every SSL session. Basically we should have a registry based dynamic
trust manager to reload the certificates from the feature-specific
truststore.

We also have the option to generalize the dynamic trust manager provided in
[1] which was originally implemented for the components within IS that are
initiating SSL connections with external clients.

Since with the above approach we will have truststores per feature, we can
avoid the conflicts with the existing authenticators. e.g
MutualSSLAuthenticator, X509Authenticator. However we will need to manage a
reference of truststore against the feature id in a map.


[1] https://github.com/wso2/carbon-identity/pull/1511

Thanks,
Sathya.

On Wed, Feb 21, 2018 at 1:02 PM, Johann Nallathamby <joh...@wso2.com> wrote:

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



-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to