Integrating Authentication and Permissioning for Vendor Data
We have been forced into updating a Data Vendor's API because they never really envisioned that we'd use their desktop product in quite the way that we had - which is to say, built a server around it and made the content accessible to a large number of applications for the traders. So, when they saw what we did, they decided to make that unsupported, and brought out a product to be used in the same manner - for considerably more money. Surprise!
So, we had to upgrade, and in this upgrade, they biggest changes are in the authentication and permissioning of the data. It's understandable, they need to protect the data from unauthorized eyes, etc. The problem I'm running into over the last few days is the way they are having me (and all the other API users - all eight of us) do this authentication. First, everyone has to have a login to the service. Seems that's a good place to start and end. But no. They have an underlying 'ID' - that's guaranteed unique. Seems that's a good place to end then. But no. The minimal authentication is done in their Java client with an ID and the IP address of the machine they logged in on.
Now it seems to me that they already know this, and all they really need is the login. The login leads to the ID, and the login tells them the IP address of the machine they are logged in on. The way they have done it is doubly redundant. That's taking a bit of doing, but it gets even better in the C API.
In the C API - if I'm reading the documentation correctly, you need not only the ID, but four other pieces of information that are known by the service but I have to provide and have no way of knowing programmatically. I have to have the user go to a page on the service's application, read off four multi-digit numbers and then feed them to the C call.
That's an embarrassment. I can't believe they think this is a good scheme. I'm hoping that these four are redundant, or unnecessary, and the docs are simply out of date. But I have a feeling that they aren't and this is just the "way things are" with this vendor. I'm really shocked at this because I had a pretty decent way to have my market data server incorporate this into it's core so that data coming out of the server could be filtered based on the requested user. That would be wonderful as it would put all the permissioning behavior into one place which makes it far easier to control.
We'll see what I get back from one of their "API Experts". I'm really really hoping I'm wrong here.
UPDATE: I got a little help from one of the experts, but for the most part I have to say that getting bad information is worse than getting no information - which was the case today. I asked for the parameters I needed to pass in and got back a list that wasn't right. Once I figured out it wasn't right and what might the right set be, I was well into the afternoon and yet I did get it right. Then I had to realize that their idea of returning a negative was returning an error and not a negative at all. So I had to code for that as well. It's amazing... the people who created this additional functionality didn't even study the old style of doing things and it makes for a very clunky interface to the system. It's working, but as I had expected going in, it's not easy and it's a pain to make it look pretty.
Tomorrow I need to wrap this authentication into a request class and then integrate it into the market data server and finally add caching on the results so that multiple requests in a day don't need to each go to the service to be resolved. Once a day is going to be enough.