Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Sathya Bandara]

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  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 
> 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 
>> wrote:
>>
>>> Hi Sathya,
>>>
>>> On Fri, Feb 9, 2018 at 7:50 AM, Sathya Bandara  wrote:
>>>
 Hi all,

 Mutual TLS is a widely used, secure, authentication technique in
 enterprise environments to ensure the authenticity of the 

Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Johann Nallathamby]

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 
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 
> wrote:
>
>> Hi Sathya,
>>
>> On Fri, Feb 9, 2018 at 7:50 AM, Sathya Bandara  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 

Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Hasintha Indrajee]

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 
wrote:

> Hi Sathya,
>
> On Fri, Feb 9, 2018 at 7:50 AM, Sathya Bandara  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] 

Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Johann Nallathamby]

Hi Sathya,

On Fri, Feb 9, 2018 at 7:50 AM, Sathya Bandara  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
*
Medium: *https://medium.com/@johann_nallathamby
*
Twitter: *@dj_nallaa*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Sathya Bandara]

Hi all,

I'm currently working on integrating the changes in [1] to provide the
capability to upload client certificates to truststore during run time
without restart.

As per the implementation in [1] the default trust manager will be replaced
with a custom trust manager which will reload the client-truststore.jks
whenever there is a SSL validation failure. However in the case where there
are many SSL failures it will reload the JKS file for each and every
validation failure which will slow the server.

With the above mentioned concern, should I proceed with this integration?
Appreciate your thoughts.

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

Thanks,
Sathya


On Mon, Feb 19, 2018 at 3:57 PM, Sathya Bandara  wrote:

> Hi all,
>
> The basic implementation for this feature is completed and we held an
> initial code review for this. Review notes can be found in [1]. We were
> able to identify the following key limitations when including this feature
> in the product.
>
>
>1. In order to use the client certificate in the authentication
>request, the certificate needs to be imported to our truststore as a
>pre-requisite. As a result we will have to ask to restart the server. Even
>if we add the certificate via Management console it will not be applied
>unless the server is restarted with the current implementation. In order to
>overcome this requirement , we need to improve our existing implementation
>to add certificates at runtime without restarting the server. Part of this
>improvement is already provided in [1] which provides the following
>capabilities.
>
>- Alter UI to view the default trust store.
>   - Alter keystore management service to support the addition of
>   trust stores.
>   - Create a X509TrustManager implementation that dynamically reloads
>   any changes made to the trust store. Anyone using this
>   "DynamicX509TrustManager" with SSLContext will not require to restart 
> the
>   server for changes to client trust store to take effect.
>
>   2. Since in the current approach of mutual authentication using
>TLS, we need to add the client certificate to the cient-trustore.jks in
>order handle mutual TLS at at web container level (tomcat), during TLS
>handshake. In this scenario all the client certificates will be accessible
>globally since we cannot override the trustore at SP level. Since our admin
>services are protected by the Mutual-SSL-authenticator, clients can
>successfully authenticate from mutual SSL authenticator using their
>certificates and consume admin services. As a work-around we can
>specifically ask to disable the mutual-SSL-authenticator if the requirement
>is to use mutual TLS for client authentication. However, the proper
>solution would be to find an approach for the web container to dynamically
>identify the client specific certificates during runtime.
>
>3. Configuring the Tomcat connector for TLS Using the Server Keystore
>requires to restart Tomcat whenever we change the contents of the keystore
>since they are cached at launch and are not re-examined until the server
>process is bounced. We need to investigate an approach to avoid server
>restart and dynamically load the keystore content. One possible solution
>would be to implement a custom trustManagerClass and then use it to load
>the KeyStore on every ssl-session [3].
>
> In order to overcome the above limitations, supplementary
> features/capabilities are required. Please find the following task break
> down in order to address these limitations.
>
> Task 1 - Capability to upload the client certificate to the trustore.jks
> from UI and dynamically apply the certificate changes during runtime.
>
>- Sub-Task 1 - Merge the changes in [2] to carbon-identity-framework
>master branch and test the functionality.
>
>
>- Sub-Task 2 - Implement a mechanism to sync truststore changes in
>cluster.
>
>
>- Sub-Task 3 - Investigate an approach to avoid tomcat restart and
>dynamically load the keystore content for the connector.
>
>
> Task 2 - Address the conflicts with existing authenticators (e.g.
> MutualSSLAuthenticator/X509 Authenticator) when engaging the TLS Mutual
> Authenticator.
>
>- Sub-Task 1: Improve the existing MutualSSLAuthenticator to add a
>secondary factor of validation.
>
>
>- Sub-Task 2: Improve the existing X509 Authenticator to add a
>secondary factor of validation.
>
>
> Appreciate your feedback and suggestions.
>
> [1] Invitation: [Review] User Story - Mutual TLS Authentication for Oauth
> 2.0 clients @ Mon Feb 12, 2018 2pm - 3pm (IST) (WSO2 Engineering Group)
> [2] https://github.com/wso2/carbon-identity/pull/1511
> [3] https://stackoverflow.com/questions/5816239/how-do-i-
> force-tomcat-to-reload-trusted-certificates
>
> Thanks,
> Sathya
>
> On Fri, Feb 9, 2018 at 12:34 PM, Hasintha Indrajee 

Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Sathya Bandara]

