How to protect and measure the web services that you share with your business partners?

Question

I am looking for ideas on how to restrict access and record API calls that we deliver to business partners to interact with our Customer Care application. Should we create usernames and passwords for our external partners in the same way as our own employees? Is there some kind of snap-in layer for .Net that can manage access restrictions and measurements or do we need to minimize our own?

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

I am new to providing software as a service, and I would like some tips, including the open source .Net project, which I can check for tips.

EDIT: now with the freshness of generosity!

EDIT: adding content to answer some questions

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

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

I am not interested in examining our partners for which formats / protocols they prefer, since one of the requirements is the ability to add new partners without IT. I just would like to consult with the best practices so that we do it “correctly” and they can be consistent.

Answer 1

We used 3scale . This allows you to measure and limit access to your API.

Answer 2

You do not quite understand what a partner is; or whether you protect data access, restrict API calls, or both.

What you do is likely to be very specific to your business. Assuming that you need to protect the data provided to the services, you need to authenticate each user and protect the transport layer. For the first, you need to have a username and password or a unique API token for end users. This must be checked for each request. Transport security can be enabled using SSL if you use HTTP for your services. As a rule, this is easiest at the web server level, you do not say that you are doing any special hosting of web services.

Assuming that this security is in place, it should provide the basis for an audit of what I think you mean by journal calls. The username identifier or API will give you an idea of ​​who is making the call, which is fundamental to auditing. Then create a list of the data that you would like to see in the audit log. Ask the business user if the registered information can help solve your questions (which forces you to add magazines).

The next thing to consider is where the registration code should be written (is there a central point: do you use AOP to add it?) And where the audit trail should be recorded. There are tools like PostSharp that allow you to embed logging through your application without major changes, but before you do this, see if there is an easy way to add logging to a common place in your application to catch the information you need.

As soon as you take your data, you need to save it somewhere. Everything can be interesting here. You will need to understand the performance characteristics of your application and possible use cases. In many applications, simply logging into the database is enough, but sometimes it will be a performance issue. Access to text files is suitable for some people, but what if the data should be linked to your user database? In this case, you will need code to process the log files with import data.

Before you spend too much time creating any registration code, it’s worth looking at NLog , Log4Net and the nofollow noreferrer "> registration unit. These are general-purpose tools that can provide a better foundation.

If you need to enforce user quotas, you might consider how quickly your log can be processed to determine how many calls the user made. Ideally, every time you process an incoming request, you will have the current status of the user so that he can return the corresponding response. This may be an attempt to add this functionality to existing applications and provide the "infrastructure" to support it.

Whether to use REST, JSON, XML, SOAP, etc. really depends on your audience. Will they use languages ​​like Ruby and Python to call your services, or will they use .NET? If they are mainly .NET users, then it may not make much sense to create clean REST interfaces using JSON, since .NET makes SOAP very simple. At the other end of the SOAP and XML scales, suck if you use client-side JavaScript. Just remember that there is no right answer without additional information about your users. JSON is generally not a panacea, and XML is not always the worst option.

Update

I am not interested in having partners for whom they would prefer formats / protocols, since one of the requirements is the ability to add new partners without IT involvement. I would like some best practice tips, so we do it in the “right” way and they can fit.

The most flexible options may be REST and XML. This is most widely supported since almost all platforms have an HTTP stack. XML is perhaps more flexible than JSON to represent your data. I would start here and work in terms of support, possibly adding JSON. However, this is not what I would call a customer-oriented approach. If this is the main function of the platform, you should really be interested in what your customers want. Hey, even if you do a quick survey today, at least you will have a more reasonable starting point. If you know any developers in the partners, then you can assume that they would prefer the tools and languages ​​that they use (even if you look at their job announcements, you can think about whether they are .NET or Java The store is far from a scientific approach, though).

Answer 3

I think you need to determine exactly what you think.

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

In general, using software as a service, you manage users through your accounts. The account has a package of functions where it defines the available functions, quotation marks for the resources used and access rights that determine what can and cannot be done.

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

To understand what is best for you, you need to decide what actions you want to allow your business partners.

• Do they just want to read your data? If we are talking about simple data consumption, then you can probably leave with a basic user account with usage restrictions. Guessing 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 about the design of your system and develop (if it does not already exist) a system of users, groups, access rights and quotas. You will create accounts for your business partners when determining acceptable actions, usage restrictions, etc. Then you will need to update your code base to see these options.

As for the format, I think it is not relevant to this discussion and it is too early to think. You can ask your partners what they would like.

Answer 4

To limit access to your web services, you will need to implement your own authentication mechanism based on custom soap headers. It is not very difficult, and you will not sacrifice interoperability. There are many articles on the Internet, for example: Creating Secure Web Services with SOAP Headers and Extensions , Authenticate a .NET Web Service with a Custom SOAP Header , etc.

Or you could take a look at WS-Security and upcoming WS-authentication to address concepts such as authentication, authentication, and authorization (see the WS-Security Framework overview ). But in fact, I'm not good enough on the Microsoft Web Services stack to provide valuable pointers.

Regarding call registration, I do not see much difficulty. After restrictive access is implemented, you will find out what needs to be registered and where.

Answer 5

To implement access restrictions

• I suggest you implement your own strategy. We previously had a similar requirement, and we implemented the approach below.

  • First level: a username and password must be provided for each request.
  • Level 2: Session Key (GUID) must be transmitted with each request.
  • Level 3: Resource level permissions - to access resources, you must pass specific key codes. To do this, you need to maintain a set of permissions for each client for each of them. This allows you to restrict access to users with limited access.

  it will be something like this.

  if (base.IsUserValid(userObject)) { if (base.ValidateSession("sessionid")) { if (base.IsUserAuthorizedToAccessResource("resourcekey","ReadorWrite")) { //Grant Access } } } 

• And I suggest you use SOAP / XML-based services if the client uses .NET technologies. REST / JSON is best for clients using other technologies. But it completely depends on the needs of your client.