Search This Blog

API Security: On-behalf of, delegated trust, and insecure

Over the last couple of years and on a few different projects a growing portion of my work has involved looking at API (and WebService) security. It's got me in a reflective mood, thinking about all the different ways I've seen the AAA (Autentication/Authorization/Audit) part of security achieved during my 12 years in Integration/SOA/Webservices /APIs. The truth is that every project I've worked on has fallen into one of three broad patterns...

On behalf of

The "on behalf of" pattern is where an API/Webservice is invoked by a system on behalf of a specified user. A great example of this is the OAuth2 model. The end user Authenticates with a login system and the client application is given an "Access Token" in order to access services on the user's behalf. The client itself doesn't have any rights other than those given by the token, and doesn't ever see the user's credentials.

The Access Token is then presented to the API with every call, and the API performs fine grained Authorization and keeps the Audit trail. Due to the inherent risks of maintaining any credentials on a mobile app, and the potential for users of an app to accept invalid HTTPS certificates this is really the best and only recommended security for APIs used by systems/applications outside the enterprise.

Delegated trust

A common pattern for services only used inside the enterprise is Delegated Trust - essentially where the system calling an API/Webservice uses a service account (or other form of Authorization such as mutual TLS) to identify themselves. The API then trusts that system to do things for any user. In this case the API delegates the responsibility of doing user level controls, and trusts the client system to do it correctly. This also means any audit records need to be kept by the calling system.

There's nothing inherently wrong with this pattern, and at times it's the only option (e.g. in situations where the activities are not triggered directly by a user, or when a COTS package doesn't allow an alternative); but it's worth considering the downsides:

APIs secured using something like OAuth can immediately be reused by other systems (e.g. an API used by a website can be reused by a mobile app). An API using Delegated Trust needs refactoring to use 'on behalf of', or the same logic needs to be built into each client.

Delegated trust means that authorization logic, and audit logs are split in multiple places. The former can make managing authorization rules more difficult (leading to cost and potential errors), the latter can make SIEM threat detection harder.

Security logic ends up residing in multiple places, and potentially in layers it shouldn't be. Just as we separate business from presentation logic; isolating security logic into a clear area can provide a simpler, more reusable, and more easily testable solution. Having security logic all over the place can lead to developers making mistakes and creating security holes.

In addition to developer mistakes, this leaves a lot more places where malicious software can be introduced by developers, as now any code deployed to any trusted application can access services with impunity.

Network Security, AKA Insecurity

What's really shocking that I still occasionally see the third pattern (or rather anti-pattern), of enterprises relying on "Network Security" to protect services. It's been a while since I've heard "everything is inside our data centre so we're OK"; these days it's mostly "we know it's not ideal but that's the way it is".

Network security is of course an important part of any security in depth strategy, but I don't need to dig out statistics about insider threats to demonstrate that an assumption that "it's inside the firewall so it's safe" is fallacious. Not only can all insider applications not necessarily be trusted; but there are a lot of unsaintly people in any large organisation. Some are open to temptation, others may hold a grudge.

Even assuming complete trust of everyone in IT operations (which one shouldn't), a surprising number of organisations operate flat networks - so anyone with a network account can access servers. This could be receptionists or call centre workers; or this could be the Chief Exec (and who says they're above reproach?). Without strict access controls at every level, and good audit trails, everyone is suspect... even me!

There is hope

Fortunately things seem to be improving. Firstly "The Cloud" is breaking apart data centres, and whilst it rather misses the point to think that it's only now insecure (it always was), at least people are starting to question if that big friendly firewall which "keeps out the nasty people" is really good enough.

Secondly the rise in Apps, and using APIs outside the enterprise is causing people to think about this seriously, and in some cases jump straight from Network (No) Security straight to On Behalf Of security. At that time the introduction of API Gateway software to support this offers an opportunity to at least retrofit service accounts to APIs/Webservices at relatively little cost.

As with other poor practices such as logging personal data, and keeping Credit Card Numbers in unencrypted databases, hopefully this is an area which will soon be rather embarrassing history.

Disclaimer

My postings reflect my own views and do not necessarily represent the views of my employer.For more by me follow me on Twitter @JAGLees

Get link

Facebook

Twitter

Pinterest

Google+

Email

Other Apps

Comments

Post a Comment

Popular Posts

Last week Software AG announced the Trial Version of Webmethods 10.1 had been released. I must admit I've been looking forward to this since the October release note promised they'd be significantly improving their Rest API and Swagger support, specifically:

REST enhancements: Integration Server and Designer now support the ability to read a Swagger specification and automatically generate a REST API descriptor. Additionally, there is support for REST v2 and the OAuth 2.0 Introspection specification. IS can now authorize OAuth2 tokens issued by third-party identity providers like Ping Identity and Okta.
The ability to generate Swagger from a REST service in Webmethods has been around for a while - although it's been far from bug free. I was keen to see if this was resolved, but more importantly I prefer to develop "contract first" so the import capability is a big selling point for me.

This blog covers my first impressions - and sadly some of the issues I've …

I started working in the integration area in 2007 and have worked
on more than a dozen integration projects. I’m now venerable enough to have seen
what was once best practice become old hat, or even (the worst pejorative of
any transformation project) “legacy”. So, what has and what hasn’t changed?
That was the way it was
When I started my integration career Webservices were in
full swing and SOA was close to the peak of the hype cycle. The future was to
be business logic exposed as re-usable services, using open standards such as
WSDL and XML. Open standards were everything, and the standards bodies W3C and OASIS
(Organisation for the Advancement of Standards in Information Systems – if I
remember rightly) were publishing an ever growing canon of WS-* specifications.
The common ones were of course WS-WSDL, and WS-Security; but then came
WS-Eventing, WS-ReliableMessaging, WS-Trust, WS-Policy, WS-Notification,
WS-PolicyAssertions, WS-Discovery, WS-Addressing, WS-Topics, WS-Enumeration…

A decade after working on my first Integration project, I’ve
been reflecting on what changed and what hasn’t. My last
post focussed on how things were then, and what technology and techniques have
fallen away; but there is as much common as there is different. Much “best
practice” in 2007 is still good now, and sadly some of the challenges I saw
then are still to be truly addressed.
Open standards
A big theme of the early 2000s was a push to use open
standards - although older colleagues may point out that CORBA predated this.
In my “what changed” blog I took a rather tongue in cheek attitude to the
myriad of WS-* standards; but although this trend got a little carried away, it
was essentially a good thing.
Back then committees decided standards, now a more Darwinian
“survival of the fittest” Open Source approach has taken hold. Standards are
still open but rather than a compromise several potentials emerge, then one -
or perhaps two - win out. This was seen when Swagger,
and to a l…