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

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

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).