Is it possible to invoke two web services in the same API resource?
I need to invoke the first web service and depending on the result returned I invoke the second web service.
I get the first result, but the second endpoint doesn’t work.
On the same endpoint?
I'm not sure if this is the best way, but you can create a real endpoint for ws and to use your "single" as the connection terminal on some trigger in income or whatever else, but in fact you can simply vary the response by the input you catch or the response produced. I simply don't realize why you need a separate socket.
Related
Scenario
I have configured the API in WSO2 which connects to my back-end HTTP service.
Before calling my back-end service, I want to call another HTTP end point (XML over HTTP) to perform some validations. If the validation response is success then the back end point configured in the API gateway can be invoked else the API needs to return error. Please let me know how this can be achieved.
Thanks,
Karthi
You can add a custom in sequence in your API https://docs.wso2.com/display/AM260/Adding+Mediation+Extensions and handle that particular logic there.
In the In sequence, you can add a call mediator https://docs.wso2.com/display/EI660/Call+Mediator to call the Back end and following that you may add a filter mediator https://docs.wso2.com/display/EI660/Filter+Mediator and validate the response and proceed the mediation flow based on it.
In the filter mediator, you may implement a logic to respond back from there itself if it is an error else do nothing so that it will proceed and call you API back end.
I am trying to do a POC where i need to invoke a Stateful SOAP webservice . I need to do a login call first to SOAP webservice and get the session id(or cookie or something like that) and use the session id for making subsequent calls to the webservice . I want to know if there is any sample stateful SOAP webservice hosted on the internet for which i can generate the client and try invoking the webservice to verify Stateful operation. Any other pointers on how i can do this is also very welcome.
If this POC is successful we will be invoking a Stateful SOAP webservice hosted by one of our vendors and we will be using a TIBCO BW client to call the SOAP webservice.
You can invoke the WebServiceDefinitionLanguage from the WSDL attached in the link It brings encouraging quotes.
You may use SOAP activity in BW or import the WSDL as a resource first and then use any SOAP or web service activity.
Check this java project in github is a multi cloud java project that invokes WebServices and Rest services from many Cloud providers and Many sites. It gives you an idea on how to do it.
Of course in BW is really easy to do it. Basically: start activity, SOAP activity, log, call subprocess, catch errors, end process.
Stateful or Stateless SOAP webservice call is just like any another web-service call. In your case, since you have to get the response(i.e. receiving token) of the first webservice call and use it in the subsequent calls, I think you should focus on how would you cache the cookie/token that you receive from the first call. Also, if there is an expiry associated to the life of the token received in your response, work on the technique of refreshing the token for which the SOAP API provider will have to provide you an token expiry interval.
I am using wso2 1.10.0 api manager for first time. I need to access the http backend with simple query parameter. I published the api and tried either by setting as queryparam or json object, it's not giving me the expected result. I will get binary response or method not allowed. When tried setting only http endpoint I never got response its just keeping processing for long time. Please suggest me how do I access simple http backend. Need to show demo in a week.
Please help to solve this.
You get 'method not allowed' when you try to access a resource which was not defined for that method (say backend has POST method supporting resource only and you try to do a GET request)
I guess the issue is with the way you have defined the resources for the api from the publisher application. (invalid HTTP methods for resources)
If you think you have defined them correctly, then the next step to identify the issue is wirelogs. wirelogs provide all the info in request passing through the api manager gateway (request headers, body etc)
Follow this article http://mytecheye.blogspot.com/2013/09/wso2-esb-all-about-wire-logs.html on how to enable and read them
You can then directly call the backend (say curl -v to the backend) and compare the request from the direct call vs the one going out from
gateway to the backend and check the difference. This would help you start finding the issue
Since you are new to API manager, I would recommend you to do following first
Try out a simple scenario similar to your one. You can google it. This is from official documentation. would recommend to try out a simple scenario first. say https://docs.wso2.com/display/AM1100/Convert+a+JSON+Message+to+SOAP+and+SOAP+to+JSON
Then use SOAP UI or similar app to directly call the backend web service (not the api manager) and get the SOAP request and SOAP response for the backend.
Then create the api in API manager. you need to do the same thing in the sample i provided. only difference is the soap payload. use the previously collected SOAP messages.
Enable wire logs. for that see the comments in the previous answer. In wirelogs you will see >> and << signs
To read the wire log, first we have to identify message direction.
DEBUG - wire >> - This represent the message coming into API manager from the wire (will notice two set of these. one coming in to the
gateway from the rest client and response coming in to the api manager from the backend. )
DEBUG - wire << - This represents the message going to the wire from API manager (again two sets. request going from api manager to the
backend service and the response sent to the rest client from the api manager.)
the soap message will be printed in this log. check for the request going from api manager to the backend and the response coming from the
backend to the api manager. you can compare that to the onces you collected in the step 2 and do modifications if needed to the sequnces.
the wirelogs will also print the http headers. so check that as well.
hope you could set up a working sample using these steps
I am trying a scenario where Datapower invokes a web-service on SFDC. For Datapower to be able to invoke services, it needs to first get the authentication token from SFDC and use that token in each web-service request to be able to invoke the web-service.
Is there a simple way in datapower to do this? As the token generated by SFDC is valid for some time, can datapower manage this information internally or will we need to maintain it on a cache (XC10?) and deal with accessing the cache from the integration box ?
Your inputs would be really helpful..
You don't need an XC10 device here, XC10 is needed when you want to cache a lot of name/value pairs. After you call the SFDC service from a Web Service Proxy (WSP) via url-open/soap-call you get the authentication token from SFDC and store it in a local/context variable and also store the current timestamp, and session timeout parameters in other local/context variables, and use them in further SFDC webservice calls. There are other ways of doing this and I hope you got the idea.
I have created a web service API and it's architecture is such that the server requires a client to sign the request along with a secret key assigned to it (signature is always different between multiple requests).
Server matches the client's signature with its own computed signature. If they are a match then the server returns the response.
I am wondering if a client should check the response coming back from the server to see if it's from the same application to which the request was made.
Is any kind of attack possible between HTTP request and HTTP response?
Do we need a security signature for the web service response?
It depends. There are a few types of web service APIs out there. Some need strict security other might not. You could have a few types of APIs:
(1) completely opened API. Say you have a blog where you post about writing RESTful services and clients. You host a complete working REST service based on one of your posts so that people give it a spin. You don't care who calls your service, the service returns some dummy data etc. It's just a demo, a toy, no security here, no request signing, nada. It's just plain HTTP calls.
(2) service with an API key. Say you have a web service and you want to know who calls it. This kind of service needs a pre-registration and each client who wants to call your service needs to register and obtain a key first. Do note that the registration is not about authentication or authorization, you just want to know who's using your API (e.g. what business sector they operate in, how many clients they have, why are they using your API for etc) so that you later make some analysis of your own and take some (marketing maybe) decisions of some sort later on based on the data you get back.
There is nothing secret about this API key. It's just an UUID of some sort, the most basic way of differentiating between calls. This again involves only plain HTTP calls with the key as an additional request parameter.
(3) service with an API key and a secret key. This is similar to number (2) but you need to absolutely make sure that the calls are coming from the client that presents some API key. You need this because you probably want to bill the client for how much they have used your service. You want to make sure the calls actually come from that client and not someone ill intentioned that maybe wants to overcharge the client's bill.
So the client uses it's key for identification and a signature of the request with the secret key to actually vouch for it's identity. This again can be plain HTTP calls with the key and signature as additional request parameters.
(4) data "tampered-safe" web services. For numbers (1), (2) and (3) above I haven't considered any message security issues because most APIs don't need it. What's exchanged isn't confidential and not all that important to protect. But sometimes although the data isn't confidential you need to make sure it wasn't tampered with during transit.
Say you are the owner of a shop that builds some product and you want to advertise your product on some partner web sites. You expose a service with the product details and your partners just use this data to display your product details on their sites. Everybody knows what products you are building so you don't need to hide that, but you are paranoid about your competition trying to ruin you so you want to avoid them intercepting the
request and multiplying by 10 all your prices in the responses of your result just to scare potential buyers away.
Number (3) above, although uses the signing part as a way to prove the identity of the caller, also assures the request was not tampered with (server will reject the request if the signature does not match). So if you need to assure an original response you can also sign the response.
For this, the service can provide the client with an API key and two secret keys. One secret key is used by the client to sign their requests while the second secret key is used by the client to verify the signature of the response (using an unique secret key for the server isn't all that safe so the server emits a server secret key specific to each client).
But this has a weak point: you would need to trust your partners that they will indeed validate the response signature before displaying the information on the site and not just bluntly display it. Paranoid as you are you want to protect against this and for this you need HTTPS.
As #SilverlightFox mentioned this proves the validity of the response. The data was not tempered with because it's encrypted. The client does not need to have an extra step to verify the response signature because that verification is already done at a lower (transport) level.
(5) secure services. And now we reach the last type of service where the data is actually confidential. HTTPS is a must for these services. HTTPS ensures the data remains confidential, that it isn't tempered in transit, identifies the server and can also identity the client if client side certificates are used.
So, in conclusion, it depends on what type of service you have.
Make the request over HTTPS to ensure the validity of the response.
This will ensure your data is not vulnerable to a MITM attack. Rolling your own untested encryption/hashing methods is a sure way to open up your application to attack, so you should use TLS/SSL which means that you should connect to your web service API over HTTPS. TLS is the proven and secure way to ensure the response is coming from the application that the request was made to.