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! Go to Solution.
What you will need to do in Apigee:
<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.
What you will need to do in Apigee:
<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
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |