The New Corporate Perimeter

Two days ago I blogged about Cardspace RIP. Long LIve Claims Based Access Control!

The post considered that Cardspace was a technology that enterprises needed, but did not realize they needed it yet. Let's face it, not every enterprise has a James McGovern as their architect.

I predicted that Cardspace would be like Sun's effort at distributed computing: JINI, that did not take off, but was quickly followed by Web services that boomed and boomed and boomed to this day.

Looks like I did not have to wait long: Richard Bejtlich tweeted from a security architect he works with: "Identity is the new corporate perimeter. You're reinventing the Internet at layer 7."

Eeeexxxxaaccctttllllyyyy. (that was me exhaling from seven years of pushing this particular rock up the hill)

Now far be it from me to wonk-ify a catchy phrase like the above, but I would add that Identity policy domains define the new corporate perimeters. Notice policy domains and perimeters are both plural. Identity is an active state, a negotiation and contract of responsibilities between Identity providers and Relying Parties (Service Providers). So when thinking about these new corporate perimeters, that is a critical first step, the 1995 DMZ architecture was static - inside the firewall or outside the firewall.

Identity based perimeters are dynamic, perhaps on a per request basis. The Identity Factor paper I wrote with Patrick Harding from Ping looks at some of these issues in more detail. The point about policy domain is that the policy contract is where the communication channel, token issuers, authentication scheme and other authorization rules form the rules the govern creation, inflow and outflow.

In my paper on Cloud Security Architecture stack - Don't Trust. And Verify.  I defined four patterns that form the core for security architecture going forward, a new corporate perimeter if you will. Of the four patterns, two deal explicitly with moving identity information around and providing fine grained contextual access - Security Token Services and PEP/PDP (XACML-style).

The other two services are defensive hedges against unknowns- Monitoring and Gateway.

Both types of services IAM and Defensive services are delivered today under the heading of "security", but they could not be much more different. The identity services are all about pushing the enterprise to take risks to get new business (Mobile) or drive down cost (Cloud). Defensive services lack this approach, because they are in effect facilitating the fire department and response activities. 

How you staff for these, tool for these and measure these services is starkly different, but they all roll up to InfoSec. As the new corporation evolves so must the new corporate perimeter.

Here is a concrete example of the above, which I will have more to say about in future posts.

Last week I blogged about how new Mobile apps mean new Mobile architectures. 

Mobile is a new architecture. Many times companies start a Mobile project by putting a Mobile client onto the existing list of clients like web apps and web services. But as these projects and deployments scale out, there is generally a specialized middle tier for Mobile that supports ocassionally connected sessions, content caching, and other optimization for Mobile environments.

Mobile needs a new security architecture. Related to the above, we have different deployment types and so need new security protocols - the types of security tokens, the way sessions are managed, and integration with the client all require a new approach from Infosec, its not same old same old web app security.

Focus on Apps and Data. Perimeter? What perimeter? Even the most casual observer knows that Mobile is the final nail in the outmoded "inside the firewall/outside the firewall" mentality. Data and functionality are on the move, and security needs to keep up.

I have been surprised that Android continues to ship without any security model for talking to servers and Web Services. The Android team has done a good job in many areas, but this is a Grand Canyon sized over sight. Hello? How does the server know who is calling?

So instead of shipping a simple Android enabled with SAML or oauth they have left developers to fend for themselves. And as you might expect some have and some haven't. (Again - its 2011 whyohwhy are people expecting developers to write their own identity???)

But as a SciFi writer might say - virtual is the new real. Who steps in to address this particular problem? Salesforce. com! Of course, they have long experience dealing with consuming tokens from all manner of enterprise directories and protocols, and are keenly aware of why standardization here matters a lot.

The first part that matters is the separation of the authN and the authZ protocols. This is something people did on occasion before, but with Mobile its mandatory. You simply cannot afford to mismanage user secrets with the way Mobile apps are built and deployed.

In this case the consumer authenticates to the SP (salesforce) and gets issued a consumer key but not the consumer secret.

The consumer's key gives them a token to enable access. The consumer never authenticated to its mobile device, but she has been issued a token that can be used for making authorization decisions on the server side. Its a new corporate perimeter indeed.

Comments

[Steve_Lockstep]

Gunnar, I agree strongly with you about the importance of coprorate identity policy. Corporate identity has always been critical, even sacrosanct. "Identity" is the way I am know by a business. Identity in each context separates the people a business knows from thos it does not. It has always been thus. So identity is not a "new corporate perimeter"; it is age-old perimeter and very hard to break down in federated identity schemes!

See http://lockstep.com.au/blog/2011/02/03/evolved-identity

Cheers, Steve Wilson.