The Federation Oriented Architecture

The services oriented architecture (SOA) as an application development approach is definitely here to stay. There are multitudes of sites out there explaining the benefits and approaches for delivering upon the promises of SOA. In looking at some of the challenges that I have seen with our customers, I believe that there is an opportunity to improve upon not only the capabilities of SOA, but also the ease of interacting with these web services. I call this the Federation Oriented Architecture (or FOA if you like). Another way to describe this could also be Context Driven Web Services or even an Information Network. Basically it comes down to the idea that you can give identity to more than just users. The same logic that we can use to move user information around through federation to partners can also be applied to application data.

FOA is comprised of the following three pieces:

FOA Components
  1. SAML interface allowing the application to identify itself and retrieve information from the information network. This could be based upon a tool like PingFederate or CA Federation Manager.
  2. Virtual Directory that instead of being used solely for correlating user information is also used to correlate and transform data from information sources across the network. Radiant Logic’s RadiantOne VDS and ICS technology is a perfect match for what is needed here.
  3. Identity Based Encryption (IBE) interface to secure information between applications. This allows the application to encrypt data for the receiving application without knowing its public key. It can make the data accessible for only a specific period of time and applications can easily be “unauthorized” from the network.

At a high level, here is the general flow in delivering a federated application:

  1. On startup applications register with the Virtual Directory and assert what type of information they know.
  2. When another application requests information, it sends a SAML Attribute Query to the Virtual Directory attribute service and identifies itself to the federation web service.
  3. The Virtual Directory checks to see if the application is authorized and if so passes on the attribute query to the registered application(s) that owns the information.
  4. If necessary, the Virtual Directory can pull data from multiple sources and perform correlation and transformation operations as needed.
  5. The application owning the information encrypts the data based upon the policy defined in the Virtual Directory using Identity Based Encryption public parameters (e.g. application name) without needing to know the requester’s public certificate. An example policy could include: encrypt this information for application A, it is only valid on the network for 5 minutes, etc.

Most of you are probably asking "how this can help me be more successful?". The following details outline some possible approaches for FOA and some things to think about along the way. So why am I even talking about this? Isn’t my background in identity and access management? Well, yes. However, a user identity is really no different than the other information you have in your environment. The same things you need to know about users to effectively allow them access into your applications (verified identity, user attributes, etc.) can be said about the applications themselves.

Here are some of the challenges I saw our customers running into:

  • Significant investments in building out atomic services to form the foundation of the catalog of available services
  • Application logic required reverse engineering since many times the original application or data owners were no longer there or the application was undocumented
  • Security risks due to either having to implement security within the services directly or by using complex (and potentially expensive) SOA security solutions

Now there are many ways to address these challenges, but what I assert is that by applying the same logic we use to federate user identities to partner organizations, we can create a federation model for applications themselves, reducing complexity and improving availability.

Here are just a few of the benefits of this approach:

  • Applications do not need to know which services to call to request information.
  • Unifies data across the network and applies business logic to transform the information as required without having to code this logic into the application or web service.
  • Minimizes propagation of information to only approved applications.
  • Allows centralized control of ability to request and read data with ability to revoke data rights to an application.
  • Provides the ability to build information policies that specify data usage including validity period, application access, etc. which increases security and lessens data proliferation.

Instead of focusing on breaking down the applications into services, why not leverage the applications themselves to provide these capabilities? Think of the applications as users that already know how to process the information and apply the business logic. In essence, they are expert users of your data. An application knows certain things and with FOA you empower the application to go out and ask the other expert applications for additional data. All of this can be done using the same principles used to build out federation capabilities for your users and in many cases using tools which you already have in your environment. As an example, if you take a tool like PingFederate, you can apply the same logic used for Internet SSO to application communication through standards-based SAML communication. Leveraging SAML, applications can basically securely assert who they are and what information they know.

While using SAML for application communication is a good first step, that in and of itself is not enough. The applications still need to know where to get information, what attributes are available, etc. Enter the virtual directory. The virtual directory allows you to create a centralized hub for requesting information from the web services out on the network instead of having to understand which services to call directly. By leveraging the virtual directory as the centralized access point for web services, you gain the following:

  • Centralized access to all web services into a single point delivery providing service discovery instead of service cataloging.
  • Virtual views of the information creating a mapping between the data and the context relevant to that information.
  • Transformation logic so that data is represented as needed by the requesting application.
  • Ability to cache information at the virtual directory to improve performance.
  • Tight mapping of between the requesting application, data and the identity of the end-user.

So, what we are doing is basically enhancing the SOA “object oriented” approach with a real life representation that understands the relationships between the objects and the context in which those objects are being used. Additionally, we can use these relationships to make decisions about the likelihood that an attribute matches what the application is requesting. Perhaps an application requests “middle initial”. The virtual directory can predict that there is a high likelihood that “initial” is the same data point as “middle initial” and depending on the threshold for error, can return that information to the requesting application.

Breaking this flow down, the Federation Oriented Architecture is represented by the following:

Federation Use Case
  1. The applications send a SAML 2.0 POST assertion to the Federation Web Service running on the Virtual Directory which contains application identity information and list of known information attributes
  2. Application identity and credentials are passed to Identity Based Encryption (IBE) key server
  3. IBE server returns application specific private key
  4. The virtual directory registers the application by creating a branch for the app with the list of know attributes as directory entries under the application’s branch
  5. The private encryption key is returned to the application which completes initialization
  6. User accesses an application to view an order
  7. The order fulfillment application makes a SAML attribute query for the customer name to the Federation Web Service running on the Virtual Directory
  8. The Virtual Directory queries the applications branch to find a likely match for the requested information and identifies that the CRM application contains the company name
  9. The Virtual Directory forwards the attribute query to the Federation Web Service running on the CRM application
  10. CRM application returns customer name to Virtual Directory and encrypts it so that it is only readable by the Virtual Directory and the order fulfillment application
  11. Virtual Directory caches information and returns customer name to the order fulfillment application

So, how can you begin to think about utilizing this type of an approach? Well, two quick use cases jump to mind (there are many more):

Intra-company application hub

  • Unified offering combining a Virtual Directory, SAML integration libraries and IBE key server
  • Sold as packaged product that allows companies to quickly integrate applications
  • Could be appliance-based to speed deployment

Federated Application Hub (Internet Application Hub)

  • Software as a Service solution allowing companies to securely share information both internally and across the internet
  • Multi-tenanted system with web-based interface to manage setup and information policies
  • Information can be shared only with trusted partners or can be made publically available as needed
  • Requires no additional in-house infrastructure

Basing this on a virtual infrastructure makes this readily consumables as a way to provide services on a per customer basis and lends itself to a out of the box multi-tenanted architecture. Since the virtual directory can process both application and user data, you can simply create a view into the information by individual/group/organization etc without having to specifically code this as multi-tenanted

Hopefully this provides a solid overview of the approach. I am definitely interested in hearing feedback and ideas. As this is further clarified, I will post additional information.

Thanks,

Todd