The Anywhere Application Architecture

With this post, the long tail of commentary from the European Identity Conference continues. I came up with the term Anywhere Application Architecture while preparing my EIC keynote as it captures a number of principles that architects must consider when deploying applications. Today, applications and the supporting infrastructure must be able to run anywhere – and be mobile enough to transit between on premises data centers, private clouds, and public clouds. Below is a graphic that represents this approach, from an authorization perspective.

Here’s how it works: A typical authorization service is depicted in the lower part of the graphic; it is comprised of a policy enforcement point (PAP) policy decision point (PDP) and policy enforcement points (PEP). In addition, authorization policies represent the business and security rules to be enforced and necessary attributes are retrieved through a policy information point (PIP) interface.

The traditional deployment of an authorization infrastructure is to install it on premises alongside applications in your enterprise’s data center. A PEP would be typically integrated with your application (App A in this case). If your enterprise utilizes a private cloud hosting a web services application, then XML gateways can serve as a super PEP to secure access to web services (in this case Service A).

If you are running workloads in the public cloud, the same authorization infrastructure can be extended. In our example, the XML gateway can protect publicly hosted web services (Service B) or you can choose to implement a PEP in the cloud (Service C). Finally, you may also choose to run part or all of your authorization infrastructure in the cloud – depending on the usage scenarios or requirements of your applications and users.

To reiterate, security architects and application planners must prepare for workloads that can run in the data center, in private clouds or in public cloud scenarios – and they must be able to accommodate moving workloads between these environments. Therefore, your IdM infrastructure must have the same flexibility characteristics. In this example, we’ve shown you how an XACML-based authorization system fits the bill. By the way, this approach integrates extremely well with a federated model as the authentication approach. Then you can also accommodate users that are located anywhere!

Explore posts in the same categories: Authorization

3 Comments on “The Anywhere Application Architecture”


  1. […] The Anywhere Architecture is about deploying services and connecting to users and data wherever they might be and enabling these interactions securely. Of course, in such a distributed environment, security needs to be rethought from the ground up. This goes through federated identity, trust establishment, externalized security, and flexible authorization to name but a few items. (More on Gerry’s blog) […]


  2. […] authorization capabilities in pretty much any architecture (see Gerry’s post on the ‘Anywhere Architecture‘). If XACML, on the other hand, specified within the core of the standard how to bind a […]


  3. […] talked previously about the XACML Anywhere Architecture where a callback from a Cloud Provider queries PDP; this would enable the Cloud Provider to get the […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s