Thursday, March 31, 2011
Sometimes internal machines are setup with SSL certificates which don't match their hostnames. Usually the reason is because the organization has bought a block of certs from Verisign, doesn't want to order more, and doesn't want to use self-signed certificates. So if you are putting the Vordel Gateway in front of a machine which (for one reason or another) is using an SSL certificate which doesn't match its hostname, then you can tell the Gateway to either (a) flag this as an issue with the service and block the request, or (b) ignore the problem.
The setting is under the "Remote Hosts" setting in Policy Studio, and the checkbox is "Verify server's certificate matches requested hostname".
Wednesday, March 30, 2011
At the time, an API was understood as being for C++ or Visual Basic. MAPI (the Mail API for Windows) is a good example. At the time I would write EDI clients using ISOCOR products, and one in particular, Personal ISOTrade, implemented the MAPI API. So, with that product, all we had to do was implement that API to send EDI messages (EDIFACT and HL7) over X.400. I also did Java programming at the time, and used Java toolkits (e.g. J/Crypto which was a full-strength JCA/JCE implementation) but these were toolkits or implementations of interfaces, not quite the same as "APIs".
Fast forward ten years. Service Oriented Architecture principles took hold, even if the name "SOA" remained controversial. The notion of Services replaced APIs. You may still use actual programmatic APIs, but the understanding was that what you were really using is a service which shouldn't be tied to a particular language. This kind of thinking was liberating, and opened up all kinds of possibilities. Gradually the APIs could be exposed in a more widely-usable way. This is how we started to talk about "services" not "APIs".
Daryl Plummer put it well that "someone told me, “if you’re over 30 you call it an ‘API’, and if you are under 30 you call it a ‘service’”)
But then what happened? It came full circle. In 2011 when we talk about "API's", we mean Web APIs like the ones on this huge list of Web APIs. The kids are now talking about APIs again, but not in the way that we did 15 years ago. Take for example the USA Today Sports Salaries API. Are you interested in finding out how much a particular US sports player earns? Then this API will get the info, using a HTTP request and receiving the response in JSON or RSS (XML).
One big difference between the C++/VB APIs of old and the Web APIs of today is that API management and security wasn't something that was considered 15 years ago. There were exceptions, such as crypto APIs which included controls against attackers swapping in their own implementation of the API as an attack. But mostly the APIs were called under the context of the user's application, and security was at that level (i.e. "The user must have logged in to use the app"). And usage of the API was usually not tracked.
But now, API management and security is important. To see why, check out that USA Today Sports Salary API page again. Access to this API is managed using an API Key:
Every call to the USA TODAY Salaries API must be authenticated with the programmer's unique API key, as in this sample request.http://api.usatoday.com/open/salaries?api_key=XXXXXX
USA Today uses this developer key to limit access to their valuable sports salaries database to just 1000 requests per day. However, the API key in the example above is sent over (yikes) plain HTTP, so an imposter could sniff someone else's API key from a message and then use it to suck down sports salaries on their account. All of this points to the need for API management and security. Fortunately there are options for API security, so that exposing a Web API doesn't have to mean hanging your data out for the world to access over plain HTTP. With a service gateway it is quite trivial to create a policy that enforces SSL, enforces usage limits, and provides API monitoring.
One of my favorite Web APIs to use in demos is SalesForce.com . SalesForce has a ton of information about their API on their developer site. Vordel can be used to connect up to SalesForce, including protecting API Key and caching the Session Identifier which is returned back by SalesForce.
One of the neat things about this is that all traffic from the app to the SalesForce API is now authenticated and monitored, and shown in the browser, as shown below:
This type of API usage monitoring wasn't possible with the APIs of the past.
So APIs and services have come full circle. 15 years ago, it was all about APIs. Then it was all about services. Now, we talk about APIs again, but mean something different than we did back then. Security and management of these new APIs has reared its head, but the good news is that there are solutions to this.
Tuesday, March 29, 2011
Monday, March 28, 2011
Following up from yesterday's video, here are some pointers to using Vordel Reporter for monitoring service usage. In the screenshot below, you can see the client Web Service usage lookup, showing how our clients (in this case "East Industries", "Central Industries", and "West Industries") have been accessing services through the Vordel Gateway. The information is shown simply as totals, but if you want to see running graphs, hit the "clients" button (to choose clients to view) then the "Aggregated Metrics" button:
See the "Audit Trail" button in the top-right? Click on this to construct queries over Vordel Reporter. Let's say an admin from East Industries is on the phone saying "Why did you guys block our message?". You can construct a search to find out if East Industry's messages are falling foul of Schema Validation, indicating a problem with their messages. In the search results below, we see that is indeed the case:
When we double-click on one of the messages, we see the message itself, and the path it took through the policy on the Vordel Gateway. We see that East Industries was authenticated, but then their message failed Schema Validation. For good measure, we see the message in the report, which we can then download and test using the SOAPbox testing tool.
The upshot is that the organization can troubleshoot their client's messages quickly and easily. This is one of the key day-to-day benefits of a SOA Appliance. If you want to schedule a live demo of this feature in action, you can do that on the live demo page on the Vordel website.
Friday, March 25, 2011
One of the neat things about Vordel Reporter is that you can drill in on messages and see the same kind of "Path through the policies" information as you see in the Vordel Gateway's Real-Time Monitoring. In the video below, I first run a report to see the clients which are accessing my services through the Vordel Gateway. Then I drill in on the Audit Trail, to see which messages from particular clients are failing schema validation, and I can take a copy of the messages themselves. The Message IDs allow me to cross-reference with the Vordel Gateway trace files. In the example, I'm checking to see which messages from "East Industries" have failed Schema Validation, and then I click on the message to see how it was processed in the Gateway. The neatest piece is at the end: The pass through the policy in the Audit Trail maps to the path through the policy shown in the Gateway's Real-Time Monitoring.
(Note: Click on the little "expand full screen" button by the video below so that you see the detail properly):
Wednesday, March 16, 2011
You can use the free SOAPbox testing tool to test for vulnerability to XPath Injection. This is configured in the Design Mode of SOAPbox, as shown below:
Monday, March 7, 2011
Thing is, there are apps I can only get from the app store that control my home lighting, and my home security. I own hundreds of apps that help me through out my work day. Also, I use my iPhone to project family pictures or videos on to my TV screen through the air and on top of that every time I have ever had any kind of issue with Apple, when I call them, they not only make it right, they go the extra mile. There store staff is trained and friendly and all my books, music, and movies, all sync so easily with my iPhone and iPad. Why would I ever want to switch to a different tablet. And Steve Job's job is to come out and be a salesperson. Sales people always tell you what you want to hear. Why would they come out and say something negative like, "And RAM, well, it just stays the same." That would be plain stupid. So who cares? The specs are clearly on the the Apple website. I have a child because of an app and we had been trying for two years. I guess what I am saying is. With my iPhone, iPad, and iTouch, they have always been fast enough for me. I have had every single one of the iPhones since they first came out. I don't need a faster processor or more RAM. Granted, I do feel that the product is faster when I get a new iPhone but ...I would have never known how that felt until I had the new one in my hand. So all of that is just icing on the cake. I love my iPhone because it comes with great customer service, is a well made product, and ties my whole life together very easily and is very easy to use. A kid can use an iPhone. Why would I switch? I have no problems and a great product that works perfectly. It is obvious that this guys just wants to hate on Apple.
Read for yourself on:
Sunday, March 6, 2011
The sample "StockQuote" service on the Sandbox image has HTTP GET interface, as well as the SOAP 1.1 and SOAP 1.2 interface. This makes it useful for REST/SOAP protocol conversion scenarios.
First, make sure the demo services are running (double-click on the shortcut for the sample Web Services on the demo image's desktop). Then if you point browser to this URL on the sandbox, you'll see the stock quote for the ticker "VRDL":
[ Note that "webservices" is mapped to the local loopback address using the hosts file. So you could use "localhost" instead of "webservices" in the URL if you like].
There is also an "update" method on this same Web Service, also called with a REST interface. This is for updating the stock price. Calling the following with a GET from a browser will result in some stock price manipulation:
Now once again call getPrice for VRDL, and see what happens. The stock price has doubled.
But hang on: One of the principle of REST is that a GET should not have "side effects" (and updating a stock price is clearly is a side effect). Also, pure REST shouldn't involve the use of HTTP QueryString parameters like we just used, even though that is how the majority of people understand REST is used (in pure REST the parameters are contained in the URL itself, not "after the question mark").
So let's use the Vordel Gateway to apply some policies to these services, and make them more RESTful.
Firstly, it makes sense to only allow certain authenticated clients to change the stock price using "update", while allowing anyone to view the stock price using "getPrice". It also makes sense to force clients to use "PUT" to put up a new stock price, and not violate the principles of REST by using a "GET" for this purpose. This is a classic example of how the Vordel is used to apply different policies to different REST services. We do this by applying different authentication policies in the Vordel Gateway to "getPrice" and "update", by mapping the URIs for these REST calls to different policies at the Vordel Gateway.
In this way, we avoid the wrath of angry RESTafarians by ensuring that the "update" operation can *only* be called with a HTTP PUT (not using a GET), while still allowing "getPrice" to be called with a HTTP GET.
In addition, we want to make sure that the usage of these operations is tracked, so that we can see how many people are using "getPrice" versus "update".
How to detect if a client has accessed our REST service using a HTTP PUT verb:
The following script will detect is a client is trying to access the REST service using a HTTP PUT:
This script can be put in to a Scripting Language filter in the Vordel Gateway, and it will return true if the user attempted to call the service with a "PUT", but return false otherwise. This allows you to branch within a policy on the HTTP verb used, which is a classic REST use case (only certain users can do a "PUT" on a particular URL, etc).
Therefore, clients can access this REST service fine,
But if you try this next URL in a browser now, you will be blocked because you've used the wrong HTTP verb (the Vordel Gateway blocks you because you should have used "PUT"):
Sending a HTTP GET with SOAPbox, SOAPui, or Poster:
Now, to use that "update" operation, you have to use a HTTP PUT. You can do this with SOAPbox (Vordel's free Web Service testing tool) or SOAPui or the simple "Poster" Firefox utility. [Note, if you're using Poster then make sure you hit "Parameter Body" so that the Content-type is "application/x-www-form-
urlencoded". Similar requirements go for SOAPbox and SOAPui. In SOAPbox, the "Request Settings" dialog, which you can see if you click on the little downward arrow beside the green "Play Button" you use to shoot requests off to a service. Click this, then drop down the appropriate HTTP Verb in the next dialog which comes up (i.e. choose GET or PUT, not the default POST).
The content you are sending with the HTTP PUT is:
And note that you no longer have the parameters QueryString there (i.e. just this: http://vordelgateway:8080/axis2/services/StockQuoteService/update ). Note also that this is quite similar to Amazon's Query API (though this uses POST not PUT).
To demo this, I simply create a user called "Gordon Gecko" in the Vordel user store with password "vordel". This user is the user allowed to update the stock price. Now, when you do a PUT to the "update" operation, I mapped a policy to the URI "/axis2/services/StockQuoteService/update", so that you must authenticate as that user (with HTTP AuthN, so I dragged in a HTTP Authentication filter into my policy).
Monitoring REST usage
If you want to see the various REST methods show up in the Vordel Real-Time Monitoring, add "Set Service Name" filters to your policies so that you are flagging that the REST services show up in Real-Time Monitoring.
If you look at the Real-Time Monitoring (connect to the Gateway on port 8090 with a browser and click on "Real-Time Monitoring"), you now see how the "update" and "getPrice" services are being used. In Vordel Reporter, you can see what Gordon Gecko has been up to, since now you're authenticating the "update" operation.