My grandfather has a bumper sticker on his pickup truck that says “He who dies with the most toys, wins.” Since my world revolves more around API Management than collecting die-cast models of John Deere tractors, I have my own version of the saying – “He who has the most context wins.” Context has always been an important part of managing data or applications, but the proliferation of enterprise B2E (business-to-employee) and B2C (business-to-consumer) mobile apps has significantly increased the need for context-based policy.
The Layer 7 family of API Gateways has always been good at context. Not only does a Gateway have access to the full request and response content, it can also access header content (from a wide variety of protocols) and transaction metadata (latency, source information etc.) Then it adds in user credentials and attributes retrieved from the request and backend identity management systems. These inform decisions around access control but also around traffic routing, prioritization, rate limiting, quota fulfillment etc.
However, mobility introduces a few new entities to the equation, all of which have to be taken into account for ideal contextual decision-making. The first is familiar: users; but mobile users might have additional attributes that come into play. Phone number and email become more important, since they provide other connection points accessible to the user on the same device (smartphone, tablet etc.) The inclusion of social login – available in the 2.1 release of our Mobile Access Gateway – provides social graph information that might also have relevance when deciding how a user request should be processed.
The second entity providing contextual attributes is the app itself. An app ID or API key can tie an application back to the developer who created it. Signer information, permissions and other internal details can give context around existing app security. The Mobile Access Gateway can collect some of this information using our Mobile SDK and more data can be gathered via integration with CA (or third-party) MAM and MDM products.
The third important entity is the device itself. Not only can APIs be tailored to return data structures specific to a screen size or even a specific device type but behavior can also be tracked to a single device ID to analyze the risk involved. There might be more risk delivering sensitive data to a family iPad than there would be on a personal smartphone – or to a phone in an airport rather than a laptop in the office. This level of risk (and the associated response) increases dramatically when interacting with an unlocked device rather than one locked down by corporate security policies.
In my new role across the CA Securecenter product line, I’ve focused quite a bit on the integration of Layer 7 with other CA products. The result has been a flood of new contextual information with which to make richer decisions. Gathering risk profiles from CA RiskMinder or data categorization from CA DataMinder provides an even stronger understanding of who is trying to access what, from where. And the decision made from this context doesn’t necessarily have to result in a thumbs-up or thumbs-down; with CA AuthMinder, suspicious requests can simply require an additional level of authentication.
Every industry has its own variables, vulnerabilities and potential optimizations. Our goal is to give customers the right context with which to make the best decisions for their specific use cases. Our rich interface management capabilities and strong integrations with other proprietary and standards-based mobile technologies give us the best palette of access control and policy options in the API Management industry. In a world where context is king, we’re continually fighting for that crown.