This last week was spent developing a proof of concept the integration of an "Authorization Authority" into our service framework. I wanted to share the general messaging approach of the POC, while I work on cleaning the .NET solution up enough to post in it's entirety.

There are four messages represented in the Authorization Authority use case scenarios. The first two are the request / response pair demonstrating communication between a service consumer and the Authorization Authority. The second two messages are the request / response pair demonstrating a consumer to service provider communication.

The first message is the test client (consumer) calling the authorization authority to request a particular user’s authorization credentials. The message is in the form of a SOAP envelope and is signed by the consumer as a means of allowing the authorization authority to authenticate the requesting application. The key data provided in this example is the end user’s user ID.

The second message is the authorization authority’s response to the authorization data request. The response comes in the form of a custom XML element named “sasauth:Token”. “sasauth” is the prefix representing a custom SunGard namespace (http://www.sungard.com/servicemanagement/authorization). Inside that “Token” element, we have encapsulated a SAML assertion document. The entire “Token” element has also been signed using the XML-Signature enveloped signature transform. This allows any application to trust that the “Token” element was originated from the authorization authority, and has not been tampered with at any point since the issuance of the token.

The third message demonstrates the inclusion of the “sasauth:Token” within the WS-Sec node of a SOAP request. The body of the message is also signed, and that signature is included within the WS-Sec node as well.

The fourth message shows a simple SOAP response document. However, the content of the result value is significant, in that it demonstrates the generic service evaluating the SAML assertions contained within the “sasauth:Token”.

I came across the following site, which appears to be Verisign's contribution to the SOA Security field. They discuss the XKMS, SAML and WS Signature specifications, which just happen to be the same specifications that I'm doing my current research on.

XML Trust Center

I just found this page: Samoa: Formal Tools for Securing Web Services.

It's the Microsoft Research project that focuses on implementing newer advances in security within a XML web service world, and the page contains a fantastic set of resources on the topic.

I'm working towards two major implementations this week.

First, I need to come up with a good model for service-based public key distribution, registration and revocation. We need to get something that can help us manage a fairly dynamic PKI environment as efficiently as possible. Another challenge is to be sure that the implementation supports applications written in both .NET's C# and Java. As a start, I believe that the XML Key Management Specification (XKMS) is the right place to begin my research. The specification appears to support the major functional requirements that we have for the system, and I was even able to find some help getting a .NET web service version of the protocol running in this article: Implementing XML Key Management Services Using ASP.NET.

Second, I need to come up with an approach to handle SAML-like (if not actually SAML) assertions within that same environment. I don't have quite as much research completed on this task, but I will be posting my thoughts and findings as I get around to this implementation.

Introduction

With this document, I wanted to present a brief overview of a concept for creating a Service Oriented Architecture (SOA) within a service provider's management infrastructure. I also thought it necessary to provide some of my personal thoughts about how the problem should be defined and how the SOA should be structured within that type of environment.

Although our approach has been of a non-formal nature, we have taken several significant steps towards implementing a more loosely coupled architecture for our applications. The first step was in the conceptualization of what the architecture would look like. Admittedly, this is the first time that I have put the approach down on paper, but the concepts have remained stable in our conversation and thought. The second step we have taken is in the establishment of a design pattern that we intended to use within all web services that we had developed. Lastly, we have developed several web services that currently run within our production infrastructure. At this point in time, there are approximately thirty web service endpoints running as production applications, instantiating one of our six custom-developed service applications.

Defining the Architecture

Within the global system architecture community, there is quite a “buzz” around the concepts of SOA. To date, the best definition that I have found for SOA is proffered by Scott Rosenbloom, of WRQ Inc:

"SOA is a framework enabling application functionality to be provided, discovered and consumed as re-usable Web Services sets. While Web Services do not equal SOA, it's one of the enabling standards. SOA abstracts complexity and implementation details, making it an ideal architectural mindset to leverage functionality trapped within mainframe/midrange systems."

Scott Rosenbloom is chief strategist with WRQ Inc.

This is a definition that I completely agree with, and one that I believe would serve us well as our modus operandi for all discussions related to SOA.

Baseline of our Requirements

In order to have a meaningful discussion on the quality or appropriateness of any architectural approach, a set of required business functions needs to be defined. This section is intended as a starting point from which to define this requirement set.

In the case of my company's environment, the business functions are able to be separated into two primary categories: Business Support Systems (BSS) and Operational Support Systems (OSS). Based on our group’s traditional role of supporting OSS systems within the company, I will focus on the OSS category of business functions below.

At a high level, I define the OSS functions as those business and technical processes that perform service provisioning, service management, service decommissioning and service quality assurance. Within that definition, some of my company’s core OSS functions can be categorized a bit more tactically:

1. Ticketing
2. Document and Knowledge Management
3. Monitoring
4. Internet Infrastructure Services
5. Configuration Management
6. etc...

Within each of the tactical functions, there is a matrix-ed set of requirements that help describe the core sets of features that any application must support. They include:

1. Provisioning
2. Daily Use
3. Monitoring
4. Quality Assurance
5. Decommissioning
6. etc...

The Architecture at a Glance

The proposed architecture is made up of four distinct application sets: User Interface Points; the Service Web; SOA Services; and Customer and Infrastructure Elements. The graphic below depicts each of these application sets and some example components within each:

The first is the User Interface Point set of applications. These are the tools used by end users of the systems. They provide a wrapper around the second set of applications that allows for consolidated end-user security, consistent look-and-feel across the functionality and some level of orchestration among the services being used. To me, it is logical to think of these interface points not as a single application, but a suite of applications tailored to the needs of each user constituency. Deciding what this set of applications looks like in implementation should be based on the study of a combination of the technical architectural needs of the enterprise with a study of each user community. (As an aside, I am a strong proponent of the intension-based design approach to making user interface design decisions.)

The second set, which I have named the Service Web, encompasses the functional services themselves. These services are the building blocks that make up the overall systems used to support the enterprise, and perform the majority of the actual “processing” within the enterprise. Many of these services are interfaces into data storage systems (persistent and non-persistent), wrapping the complexities of the underlying data into simplified sets of message-based requests/response pairs. And because of what our business is, these services may also interact with the customer and infrastructure environments.

I have categorized the functions required to support growth within the web as the SOA Services set of applications. These are the applications that can help us better support the development, deployment and maintenance of the Service Web, potentially protecting us from many of the problems inherent to a coupling index spike. Functions such as authentication; authorization; certificate management; name resolution and management; and service description and discovery are at the heart of this application set.

Lastly, I have defined a Customer and Infrastructure Environments area of the architecture. This is not necessarily a set of applications in the same sense as the other areas of the architecture (although applications are certainly a part of it), but it represents the things that we manage for our customers.

One additional point about the above categorization of elements within an SOA is that any application can reside within more than one of these categories. As an example, name services can be fulfilled by an implementation of BIND that includes not only traditional DNS protocol interfaces into the application, but an XML Web Service wrapper around some of the management functionality. This type of application would serve as both a SOA Service and as a member of the Service Web. When designing, developing, deploying and managing that application, looking at it from both perspectives will yield a much more productive member of the overall architecture.

While I have described the Service Web as exactly that, a web of services, another architectural principal that I believe is important to consider is the rate of growth in the inter-service coupling index. Basically, this index is a measurement of the complexity of the Service Web. As more and more applications begin to act as both service consumers and service providers, the index grows. As this begins to spike upward, we will need to be cognizant of the increase in failure points throughout our applications.

Architectural Perspectives

Since perspective is so important to the representation and definition of a technical architecture, this document will examine two primary perspectives, and discuss how the elements interact within those perspectives.

Example Consumer Perspective

The first perspective to look at is the service consumer’s perspective. Specifically, the perspective describes a user interface type consumer application. This simplifies the perspective, by not introducing any “service” qualities to the example consumer.

Within the consumer, there are three primary functions: the actual user interface; the internal application logic and service orchestration; and the SOA Service client functions.

The user interface is exactly as it seems. It represents the thing that the end user interacts with, be that a web page, desktop application or other client technology.

The internal application logic and service orchestration component represents the elements of the consumer application that manage the user interface’s control flow logic, initial validation logic, and coordinates the use of each of the target services.

The SOA Service client functions are all the functionality that are considered part of the SOA required infrastructure. This includes the client’s use of authentication and authorization services; required logging and non-repudiation controls; as well as the use of all the other services provides as part of the SOA Service application set.

There are two important points to be made with this perspective. First, the use of the SOA Services infrastructure should be standardized and implemented as completely as possible in a reusable way. This will make enforcement of the architectural standards (for various reasons) much easier, and help the development teams focus on the application’s core requirements.

The second point is that there is a certain level of orchestration and flow control within the consumer application. What remains to be considered though, is if there should be a more dedicate approach to the orchestration and flow control problem domain. This is an area that I believe needs serious consideration.

Example Service Perspective

The second perspective that is highlighted is the perspective of an example service. As with the example consumer, the service’s internal workings can be broken down into the three functional components: the service’s interface; the service’s functional logic; and the service’s use of the SOA Service application set.

The exposed interface is the interface that the service makes available to all potential consumers. This is the place where design concepts like service autonomy and message-based interactions are extremely important.

Next, we have the service functional components. Like the internal application logic and service orchestration portion of the consumer application, the example service contains code that actually performs its required function.

Lastly, the SOA Service functional components include the service-side logic required to use each SOA service. As an example, if a service requires that all messages received are signed by the consumer application (using a valid certificate) then the service would need to implement the validation logic to confirm that the message is signed, the message has not been altered, and that the certificate used to sign the message is considered a valid certificate. Again, these components should be developed as reusable classes that can be plugged in at either development-time or deployment-time.

This is where we were:  http://home.comcast.net/~ajsphila/SB05/