SOA security 1-2-3, Part 2: Create a high-level design that everyone can use

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

John R. Betancourt (john.betancourt@gmail.com), President , Intelleges

28 Aug 2007

Examine a service-oriented architecture (SOA) security implementation road map in this series. This article—the second in a three-part series—provides rules for assisting an SOA security team in developing a successful high-level design.

SOA security implementations, like SOA in general, should be viewed as a long journey. As with any journey, you'll need certain items if the trip is going to be successful.

Part 1 of this series focuses on the road map, which provides a simple, 10-step process that serves as an overall guide for an SOA security team. In step 7 of that process, "Follow an SDLC process for an SOA security implementation," the SOA security team produces the high-level design (HLD)—the Holy Grail—of any SOA security implementation. In this step, the SOA security team is expected to follow the Software Development Life Cycle.

Software Development Life Cycle

The Software Development Life Cycle (SDLC) typically consists of four stages:

• Requirements
• Design
• Coding
• Testing

The objective of the second stage in the SDLC—the design stage—is to produce the overall design of the system. The design stage includes two substages: the HLD and the detailed-level design (DLD). For the HLD, you as the security enterprise architect (SEA) review the SOA security implementation's functional and nonfunctional requirements and design an overall solution architecture. Like the enterprise architect (EA), the SEA is responsible for:

• Recognizing common paradigms so that high-level relationships among systems can be understood and so that new systems can be built as variations on old systems.
• Getting the right architecture, which is often crucial to the success of a software system design. The wrong architecture can have disastrous results.
• Having a detailed understanding of software architectures that will allow the team to make principled choices among design alternatives.
• Providing an architectural representation, which is essential to the analysis and description of the high-level properties of a complex system.

The bottom line is that a well-constructed HLD is crucial for any successful SOA security implementation, and the SEA is ultimately responsible for leading the SOA security team toward its creation.

Back to top

Simple rules for creating an HLD

Despite the criticality of an SOA security implementation HLD, SOA security teams aren't always clear about what the goals of an HLD should be. Often without dedicated architectural resources, team members are overwhelmed with architectural notation and unfamiliar with modeling tools that can assist them in managing the overall process.

Here, besides recommending tools, you can provide helpful hints and rules that SOA security team members can adopt and incorporate into their processes toward generating a winning SOA security implementation HLD.

SOA security team members should keep a few basic rules of thumb in mind before beginning construction of their HLD documentation. Essentially, the HLD should:

• Be a diagram or set of diagrams with as few notes as possible.
• Start simple and at as high a level as possible.
• Be readable by all stakeholders.
• Satisfy the entire set of security requirements listed in the requirements document.
• Use the least number of diagrams: One is best but not always feasible.
• Contain all the key objects that must be secured and represent them generically.
• Contain all the key security relationships between objects.
• Serve to generate all security test cases.
• Leverage object-oriented concepts such as encapsulation, inheritance, and polymorphism.
• Serve as a starting point from which to generate the DLD.

Your focus should be on providing answers to key questions, such as "when do we start?" "How do we proceed?" "How do we know when we're done?"

Back to top

Create the HLD

The main goal of the SOA security team's HLD effort should be to create a document that serves as a communications tool: It must speak to and for the entire team. Before SOA team members get mired in the nitty gritty of architectural documentation, they should focus on thoroughly reviewing their requirements and understanding what their overall security goals are. The HLD must serve to communicate clearly what they have in mind in terms of providing overall security for the SOA implementation.

Codifying the team's general agreement on key stakeholder SOA security implementation questions is then the next step. For example, the document could include queries such as:

• What do we need? (Security personnel and requirements documents)
• What are we building? (Developers)
• What are we paying for? (Upper management)

The HLD must also provide answers to more complex questions, such as nonfunctional requirements. These requirements include system audit and control, extensibility, resilience, vertical and horizontal scalability, multisite issues, and integration of third-party tools.

Deciding when to begin the HLD isn't easy. The accepted industry guideline is Capability Maturity Model Integration (CMMI) levels 3-4 (see Resources as a basis for pursuing an enterprisewide SOA security strategy. Much of the detailed requirements documentation should be completed before you begin. And, counter-intuitively, much of the SOA security services implementation must be understood simultaneously. Before beginning the HLD, the team should have already listed their requirements, understood the services that will be needed to satisfy those requirements, and associated those services with the appropriate requirements.

Identify the principals

Before delving into an HLD, the team should create a list of all the entities that they must secure. In the security domain, items that must be secured are called principals. Here is a list of high-level principals for a typical SOA system:

• Application or service
• Hardware
• Message
• Orchestration
• Service component
• SOA component (for example, Enterprise Service Bus, or ESB)
• User
• Utility

In addition, the SOA security team should generate a high-level graphic representation of how team members will secure interactions among principals. Figure 1 shows how principals are further divided into participants and resources, where each participant can be a human or a computing application invoking the capabilities of a resource, and each resource is a service capability, data, component, or real-world effect. The security intermediation between principals can be further deconstructed into enforcement points, decision points, contracts, and attributes.

Principal interactions

Because each principal listed above can potentially interact with other principals, it follows that the intermediation shown in Figure 1 will require one of these diagrams for each interaction. For an SOA implementation with the aggregates shown in Table 1, there are, in round numbers, potentially 1000 x 1000 interactions. That is 1,000,000 potential interactions between principals that have to be accounted for, at least in the HLD.

Secure the principal interactions

As the interactions between principals are further detailed, specific SOA security services will emerge with specific responsibilities for securing those interactions. Prior to beginning an SOA HLD, the team should create a table linking services to principals. Table 2 shows an excerpt from a requirements document in which the identification service is associated with all the principals.

This association is further illustrated in the principal/service matrix, which is useful when constructing an HLD. Table 3 shows such a matrix.

Note that this process isn't static but dynamic: When sufficient requirements have been gathered, the team is almost ready to begin a preliminary HLD. As other requirements are added, they will continue to affect the HLD. Moreover, as the HLD is fleshed out, additional and unexpected requirements will likewise appear until a steady state is achieved and changes in one document don't substantially affect the other.

At first, the team shouldn't focus too much on architectural notation, because the process of creating an SOA HLD can be highly dynamic and involve many stakeholders. Therefore, it's best to use tools that can help with both the HLD design and the HLD design-management process. SOA security team members should familiarize themselves with online tutorials such as "Developing a J2EE Architecture with Rational Software Architect Using the Rational Unified Process." Again, the purpose of the HLD is to communicate clearly to the SOA security team first. Afterwards, you should work with the EA to ensure that the document is consistent with the overall architectural notation of the enterprise model.

Back to top

Create a diagram

Let's begin with the simple diagram shown in Figure 2.

Here, the "SOA security cloud" represents all security services meeting all SOA security requirements. It permeates the overall SOA implementation and can accommodate current and future requirements. Notably, this diagram meets the first five rules, which require that it:

• Be a diagram or set of diagrams.
• Start simple and at as high a level as possible.
• Be readable by all stakeholders.
• Satisfy the entire set of requirements listed in the requirements document.
• Use the least number of diagrams. (One is best but not always feasible.)

Figure 2, however, doesn't meet any of the other rules and must therefore be further refined, although it's important to note that it can serve as a much better jumping-off point than simply a blank page.

Using Figure 2 as your base diagram, in your next diagram (Figure 3), you add SOA security services, principals, and principal interactions elements to your SOA cloud. In addition, you include elements such as third-party tools and an electronic perimeter. Besides the interaction between principals and the intermediation of security services, take into consideration third-party tools and services that will provide critical services in addition to those that SOA security provides.

A careful review of this diagram reveals that it meets the other rule requirements, including:

• Containing all the key objects that must be secured and representing them generically
• Containing all the key security relationships between objects
• Leveraging object-oriented concepts such as encapsulation, inheritance, and polymorphism

Figure 3 contains all the key SOA security services for this implementation. You can include additional services as needed, but you gain no additional information by including more than three or four. Figure 3 also contains all the principals; by using different shapes, it serves to represent all principal interactions polymorphically.

If you assume that each border surrounding each principal is an enforcement point (EP) and decision point (DP), then in this diagram, you have incorporated all the elements needed for an HLD. You're not offering details about how those EPs or DPs will be implemented: Those details are left to the detailed design.

Back to top

Create the DLD

From this HLD, you can begin to generate the DLD, which is rule of thumb number 10. In this case, you can use product-agnostic Unified Modeling Language (UML) notation to illustrate relationships between SOA security services, as shown in Figure 4.

In Figure 4, you provide a detailed component diagram for the security services based on your HLD diagram.

Back to top

Summary

When creating an SOA security HLD, it's important to start with detailed requirements. Using the right tools to design and manage the process and following the rules of thumb in this article, you and the SOA security team can create an HLD that everyone agrees is clear without getting bogged down in notations.

The next and final article in this series focuses on creating a useful notation for generating SOA security test cases. In pursuit of rule number 10, you'll use this HLD to begin to generate test cases. Until then, continue to send in your useful comments and thoughts.

Share this... Digg this story Post to del.icio.us Slashdot it!

Resources

• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  
• Find more information about the Oasis Security Services TC Glossary (PDF).
  
  
• Check out Gary McGraw's very useful book, Software Security: Building Security In (Addison-Wesley, 2006).
  
  
• To learn more about CMMI, visit the Carnegie Mellon Software Engineering Institute Web sit.
  
  

• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

• Check out developerWorks blogs and get involved in the developerWorks community.

About the author

		John Betancourt is President and CEO of Intelleges, a company focusing on supply chain security, large-scale SOA implementations, and cybersecurity.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Back to top