How can I make 2-way tls optional for some consumers.

I mean if a client wants to do 2-way tls I support that and if they don't want to perform 2 way tls I should support that as well. I want to configure this for only some exceptional client. For rest of the client calling my api I want to enforce 2 way tls.

Solved Solved
0 2 720
1 ACCEPTED SOLUTION

What you will need to do in Apigee:

  • create 2 inbound virtualhosts, one with 2-way TLS, and one with 1-way TLS. Call them "1waytls" and "2waytls", respectively. These have different hostnames. Let's say https://api.1waytls.example.com and https://api.2waytls.example.com
  • For clients that do not use 2-way TLS, set the custom attribute "RequiredVhost" on the client to have the value "1waytls", which is the name of the vhost you defined above.
  • For your other clients, set the custom attribute "RequiredVhost" to have the value "2waytls".
  • Within the proxy logic, you will need to verify the token or key presented by the client. Once you have verified that client authentication, you will have the client_id. Using that you can AccessEntity to get all the attributes for the client, then use an ExtractVariables to get the specific attribute called "RequiredVhost" into a context variable. Then, using Conditions in the proxy flow, you can raise a fault if the designated Vhost for that client does not match the vhost they used. It might look like this:
<Step>
  <Name>OAuthV2-VerifyAccessToken</Name>
</Step>
<Step>
  <Name>AccessEntity-GetClientInformation</Name>
</Step>
<Step>
  <Name>ExtractVariables-GetRequiredVhost</Name>
</Step>
<Step>
  <Condition>virtualhost.name != client_designated.requiredvhost</Condition>
  <Name>RaiseFault-IncorrectVhost</Name>
</Step>

This illustrates the idea and will work. But you can make it perform better.

You can eliminate that lookup on every verify-access-token, if you attach the required vhost information as a custom attribute on the token itself, during token generation. So the lookup I just described would be done only once, during token generation, as opposed to every time the token is verified.

View solution in original post

2 REPLIES 2

What you will need to do in Apigee:

  • create 2 inbound virtualhosts, one with 2-way TLS, and one with 1-way TLS. Call them "1waytls" and "2waytls", respectively. These have different hostnames. Let's say https://api.1waytls.example.com and https://api.2waytls.example.com
  • For clients that do not use 2-way TLS, set the custom attribute "RequiredVhost" on the client to have the value "1waytls", which is the name of the vhost you defined above.
  • For your other clients, set the custom attribute "RequiredVhost" to have the value "2waytls".
  • Within the proxy logic, you will need to verify the token or key presented by the client. Once you have verified that client authentication, you will have the client_id. Using that you can AccessEntity to get all the attributes for the client, then use an ExtractVariables to get the specific attribute called "RequiredVhost" into a context variable. Then, using Conditions in the proxy flow, you can raise a fault if the designated Vhost for that client does not match the vhost they used. It might look like this:
<Step>
  <Name>OAuthV2-VerifyAccessToken</Name>
</Step>
<Step>
  <Name>AccessEntity-GetClientInformation</Name>
</Step>
<Step>
  <Name>ExtractVariables-GetRequiredVhost</Name>
</Step>
<Step>
  <Condition>virtualhost.name != client_designated.requiredvhost</Condition>
  <Name>RaiseFault-IncorrectVhost</Name>
</Step>

This illustrates the idea and will work. But you can make it perform better.

You can eliminate that lookup on every verify-access-token, if you attach the required vhost information as a custom attribute on the token itself, during token generation. So the lookup I just described would be done only once, during token generation, as opposed to every time the token is verified.

Hi Dino,

Is there a way to modify the Virtual Host configuration to ask for client cert (SSL Handshake Certificate Request 13) and if the client doesn't send the certificate back, apigee doesn't terminate the SSL connection and populate the SSL Handshake variables accordingly?

We have a scenario where we cannot change what existing clients are connecting too. Some clients do 2-way SSL and some don't. but the current NetScaler has that option of making the response to "SSL Handshake Certificate Request 13" optional, which means it let the SSL handshake continues even if the client hasn't presented a client certificate. Then it injects HTTP headers with the outcome of the SSL Handshake which in this case it would have an empty DN. Later on the policies checks that variable and allow or denies request based on that.

Cheers,

adam