search

mulesoft / api-policies

18 stars 34 forks source link

Policies that use cxf:proxy-service does not work with the autogenerated wsdl proxies in API Gateway #5

Open FedeAmdan opened 9 years ago

FedeAmdan commented 9 years ago

As the policy is using a cxf:proxy-service, that component will provide you an invalid wsdl instead of giving you the one generated by the API Platform proxy's cxf:proxy-service (which modifies the wsdl of the user's web service) or the one generated by a cxf:jaxws-service. This is wrong, even if your webservice is secured, you must be able to retrieve the wsdl of it. The correct usage of this security component (if you have an API Platform proxy) would be to include it inside of the proxy's cxf:proxy-service (without using a policy).

rusinm commented 9 years ago

Could you clarify how does it relate to the web security configuration? I understand that the web security is based on the standards. I do not specify a wsdl in that component, just a SAML validation.

Dňa 7/17/2015 o 11:44 PM Federico Amdan napísal(a):

As the policy is using a cxf:proxy-service, that component will provide you an invalid wsdl instead of giving you the one generated by the API Platform proxy's cxf:proxy-service (which modifies the wsdl of the user's web service) or the one generated by a cxf:jaxws-service. This is wrong, even if your webservice is secured, you must be able to retrieve the wsdl of it. The correct usage of this security component (if you have an API Platform proxy) would be to include it inside of the proxy's cxf:proxy-service (without using a policy).

— Reply to this email directly or view it on GitHub https://github.com/mulesoft/api-policies/issues/5.

FedeAmdan commented 9 years ago

The limitation that I am talking about is related to the mule components and how the policies are applied in API Gateway. The policy that you created, and also the API Platform autogenerated proxy contain a cxf:proxy-service. One of the things that this element is doing, is letting you retrieve the wsdl of the web service that you are proxying, by appending "?wsdl" to the web service address. The proxy-service that is inside of the proxy is retrieving the original wsdl, slightly modified. (The changes are produced by the proxy-service). By including the second proxy-service before it (that is inside of the policy, which has the ws configuration but does not contain any wsdl configured), this feature can not be done. The wsdl that is retrieved does not contain the information of the web service that is being proxied. This feature is essential for the proxy usage. What i see is that by including the ws configuration inside of the proxy-service that is already inside of the proxy, the endpoint is secured. This is the only way to secure it right now.

evangelina commented 8 years ago

Hi @rusinm, the problem is when the policy adds the proxy-service and a request to retrieve the WSDL is made. In that case, the policy's proxy service will return a stub WSDL that the proxy uses, since there is no wsdlLocation configured, instead of the implementations WSDL. The way to validate this problem is to invoke ?wsdl before and after applying the policy.

The way around it is it to check if the request ends with ?wsdl o ?xsd, in which case you can skip the policy's logic, since I guess it doesn't make sense to apply it to the WSDL retrieval, and the main proxy will be the one returning the correct WSDL.

Please let me know if it's clearer now, Eva