1. External security policy: for the Mobile device -> API Management Layer message exchanges
2. Internal security policy: for the API Management Layer -> Enterprise backend message exchanges
3. External <-> Internal mapper security policy: to facilitate the right security and identity services for each boundary transition
Gateways and API Management have many, varied capabilities. They can play several different roles in an enterprise security architecture. To tie this down to something useful for a real world deployment, it pays to be specific – not just a laundry list of WHAT a API Management Layer can do, but WHERE in the architecture it acts. In this post, let’s drill down into some specific concerns that can be addressed by the Mobile API Management Layer in these zones.
Zone 1. External security policy: for the Mobile device -> API Management Layer message exchanges
The old chestnut “trust but verify” is no longer valid, better way to think about this boundary is – “Don’t Trust. And Verify.”
The API Management Layer should not “trust” that any old client (SSL or otherwise) that sends data is AOK, the communications, user and application should be authenticated and authorized. In addition, the data and usage should be verified.
Getting down to brass tacks, there’s a steady drumbeat towards OAuth as an external protocol for mobile. From Cloud vendors like Salesforce, platform providers like Google and enterprise applications are all moving in this direction – OAuth as a standard token type and protocol for Mobile apps.
Lastly, this zone should record (to an audit log monitor and/or SIEM) the details of the transaction.
Zone 2. Internal security policy: for the API Management Layer -> Enterprise backend message exchanges
OAuth has emerged as a de facto standard for mobile apps, but inside the enterprise you can expect a Noah’s ark approach to identity – Kerberos, X.509, SAML, proprietary and custom. The external policy insulates the mobile client from having to deal with these many protocols, but the job falls to the API Management Layer to implement these interfaces.
This responsibility means many burdens for the API Management Layer including consistent naming, refreshing certificates and connections, protocol specific configurations and mapping, dealing with latency, error correction and retry and a host of other connectivity issues.
As to verification, the malicious code issues should be handled by the upstream (external policy). For most apps its not likely necessary to duplicate these checks, note that there could be some areas like callbacks and asynchronous messaging where further granular checks can only be done after an initial inbound call, though. The main verification step to be aware of at this level is to ensure that the authorization maps from external to internal which brings us to:
Zone 3. External <-> Internal mapper security policy: to facilitate the right security and identity services for each boundary transition
This mapping keeps the control of the enterprise object mapping on the server side. Abstracting it away from the client is helpful for developers (only having to deal with external API not enterprise hodge podge) and security – avoids vulnerabilities like Insecure Direct Object Reference. This process can be made stronger by having the mapper issue and verify a nonce (unique code) per instance, to defend against replay and other attacks.
In the next post, we will look at client side integration issues – how to communicate with the API Management Layer