Governing Anonymous Service Consumers
On Friday, the SOA Chief (Tim Vibbert), Brenda Michelson, and I had a conversation on Twitter regarding SOA governance and anonymous service consumers. Specifically, how do you provide run-time governance for a service that is accessed anonymously?
If you’ve read this blog or my book, you’ll know that my take on run-time SOA governance is the enforcement and/or monitoring of compliance with the policies contained within the service contract. Therein lies the biggest problem: if the service consumer is anonymous, is there a contract? There’s certainly the functional interface, which is part of the contract, but there isn’t any agreement on the allowed request rates, hours of usage, etc. So what do we do?
The first thing to recognize is that while there may not be a formal contract that all consumers have agreed to, there should always be an implied contract. When two parties come to the table to establish an agreement, it’s likely that both sides comes with a contract proposal, and the final contract is a negotiation between the two. The same thing must be considered here. If someone starts using a service, they have some implicit level of service that they expect to receive. Likewise, the service provider knows both the capacity they currently can handle as well as what how they think a typical consumer will use the service. Unfortunately, these implied contracts can frequently be wrong. The advice here is that even if you are trying to lower the barrier for entry by having anonymous access, you still need to think about service contracts and design to meet some base level of availability.
The second thing to do, which may seem obvious, is to avoid anonymous access in the first place. It’s very hard to enforce anything when you don’t know where it’s coming from. Your authorization policy can simply be that you must be an authenticated user to use the service. Even in an internal setting, having some form of identity on the message, even if there are no authentication or authorization policies, becomes critical when you’re trying to understand how the systems are interacting, perform capacity planning, and especially in a troubleshooting scenario. Even services with low barriers to entry, like the Twitter API, often require identity.
The next thing you should do is leverage a platform with elasticity. That is, the available capacity should grow and shrink with the demand. If it’s anonymous, and new consumers can start using it simply by getting the URLs from someone else, you have no control over the rate at which usage will scale. If the implied level of availability is that the service is always available, you’ll need on-demand resources.
Finally, you still need to protect your systems. No request is completely anonymous, and there are things you can do to ensure the availability of your service against rogue consumers. Requests will have source IP addresses on them, so you can look for bad behavior at that level. You can still do schema validation, look for SQL injection, etc. In other words, you still need to do DoS protection. You also should be looking at the usage metrics on a frequent basis to understand the demand curve, and making decisions accordingly.
6 Responses to “Governing Anonymous Service Consumers”
Leave a Reply
Todd,
Very good points here but I wonder in practice how big of an issue this really is. How many development folks just run out and discover a service interface on the network and just start using it without anyone knowing about it?
I’m sure it could happen but I think probably not very often. I also know in Financial Services companies like the one I work for, auditing requirements don’t allow for to much anonymous access. Maybe its an issue in very large distributed environments or open web services on the Net?
You don’t necessarily have to control that through an ACL or other security mechanism though, it can be embedded in the meta data of the service. There are a lot of ways to skin that cat as you mentioned, ip addresses, schema validation etc
Obviously you need to understand who is using your service. Context of the use, performance/load patterns, auditing are things that have to be taken into account. Not to mention upgrade issues, requirement changes etc.
markg
Mark,
Tons!
And, one of my favorite stories was a financial services company. The interface was incorporated into some code that was then shared… along with the access ID. I’m not saying it was a good/proper use of technology, but it happens and it happens a lot.
And, a lot of off-the-shelf software comes with service interfaces enabled by default, so any enterprising coder will just try to use them to see if they’re avialble, and lots of time they are with standard user ID’s. Access is logged, but no one looks that closely at the logs unless they’re looking for a problem. Not exactly anonymous access, but certainly invisible.
And, don’t get me started about the case studies of people who’ve “forgotten” a system was even there, and still have people accessing it long after it’s been replaced.
Finally, on a totally unrelated note, a lifetime ago I worked for a disk drive manufacturer. Moody’s was a customer. A drive failed, I went to replace it, and had to wait six hours for them to physically find the server that failed. Six hours! They lost a server. Don’t tell me people don’t lose lines of code, when sharing it’s as easy as pulling a WSDL into the dev environment and making a call.
David
Progress Software / Actional
David,
Very good points and examples but I not sure we are completely talking about the same thing. All the stuff you mentioned certainly happens a lot in an enterprise. That’s were good governance processes come in to make sure things like that are kept to a minimum.
But my point was about anonymous services from a security perspective already in play and being discovered and used. For services that folks have forgotten about or don’t know about because they are embedded in other things, I agree with you there, it does happen a lot.
This all falls back to your governance process not the security access point to your service. Hows does your enterprise code get reviewed? How do you conduct your design reviews? Hows does it get documented? How does it get promoted to production? How do you audit your existing services and usage?
These things will address the usage of services because as you pointed out developers will share user id’s and passwords. Of course that’s an another problem with your architecture if you are relying on user id’s and password for security and knowledge of who is doing what.
that’s my two cents.
markg
I have to agree with Todd’s comments and David’s response. I have found over the last 6 years that rogue services are not the real problem (for us), but rogue consumers. To allow anonomous service access would be similar to McDonalds. There is a certain level of service expected, but when a bus load of people arrive, everyone has a delay. As a consumer, you could leave and go across the street to Burger King, but you have no other action. In business, you CANNOT allow anonomous access to services that are used in business processes. You cannot jeapardize the other applications. Governance is critical. A business would never rely on a service (human or computer) for which they did not have a contract with service levels specified that impacts their business proceses. Why would we even consider this for internal SOA services?
ben
Todd,
I think the capacity growth and shrink with the demand can be achieved with Cloud computing which makes me dream about big SOA+Cloud computing.
If the anonymous consumers are expected users like employees or customers of the enterprise you can group the users based on the department or location or role….
In case the provider is not aware of the consumer log the consumer IP and monitor the most consuming IP and enable SLA.
My 2 cents.
A cloud provider is certainly an option for anonymous services where the load is inherently unpredictable. There’s also no reason why you couldn’t create a capacity-on-demand environment in your own data center, as well. Pricing models, security, and integration needs are all things to consider when choosing how to provide the necessary capabilities.