Identity is the New Perimeter
It was Bill Gates who said that security should be based on "policy, not topology". It's a phrase which always stuck with me. Rather than basing security on where something is, you use a policy which is independent of the network.
Identity is a key part of security policies. We make decisions on who the user is, where they have logged in (their identity provider), and their attributes.
I've put this into a diagram below. On the left, you see the old security perimeter, with "good guys inside, bad guys outside". On the right, you see the the new architecture, where an organization has mobile workers, and employees who expect to use Cloud-based services like SalesForce.com just the same on-premises apps.
In the architecture on the right, security is based on identity, not on the perimeter.
APIs are key, both for the mobile and Cloud cases.
For mobile apps, it's important to provide the mobile backend which is the API layer that links mobile apps back into internal systems. A mobile backend exposes APIs which are consumed by mobile apps. It is at the mobile backend that rules based on identity and data validation are applied, as well as where the audit trail is written. Identity standards such as OAuth allow identity to be brought to bear for mobile users.
Employees expect to use Cloud-based services such as SalesForce.com side-by-side with internalsystems. The old perimeter model simply does not apply here. SalesForce is outside “the perimeter” but users must still be able to use it. Again, the solution lies with Web APIs. An API layer allows organizations to apply identity-based controls to SalesForce usage, plus data validation, and an audit trail.
Identity standards are key to the new perimeter. By using standards such as OAuth, you can based security on "policy not topology" where the policy is dependent on the client identity. This goes for connections "going out" (on-premises to Cloud) as well as connections "coming in" (mobile to on-premises).
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)