Security Centralization

How can security-related logic be abstracted and centrally maintained?

Problem Processing logic associated with generic security functions and custom security policies often needs to be repeatedly carried out by different services, resulting in redundancy and governance challenges.
Solution Security-related processing logic is abstracted into a separate framework of specialized utility services.
Application Depending on the nature of the SOA implementation, a centralized security framework can consist of a combination of Web services, custom and system service agents, and proprietary products.	Impacts A single point of failure can be introduced for the entire service inventory, and it may be challenging to establish a single security framework that can accommodate the range of required security requirements.
Principles Service Reusability, Service Composability	Architecture Inventory

Table 6.22 – Profile summary for the Security Centralization pattern.

Problem

One functional requirement common to most services and all service inventories is that of security processing. A variety of security-related functions can exist, many of which need to be repeatedly carried out within compositions and individual data exchanges.

Having individual services encapsulate this type of logic can lead to a great deal of redundancy and architectural inconsistency. Although some common functions can be isolated into dedicated utility service capabilities, the complexity and specialized nature of some security requirements can make this approach inadequate.

Figure 6.98 – A variety of security-related processing functions are common (to varying degrees) across most members of a service inventory (regardless of service model).

Solution

A centralized security framework is established in support of a service inventory as a standardized architectural extension. The framework is comprised of a combination of security technologies that address a range of security requirements, including the centralized maintenance of security policies.

Figure 6.99 – The centralization of security processing logic establishes a framework of related services, agents and programs that perform common security functions.

Application

How Security Centralization (also known as Service-Oriented Security Architecture) can be applied is dependent on the implementation options provided by the chosen vendor platform(s). Typically, security processing is abstracted into a dedicated layer consisting of service agents, system services, and the messaging framework itself.

When services are delivered as Web services, this pattern can be achieved via a centralized implementation of security-centric utility services. A common example is an authentication agent that authenticates and authorizes service consumers on behalf of other Web services.

Impacts

Establishing a centralized security framework can be exceedingly complex. There are a variety of security-related processing functions that need to be standardized, coordinated, and delivered in a manner that is adequate for a range of service interaction requirements.

Furthermore, as with other centralization patterns, isolating critical processing functionality introduces a single point of failure that can bring down an entire inventory of services. The reliability of the centralized security architecture therefore needs to be well assessed.

Relationships

Centralized security logic can create a specialized form of utility service, as per the Utility Abstraction pattern, and may also require Legacy Wrapper for the encapsulation of legacy security extensions.

Many modern-day security features are implemented via the application of the Service Agent pattern, especially those that process messages with embedded security intelligence.

One of the closest potential relationships, however, is with Message-Level Security. In Web services-based architectures, the WS-Security framework provides the opportunity to centralize security logic by leveraging industry security standards based on a message-level application.

Finally, any products or platforms used to accommodate the physical centralization of security logic can be further regulated via the Canonical Resources pattern to avoid unnecessary disparity, especially when security utility services are shared across inventories (as when the Cross-Domain Utility Layer pattern is employed).

Figure 6.100 – The Security Centralization pattern strategically positions security logic within an architecture and can be responsible for a specialized type of utility service, resulting in relationships with security and utility-related patterns.

Case Study Example

Case study content is not available on this Web site.