Over the next several posts, I will explore some of the core patterns for Service Gateways that provide access to Enterprise Mobile Applications that need to leverage enterprise apps and data. Before I go there – a word about risk. Mobile security is a hot topic. Is Android less secure than iOS? What about rooted devices? How should enterprise deal with BYOD? How do mobile dev teams write secure code for mobile platforms? And the list goes on and on, there are plenty of important questions to ask.
Amidst all these gnarly big and small questions on technical security for enterprise mobile applications. its vital to remain focused on risk. And where is the risk for enterprise mobile applications? On the apps, identity, and data housed on the numerous mobile devices? Sure. There’s risk on individual mobile apps and devices, but the lion’s share of data, functionality and identity is on the server side, and that’s where the lion’s share of the risk is too.
Boundary crossings are a key focus area for security architects. The Enterprise Service Gateway defines the boundary between “external” systems and “internal” systems (note – I am not sold that this is a valid distinction in many instances but its commonly used and holds up for the purposes of this pattern). The transition between external and internal confronts the security architect with a number of design choices. We can divide the message exchanges into two sets
1. Mobile device -> Gateway: asynchronous Web service calls via REST
2. Service Gateway -> Enterprise backend app servers: synchronous and asynchronous calls via REST, JMS, SOAP, and more
The inbound calls to the Service Gateway usually follow a simple message exchange pattern (albeit its asynchronous which is something new to many enterprises but we’ll save that for another day), whereas the Gateway -> Enterprise message exchange patterns can run the gamut. In effect, the external services simplify the experience for the user and the internal services- well they just go where the data is.
The implications here shed light on the core utility of the gateway. The gateway is the location to implement three sets of security policies.
1. External security policy: for the Mobile device -> Service Gateway message exchanges
2. Internal security policy: for the Service Gateway -> Enterprise backend message exchanges
3. External <-> Internal mapper security policy: to facilitate the right security and identity services for each boundary transition
Security is about reducing vulnerabilities (access control services) and coping with threats (hardening, defensive services). Service Gateways play a key role in each.
In the case of access control and identity services, the identity protocols and tokens that are used by the mobile device are usually validated and terminated at the gateway. The gateway then maps the relevant user identity, such as username and attributes, and instantiates a second protocol to communicate with the enterprise backend.
In the case of defensive services, enterprise applications are not hardened for external access, after all that’s why there is a DMZ. Inbound calls, messages, and data must be inspected for malicious code targeting the enterprise. In effect the Service Gateway is what enables the internal services to be consumed externally.
To make sure mobile security is effective, from a big picture, strategic perspective its important to keep in mind the vital role of the gateway in managing risk on both the mobile device and the enterprise backend. To execute tactically its important to divide the Gateway’s role in to how it works for each separate policy zone, and how it maps between the zones. So many projects, start out assuming that mobile is just another front end to hook up to existing middle tiers – it isn’t. To get an idea on some key differences, I highly recommend this Mobile Middleware White Paper as a solid read for more on the subject. In the next post we’ll look at some policy options for each zone.