Would I be right in thinking that a Web service's API is a client of the Web service, which provides function names to access the Web service?
Not exactly, although the last part of your statement may be correct..ish.
API stands for "Application Programmer Interface" (or something along those lines anyway). Basically, an API is a set of specifications, telling a using party (the client) how to access some resource (the Web Service).
A client can for instance be an application which connects to a service in accordance with the specifications in an API. This is a general principle (not only for web services), and can be really simple, like for instance the following:
https://www.google.com/search?q=catnip
This is a search query to google. An API states that the value of the parameter q (passsed in the url using ?q=<some value>, should be searched for.
A client could be your web-browser, or any other application which passes that query to Google, and receives the answer it provides.
Sidenote: The same API also states that there can be more data in the url, such as format, client-information, etc: https://www.google.com/search?client=opera&q=catnip&ie=utf-8
Related
We have intranet based notes applications. We need to create a web service provider from notes and it needs to be consumed from other internet based application.
Note- the consumer will be triggered from external environment not from our network.
For Eg: Network X is ours, all the note application works only in network X(not in internet). It means that single sign on is not enabled. The external application is in network Y.
We have a provider and it works fine in our end. But we need to consume it from the external application, it is ASP .Net.
Question :
Does Single Sign on need to be enabled in our domino server?
Is there any possible to consume my provider without enabling single sign on from external application?
Which is the secured web service scenario in Lotus notes domino?
We are using notes 8.5.3.
Thanks in advance
I will start a response, but I'm afraid that you didn't gave enough information to get the response you need.
Basically, your WS provider is anonymous, so a consumer calling it from the Y network will act as anonymous.
[edited]
From your network Y, simply open the WSDL to check that you have access:
//server/yourdb.nsf/WS_name?wsdl
Using tool like SoapUI, try to consume it.
According to you remark (hello word) you don't need what I mention below about security. I suggest you to read Creating your first Web Service provider and consumer in LotusScript and Java.
Security
If the data you want to send are publicly accessible, you have not to care about security and SSO. If in contrast you need to give access thru your WS to a limited audience, you will have to read and do what IBM recommends:
How to secure a web service hosted on a Domino server
I suggest you to provide some information:
in which language is the WS (LS / Java)
how/what ganularity did you implement the security (reader field, or ACL)
What is the data you
are returning with your WS
Is it possible to block connections to a web service (server) from outside its domain?
For example consider a web app that fetches data from Twitter's API using Twitter's "application only auth". The web app's client uses AJAX to call it's own server, which in turn calls Twitter's API with Twitter's token.
While the token is never exposed to the client side code is there anything to stop an outside server side app from calling the web app's server using the URLs used by the client and for example exhausting the Twitter tokens rate limits?
Is it possible to block connections to a web service (server) from outside its domain?
Certainly. Set your web server's access control lists to drop connections from outside of your IP range. Alternately, install a firewall. That's very straightforward, but I suspect you mean something else by "outside its domain?"
From your description, you seem to be really asking whether you verify that you're only talking to your own client application. As a general rule, no. You can authenticate users. That's easy. If the user isn't logged in and authorized to use your service, you don't forward requests to Twitter. But you can't authenticate applications.
If you're going to accept any user who shows up, you can't stop them from using whatever client they want. There is no way to ensure that it is your unmodified client if you've allowed it to be run on their machine. They can always modify it, and they can always send you arbitrary traffic from other programs and you can't tell the difference. On the network, bytes are bytes.
It's not all hopeless; there are things you can do. See https://stackoverflow.com/a/9183066/97337 for another version of this question, and links to several other versions of the question. (They're not exactly duplicates in how they're asked, but they all wind up being basically the same answer.)
You should secure your web service with user and password security or certificate security. The basic idea is that the web service client must authenticate in order to call your web service.
Here are some technics (there are others or variations):
1) HTTP basic authentication and HTTPS
2) Mutual SSL authentication - Also called two-way authentication, is a process in which both entities authenticate with each other. The server presents a certificate to the client and the client present a certificate to the server.
3) With SOAP web services you can use WS-Security standard.
4) OAuth framework
5) With Rest services you can use options 1), 2), 4). Or implement one by your own. This are good recomendations.
As you can see, there are a lot of ways to secure a web service.
I have a public facing API that returns some data, internally using the Google Maps API Service. This API is mostly for interal purposes right now, invoked through the webapplication.
However, I wish to restrict the usage of this API i.e. it should only be invoked from my Web Application ( or mobile app) when a user (non-registered) browses it. An http request directly to this API should not be authorized.
I cannot use API keys since the webapp flow should work for non-registered users as well.
If you're not using HTTPS, any security mechanism is flawed, because it can be replicated. IMHO, you could add a HTTP header (e.g. "Request-source: YourApp") and check for its existance in your API.
Of course, once it's documented somehow, anyone can mimic this header. But if you use HTTPS and create a header that's unknown for other people, you prevent this from happening.
A company has developed a web service for us. They have sent us the URL to the web service and the method and parameters we will need to call. They said that they would send us the secure API key and they just did. This key is in the format: ABCDE_IBMPC_Z12345 but no other instructions.
My question is, they did not send any instructions on how to log in with this secure API key. Is this something "generic" to all web services? Can someone tell me how to use this key to authenticate and log in so that I can call the method I need to call?
It will most likely need to be supplied as a querystring parameter... they should have told you what the parameter name is though :-)
It'll be something like ?api_key=ABCDE_IBMPC_Z12345
This is a similar situation to the one raised in this question:
Javascript Calling a Rest API with App Name and App Password - How Can i Secure it
Here is the architecture overview:
The site is Html5/jquerymobile
It contacts what I call a "Wrapper" service.... This is a REST API I wrote in C#, to contact another 3rd party REST API. I do this because there are credentials in the Header and the API uses Basic Authentication. Credentials are therefore not publicized as they are only known server-side.
My "Wrapper" service does not currently implement any additional security. It is currently accessible from anywhere. The easiest and quickest way to lock it down is to restrict by IP, so no other IP anywhere except the server can actually contact my wrapper service.
The questions:
Is the locking by IP the only way to ensure that the API won't get hammered if it was otherwise accessible from anywhere?
If I convert this using Phonegap (which I have... and deployed successfully on Android), obviously the native app won't work if the web service is restricted.
Is there a way around this so I can allow traffic only from the mobile app, and not from any other source? I'm thinking along the lines of MD5 hash or something that could be sent to the wrapper API.. but unfortunately I'm thinking that info can easily be "sniffed".
Is my only viable option here to release the app as a web app, forcing browser use, thereby removing any concerns about allowing my web service to be hammered??
I believe the answer to this is a combination of a user token and encrypting the message through SSL.
The server can issue a valid user a token so we can identify him in future requests.
Encrypting it via SSL will ensure that this token cannot be sniffed.
https://security.stackexchange.com/questions/12531/ssl-with-get-and-post