Hi all,

The basic implementation for this feature is completed and we held an
initial code review for this. Review notes can be found in [1]. We were
able to identify the following key limitations when including this feature
in the product.


   1. In order to use the client certificate in the authentication request,
   the certificate needs to be imported to our truststore as a pre-requisite.
   As a result we will have to ask to restart the server. Even if we add the
   certificate via Management console it will not be applied unless the server
   is restarted with the current implementation. In order to overcome this
   requirement , we need to improve our existing implementation to add
   certificates at runtime without restarting the server. Part of this
   improvement is already provided in [1] which provides the following
   capabilities.

   - Alter UI to view the default trust store.
  - Alter keystore management service to support the addition of trust
  stores.
  - Create a X509TrustManager implementation that dynamically reloads
  any changes made to the trust store. Anyone using this
  "DynamicX509TrustManager" with SSLContext will not require to restart the
  server for changes to client trust store to take effect.

  2. Since in the current approach of mutual authentication using TLS,
   we need to add the client certificate to the cient-trustore.jks in order
   handle mutual TLS at at web container level (tomcat), during TLS handshake.
   In this scenario all the client certificates will be accessible globally
   since we cannot override the trustore at SP level. Since our admin services
   are protected by the Mutual-SSL-authenticator, clients can successfully
   authenticate from mutual SSL authenticator using their certificates and
   consume admin services. As a work-around we can specifically ask to disable
   the mutual-SSL-authenticator if the requirement is to use mutual TLS for
   client authentication. However, the proper solution would be to find an
   approach for the web container to dynamically identify the client specific
   certificates during runtime.

   3. Configuring the Tomcat connector for TLS Using the Server Keystore
   requires to restart Tomcat whenever we change the contents of the keystore
   since they are cached at launch and are not re-examined until the server
   process is bounced. We need to investigate an approach to avoid server
   restart and dynamically load the keystore content. One possible solution
   would be to implement a custom trustManagerClass and then use it to load
   the KeyStore on every ssl-session [3].

In order to overcome the above limitations, supplementary
features/capabilities are required. Please find the following task break
down in order to address these limitations.

Task 1 - Capability to upload the client certificate to the trustore.jks
from UI and dynamically apply the certificate changes during runtime.

   - Sub-Task 1 - Merge the changes in [2] to carbon-identity-framework
   master branch and test the functionality.


   - Sub-Task 2 - Implement a mechanism to sync truststore changes in
   cluster.


   - Sub-Task 3 - Investigate an approach to avoid tomcat restart and
   dynamically load the keystore content for the connector.


Task 2 - Address the conflicts with existing authenticators (e.g.
MutualSSLAuthenticator/X509 Authenticator) when engaging the TLS Mutual
Authenticator.

   - Sub-Task 1: Improve the existing MutualSSLAuthenticator to add a
   secondary factor of validation.


   - Sub-Task 2: Improve the existing X509 Authenticator to add a secondary
   factor of validation.


Appreciate your feedback and suggestions.

[1] Invitation: [Review] User Story - Mutual TLS Authentication for Oauth
2.0 clients @ Mon Feb 12, 2018 2pm - 3pm (IST) (WSO2 Engineering Group)
[2] https://github.com/wso2/carbon-identity/pull/1511
[3]
https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates

Thanks,
Sathya

On Fri, Feb 9, 2018 at 12:34 PM, Hasintha Indrajee 
wrote:

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

Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Hasintha Indrajee]

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  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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Sathya Bandara]

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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture