How do you secure and meter the web services you share with your business partners?

Question

I'm looking for ideas on how to restrict access to and log calls for an API we're delivering for business partners to interface with our Customer Care application. Should we create usernames and passwords for our external partners just as we would our own employees? Is there some kind of snap-in layer for .Net that can manage access restrictions and metering or do we have to roll our own?

What formats should we support? Is JSON canonical or is there some new thing out there I need to know about?

I'm new to providing software-as-a-service and would love some advice, including an open source .Net project that I can examine for hints.

EDIT: now with bounty freshness!

EDIT: adding content to answer some questions

This will be an API for our partners to use to access our customer service functions, such as creating new accounts, making payments and other account management functionality.

I am familiar with PostSharp and have already produced a technology demo with logging features for method calls.

I am not interested in surveying our partners for which formats/protocols they'd prefer, since one of the requirements is the ability to add new partners without IT involvement. I'd just like some tips on best practices, so that we're doing it the "right" way and they can conform.

Answer 1

I think you need to define what exactly you are thinking of.

Software-as-a-service means you're offering a working software for the users to work on their own data while using your software just as an instrument to manipulate that data. Here, the users are usually not interested in the data you could offer (it is useless to them). SaaS is just an alternative solution for them. They could also develop/install software for their needs locally, in their network, because their primary interest is in their data and they just need an instrument to work with it.

In general, with software-as-a-service you manage users through their accounts. An account has a feature pack where it defines the features available, the quotes for resources used and the access rights that define what can and what can not be done.

What you are describing is basically an external access to your data. It has little in common with the concept of SaaS. For example, GeoIP location services have the same problem, give the access to their database but monitor the usage per user (for example, an account allows 1000 geolocation requests for a user per month).

In order to understand what will work best for you you need to decide what kind of activities you wish to allow your business partners to conduct.

• Do they simply want to read your data? If it is a matter of simple data consumption, then you can probably get away with having basic user account with usage limits. Guessing from your question about the preferred data format, I suppose this is your case.

• Do they intend to take an active part in the customer service process and add, delete, modify or otherwise process the data? In this case you need to think the design of your system through and design (if it's not there yet) a system of users, groups, access rights and quotas. You will be creating accounts for your business partners while defining the allowed activities, usage limits etc. Then you will need to update your code base to watch these parameters.

Regarding the format, I think it is irrelevant to this discussion and a little bit too early to think of. You may wish to ask your partners what they would prefer.

Answer 2

You are not very clear about who a partner is; or whether you are protecting access to data, limiting API calls, or both.

What you are doing is likely to be very specific to your business. Assuming you need to protect the data that the services provide access to you need to authenticate each user and protect the transport layer. For the former you need to have user name and password or unique API token for end users. This should be checked on every request. The transport security can be enabled using SSL if you are using HTTP for your services. It is generally easiest to enable this at the web server level, you don't mention that you are doing any special hosting of web services.

Assuming that this security is in place, it should provide a foundation for auditing which is what I assume you mean by log calls. The username or API token will give you an idea about who is making a call which is fundamental to auditing. Next create a list of data you would like to see an the audit trail. Ask a business user if the info logged can help deal with the questions you have (what is driving you to add logging).

The next things to consider is where the logging code should go (is there a central point? do you use AOP to add it?), and where the audit trail should be logged to. There are tools like PostSharp that let you weave logging through your application without a great deal of modifications, but before doing this see if there an easy way to add a log function to a common location in you application to 'trap' the information you need.

Once you have your hands on the data you need to save it somewhere. This is where things can get interesting. You will need to understand the performance characteristics of your application, and what usage patterns are likely. In many applications it is OK to just log to a database, but at times this will be a performance problem. Logging to text files is OK for some people, but what if the data needs to be related back to your user database? In that case you need some code to process the log files an import data.

Before you spend too much time building any logging code it is worth looking at NLog, Log4Net, and the Enterprise Library logging block. These are general purpose tools that might provide a better foundation.

If you need to enforce user quotas you might want to consider how quickly your log can be processed to determine how many calls a user has made. Ideally each time you process an incoming request you would have the current status of a user on hand to be able to return an appropriate response. It can be an effort to add this functionality into existing applications, and provide the 'infrastructure' to support it.

Whether to use REST, JSON, XML, SOAP etc really depends on your audience. Are they going to be using languages like Ruby and Python to call your services, or will they be using .NET? If they are going to be mainly .NET users then it may not make a lot of sense to build purely REST interfaces using JSON since .NET makes SOAP very easy. On the other end of the scale SOAP and XML suck if you are using JavaScript on the client side. Just remember that there is no right answer without more information on your users. Generally JSON is not a panacea, and XML is not always the worst option.

Update

I am not interested in surveying our partners for which formats/protocols they'd prefer, since one of the requirements is the ability to add new partners without IT involvement. I'd just like some tips on best practices, so that we're doing it the "right" way and they can conform.

The most flexible option is likely to be REST and XML. This most broadly supported since almost all platforms have an HTTP stack. XML is arguably more flexible than JSON to represent your data. I would start here and work back in terms of support, maybe adding JSON. However this not what I would call a customer focused approach. If this is a core feature of a platform you should really take an interest in what your customers want. Hey even if you do a quick survey today at least you'll have a more reasonable starting point. If you know any developers at partners then you might be able to surmise what they would prefer from the tools and languages they use (even going as far as looking at their job ads might give you some idea of whether they are a .NET or Java shop - far from a scientific approach though).

Answer 3

To restrict access to your web services, an option would to implement a custom authentication mechanism based on custom soap headers. It's not really complicated and you won't sacrifice interoperability. There are plenty of article to do this on the web, e.g.: Build Secure Web Services With SOAP Headers and Extensions, Authenticate .NET web service with custom SOAP Header, etc.

Or you could have a look at WS-Security and the forthcoming WS-Authorization to deal with concepts like identification, authentication and authorization (see An Overview of the WS-Security Framework). But actually, I don't know the Microsoft Web Services stack well enough to provide valuable pointers.

Regarding the logging of the calls, I don't see any particular difficulty. Once the restrict access will be implemented, you'll find out what to log and where.

Answer 4

We've been using 3scale. It allows to meter and limit access to your API.