第 13 章安全中间件的模式

第 13 章安全中间件的模式

CHAPTER 13 Patterns for Secure Middleware

Medio tutissimus ibis. (You will be safest in the middle.)

Ovid

The most perfect political community is one in which the middle class is in control, and outnumbers both of the other classes.

Aristotle

13.1 Introduction

Middleware typically includes a set of functions that provide services to applications, including distributed aspects such as brokering, as well as specific services such as blackboards, pipes and filters, adapters and others. Middleware may also include global services such as authentication, authorization and other services. These services can support development of applications or their execution. There is a great deal of pattern-oriented advice on how to build distributed systems, for example [Bus96][bus07] [Cra95], [Kir04][sch00b]. There is also a great deal of experience with securing distributed systems, for example [And08][dem04] [Kau02]. However, much of the experience gained in securing distributed systems has not worked its way back into design patterns. In [Fer07b] we showed how to add security to middleware patterns; we describe here specific patterns obtained using this approach.

Figure 13.1 shows the patterns discussed in this chapter. The SECURE THREE-TIER ARCHITECTURE pattern typically organizes the structure of middleware systems. Three-tier systems frequently implement a SECURE MODEL-VIEW-CONTROLLER pattern. Distribution is organized using a SECURE BROKER, which is implemented as part of a SECURE ENTERPRISE SERVICE BUS (ESB), and may also use a SECURE DISTRIBUTED PUBLISH/SUBSCRIBE pattern. Other frequently used middleware patterns include SECURE BLACKBOARD, SECURE PIPES AND FILTERS and SECURE ADAPTER. The objectives of these patterns are:

Figure 13.1: Secure middleware patterns

SECURE BROKER [Mor06b] extends the Broker pattern [Bus96] to provide secure interactions between distributed components.
SECURE PIPES AND FILTERS [Fer09a] provides secure handling of data streams. Each processing step applies some data transformation or filtering. The rights to apply specific transformations to the data can be controlled. The communication of data between stages can be also protected, and the operations applied can be logged.
SECURE BLACKBOARD [Ort08] provides secure handling of data when its blackboard is accessed by a set of knowledge sources. Each knowledge source reads data from the blackboard, applies some processing or data transformation, and updates the blackboard. To prevent violations of integrity and confidentiality, the rights to reading and updating data are controlled according to their predefined rights, and their actions are logged. The sources are authenticated before being allowed to access the blackboard.
SECURE ADAPTER [Fer09b] converts the interface of an existing class into a more convenient interface. Both adapter and adaptee are secured.
SECURE THREE-TIER ARCHITECTURE [Fer08d] extends the Three-Tier Architecture pattern by enforcing a global view of security for all three layers. In the presentation part of the system, security aspects dealing with user interaction are enforced; in the business logic, global security constraints are applied; the data storage applies policies to constrain access of users to data.
SECURE ENTERPRISE SERVICE BUS [Fer11b] provides a convenient infrastructure to integrate a variety of distributed services and related components in a simple and secure way.
SECURE DISTRIBUTED PUBLISH/SUBSCRIBE [Fer12e] decouples the publishers of events from those interested in the events (subscribers). Subscription and publishing are performed securely.
SECURE MODEL-VIEW-CONTROLLER [Del12] adds security to the interactions of users with systems configured using the MVC (Model-View-Controller) pattern.

13.2 Secure Broker

The SECURE BROKER pattern extends the Broker pattern to provide secure interactions between distributed components.

EXAMPLE

An organization uses an electronic messaging system such as conferencing software, chat or instant messaging. A group within the organization wants to arrange for private communications within the group. Members of the group should be able to exchange messages with each other that are not made known to the organization at large. Members have a variety of devices (laptops, smart phones) that run the organization’s messaging client.

CONTEXT

Distributed computing systems, homogeneous or heterogeneous, with independent cooperating components that must be secured.

The Broker architectural pattern can be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions [Bus96].

Proxies insulate their callers, client and server, from the implementation details of communications. The Bridge class implements a similar concept for communications between brokers. There are two basic use cases for Broker, illustrating its role in structuring transparent communications between clients and servers: server registration and client requests service; see [Bus96] for details.

PROBLEM

In addition to the liabilities of the broker [Bus96], security threats add a new set of problems. How can we secure the broker’s activities?

The threats affecting the pattern include:

Illegal access. Clients’ access to servers may need to be restricted, and servers’ access to clients may need to be restricted, for compliance and application semantics purposes.
Message interception or replaying. An attacker may intercept the messages from client to server and read or modify them. Message replaying is another possibility.
Spoofing (forgery). If a rogue server can portray itself as valid to the broker, it can appear to service client requests while also compromising client data, or perform a wide variety of other attacks on unsuspecting clients. Likewise, if a rogue broker can portray itself as valid to servers and clients, it can do harm by recording traffic between clients and servers, substituting other clients and servers for valid ones, and so on. And if a client can forge its identity to a broker, it can access services for which it does not have rights. There are a wide variety of attacks based on forgery: redirection of traffic from official sites to forged sites; spamming while masking the source’s destination; cache poisoning, in which invalid entries are stored in the broker’s repository; and routing attacks, in which traffic intended for one destination is sent to another [NTC01].
Denial of service. Valid entries in the repository could be removed, and they will not be accessible. And with access to the broker’s server repository, DoS attacks can be launched against member servers. By limiting the server’s abilities to respond to requests, clients can be disabled [Kau02].

SOLUTION

In addition to the Broker pattern’s role in decoupling communications from applications, a secure broker must introduce mutual authentication between servers and clients. It must also provide authorization and a reference monitor to control access to resources, and cryptographic controls to prevent message attacks.

STRUCTURE

Figure 13.2 shows the class diagram for the SECURE BROKER pattern. Subject is a role that can be taken by the Broker, Client(a principal), and Server. Its function is to provide identity to components participating in communication, and to allow components to authenticate each other. Identity management and creation is beyond the scope of this description, but it must be sufficient to uniquely identify components in the universe of possible interactions.

Figure 13.2: Class diagram for the SECURE BROKER pattern

The ReferenceMonitor authorizes participant requests. It is responsible for allowing and denying service requests based on the identity of the requester and the prevailing set of rights. Rights structure and configuration are discussed in Chapter 6.

SecureChannel is responsible for encrypting traffic between components that may travel over secure links that are not limited to trusted components.

DYNAMICS

A secure broker implements or supports the use cases ‘Subject creation’, ‘Registration’ and ‘Secure service request’. Each client and server wishing to participate in secured communications must be assigned identity and rights.

Subject creation. In contrast to the Broker pattern, where it is assumed that the broker can be trusted, servers, clients and brokers, in their roles as principals, must be assigned identities and credentials in order to safeguard access. Therefore, we need a preliminary use case for each principal (subject), ‘Subject creation’, incorporating identity and rights assignment. This use case is straightforward and requires a security administrator to assign rights to a new subject according to predefined policies (see Chapter 6).
Secure registration. Registration is similar to the standard sequences in [Bus96], except that mutual authentication must be done before registration.

Use Case: Secure Service Request – Figure 13.3

Figure 13.3: Sequence diagram for the use case ‘Secure service request’

Given that the participating Client, Server and Broker have been previously authenticated and assigned credentials, service requests flow as indicated in the sequence diagram of Figure 13.3.

A Client makes a request indicating its ID and its rights. The Client-SideProxy marshals and forwards the request to the Broker. The Broker checks the rights of the Client to perform this operation on the servant object1, finds the Server, and routes the request to the Server-SideProxy. The proxy unpacks the data, may check rights (in addition or instead of the Broker) and performs the service. The response is sent as in a standard Broker implementation. (The figure does not show the encryption operations.)

IMPLEMENTATION

CORBA

In order to show a specific set of defenses, we choose an example Broker implementation, the Common Object Request Broker (CORBA), to see how transactions are secured. To do this requires some introduction to CORBA’s security architecture.

CORBA security explicitly defines the threats it is designed to address:


Threat 1	An authorized user of the system gaining access to information that should be hidden from them.
Threat 2	A user masquerading as someone else, directly or through delegation.
Threat 3	Security controls being bypassed.
Threat 4	Eavesdropping on a communication line.
Threat 5	Tampering with communication.
Threat 6	Lack of accountability, due, for example, to inadequate identification of users [NTC01].

This architecture can be mapped to Broker’s defenses in the following way:

Threats 1, 2, 3. Protect clients from illegitimate servers and brokers.
Threats 1, 2, 3. Protect servers from illegitimate clients and brokers.
Threats 1, 2, 3. Protect brokers from illegitimate clients and servers.
Threats 4 and 5. Allow for securing communications between clients and servers.

CORBA, in its Security Service, approaches securing transactions by treating clients, servers and Brokers as principals, which are ‘a human user or system entity that is registered in and authenticated to the system’ [NTC01]. The distinguishing characteristic of a principal is its identity. There are several consequences of identity: it makes the principal accountable for its actions; it identifies the originator of a message; it identifies whom to charge for use of a system; and it allows access control/rights management to be defined. Principals may be granted security attributes (rights). These attributes are used to determine access control for objects within the system. An object’s collection of security attributes is known as its credentials (see Chapter 5). Authorization is implemented between principals and objects through security context objects, which carry the identity and credential information necessary to determine the calling principal’s rights for the called object.

The principal authenticator interface provides facilities for generating sets of credentials and for generating security contexts, given a principal, an object and an access request. An object implementing the principal authenticator (called ‘vault’ in the CORBA architecture) accepts a principal’s identity as an argument and authenticates that principal, returning its set of credentials (Figure 13.4). Access decision objects are responsible for binary (yes/no) access decisions, based on the applicable principal, object and security context. When a client makes a request of a server, both client and server proxies submit the request for evaluation according to security policies through these access decision objects (Figure 13.5). Note that no checking is done by the CORBA Broker; CORBA assumes that the proxies can be trusted.

Figure 13.4: Subject authentication in CORBA

Figure 13.5: Secure object invocation in CORBA

.NET REMOTING

.NET Remoting implements HTTP and TCP transport mechanisms (‘channels’). The .NET Remoting security architecture does not enumerate specific threats; rather, it provides a generic set of tools for authentication, authorization and confidentiality that must be adapted in an application’s context. These tools, implemented through the GSS-API, include credentials to identify clients and servers, contexts in which these credentials are valid, and provisions for encrypted transport [MS04A].

Microsoft has illustrated how to use .NET Remoting to implement the Broker pattern [MS03A]. In considering .NET Remoting security, and how to apply it to the SECURE BROKER pattern, we look to the GSS-API [RFC2743] for guidance.

Follow the steps for Broker [Bus96], but amend them in the following ways:

Include identity and rights in the object model. Ensure that all participants are assigned identity, that they are authenticated in order to participate, and that rights are checked before requests are granted.
Implement a reference monitor to check authorization.
Implement the Secure Channel pattern [Bra00] to protect message traffic.

Therefore, in addition to the broker role in decoupling communications from applications, a SECURE BROKER must:

Protect clients from illegitimate servers and brokers.
Protect servers from illegitimate clients and brokers.
Protect brokers from illegitimate clients and servers.
Allow for securing communications between its clients and servers.

EXAMPLE RESOLVED

In the messaging example, each group member participating in the conversation is issued an identity for the system, together with rights to chat with other members of the group. The messaging server is also assigned an identity, together with rights permitting each member of the group to send messages to other members of the group. As client proxies send messages to the server, each message is checked by the server’s reference monitor (and possibly the server-proxy’s reference monitor, depending on the configuration and security requirements). Eligible messages from authenticated participants are relayed. As some of the group members communicate over public lines, Secure Channel [Bra00] is set in operation for these links, to ensure message confidentiality.

CONSEQUENCES

The SECURE BROKER pattern offers the following benefits:

Illegal access. Based on authentication, access control can be implemented, enabling restrictions on the use of privileged information and functionality.
Message interception. Encryption can handle all these problems (see Chapter 12).
Forgery. By requiring authentication of each broker, client and server, trust can be established between transaction participants.
Denial of service. Authentication and access control prevent removal of valid entries. With control of access to the broker’s server repository, DoS attacks cannot be launched against member servers.

The pattern also has the following potential liabilities:

Extra overhead.
Added complexity.

KNOWN USES

The CORBA Security Service, Microsoft .NET Remoting and the World Wide Web implement at least some aspects of the pattern described here.

13.3 Secure Pipes and Filters

The SECURE PIPES AND FILTERS pattern describes how to provide secure handling of data streams. Each processing step applies some data transformation or filtering. The rights to apply specific transformations to the data can be controlled. The communication of data between stages can be also protected. The operations applied can be logged.

EXAMPLE

ArtisticRenderings is a company that prepares brochures and reports for marketing real estate, stocks and all kind of products. To prepare each brochure needs a product specialist, a graphic designer and an artist. To insert information from databases, for example sales statistics, we need some IT people. The whole process is under the control of a supervisor. Each person has their own interface, and once they complete their jobs, their inputs will be applied in sequence to the stream of documents. However, some documents are sensitive and we need to control who makes the changes, or a disgruntled employee might introduce incorrect contents.

CONTEXT

Consider Pipes and Filters software or other processing systems which are used to process data streams. Some of them may be parallel, attempting to improve the process performance. The execution platform for this kind of system is frequently a distributed one, whose components may require a certain level of security for processing the stream of data. Parallel here means that several components (whether human or automatic) act simultaneously. Even a human Pipes and Filters pattern aims to improve performance. In this case we don’t have significant performance improvements, but this architecture may be valuable for flexibility reasons, or to have a systematic, well-structured process.

PROBLEM

The essence of the Pipes and Filters pattern is that every time data reaches a different stage, different functions are applied on it, and in a secure version these actions should be controlled. In this kind of system, we may also need the flexibility to reorder the steps of the process or change the processing steps. In the example above, a new person may be assigned to the workflow to perform additional functions on the documents, which may require adding an extra step. How can we control the actions to be performed in a data pipeline and provide security for the pipeline activities? Additionally, the data may be moved along the pipeline using insecure channels, and the users defining the data transformations may be remote.

The solution to this problem must resolve the following forces:

Stage control. The system may need to control, at each stage of processing, who can do what (what operations can be applied) with the data in the pipeline. This may be necessary in both automatic and interactive pipelines, otherwise employees might introduce illegal content or filter out wanted information.
Authenticity. We might require the data or the message carrying it to be authenticated before it is accepted by the next or the previous stage, otherwise an imposter might send data to be processed.
Message protection. Before sending data in the pipes we may need to hide it to prevent eavesdropping. We may also need to verify the authenticity of messages.
Reconfiguration control. Due to regulatory constraints, work changes, or efficiency, some documents may need extra stages, or to skip stages. We need to be able to reconfigure the number or order of the steps. This reconfiguration should be controlled, or a user might skip necessary stages or add unintended stages.
Recording. We should keep track of any actions applied to the data in cases where legal documents or regulatory compliance is involved.
Transparency. The security controls should be transparent to the users of the pipeline.
Overhead. The security controls should not affect performance significantly.

SOLUTION

The SECURE PIPES AND FILTERS pattern provides a secure way to process data in different stages or steps, by adding basic security mechanisms (as instances of security patterns) to each of them to provide authentication, authorization, information hiding and logging. Because the functions to be performed at each stage depend on people doing specific tasks, we use a Role-Based Access Control (RBAC) model [Fer01a] to describe their required rights. An RBAC model assigns rights to roles to access data or resources in specific ways. Individual users may belong to one or more roles.

STRUCTURE

We apply an RBAC pattern to control access to stages. In this model, users are members of Roles and Rights are assigned to roles. A Right defines the access type that can be applied by a Role to a protection object. Pattern instances corresponding to security mechanisms have been added to the Pipes and Filters pattern in Figure 13.6. Since we are considering a set of stages the pattern is made clearer by showing an object diagram (describing three typical stages) rather than a class diagram. The subsystems named Authenticator are instances of the AUTHENTICATOR pattern, and allow each Filter to authenticate the sender of the data it is receiving. Log indicates instances of the SECURITY LOGGER AND AUDITOR pattern, used to keep track of any accesses to the data.

Figure 13.6: Object diagram for the SECURE PIPES AND FILTERS pattern

Objects with the stereotype <<role>> and Right are instances of the ROLE-BASED ACCESS CONTROL pattern. For example, Role1 has the right to apply operations op1 and op2 to the data in Filter i. The ReferenceMonitor subsystem indicates the enforcement of the authorization rights defined by the RBAC instances. We show the ReferenceMonitor as a shared resource and the Authenticators as individual for each stage; their actual distribution depends on the distribution architecture of the complete system. In order to control the reconfiguration of the stages, the ROLE-BASED ACCESS CONTROL pattern is also applied to the pipeline structure, so that only someone with an administrator role (Role3) can perform any changes to it.

DYNAMICS

Figure 13.7 shows the use case in which a subject with a specific role tries to execute an operation, op3, on a document. The ReferenceMonitor checks whether its role allows the operation, and if true, reads data from the input pipe, Pipe i, to the filter where op3 is applied. After the operation the data is moved to the next pipe, Pipe j.

Figure 13.7: Sequence diagram for the use case ‘Apply an operation on a data stream’

IMPLEMENTATION

We follow the steps suggested in [Bus96] and indicate where security is needed:

Divide the application into a sequence of stages. Who should have access to which operations or results from each stage should be defined in the conceptual model. When the application is divided into stages we need to define how the rights in the complete model are reflected in each stage.
Define the data format to be passed along each pipe. This aspect has no effect on security.
Perform threat enumeration (see Chapter 3) and risk analysis. This is necessary to decide about what security mechanisms to add in each stage.
Decide how to implement each pipe connection. Aspects such as active or passive components, or push or pull movement of data are defined at this point. We have to decide whether to use authentication between filters, and if we do, what type of authentication. For communications within the same physical building, filter authentication may not be required, although user authentication to the system is always needed.
Design and implement the filters. Each filter enforces the rights defined in the first implementation step, and must have a reference monitor and a means to access the authorization rules. In distributed systems one needs to decide where these rules should be stored. Filters also implement logging, as well as encryption and decryption.
Design error handling. From the security side this implies handling security violations. This handling is application-dependent and no general policy is possible.
Set up the processing pipeline. The initial configuration, as well as changes to the configuration, must be restricted only to administrators.

We can apply the principle of defense in depth, defining a coherent set of security mechanisms that provide a secure core for this application. In some cases, specific mechanisms can be left out, being careful about security consistency; for example, authorization requires authentication. In other cases, more security controls may be needed to prevent, for example, conflicts of interest.

The ROLE-BASED ACCESS CONTROL pattern (page 78) provides the option of abstracting different roles within the data flow. It may be that we need to work with individual subjects instead of roles; in this case implementing the AUTHORIZATION pattern (page 74) should be a better approach. The link between stages could be subject to attacks, and optional operations of encryption and decryption could be implemented in each filter, as well as digital signatures in each data message (not shown in Figure 13.6).

EXAMPLE RESOLVED

We implemented the ROLE-BASED ACCESS CONTROL pattern in the pipes and filters of the example. Now people making changes to documents need to be authorized before they can do so. The operations they can apply depend on their roles with respect to the application. Logging protects the company in case they need to show that they comply with regulations, and they can track who made a specific change to a given document. Authentication is needed to apply authorization, and maybe also between stages if necessary.

CONSEQUENCES

The SECURE PIPES AND FILTERS pattern offers the following benefits:

Access control. We can assign privileges according to the functions needed at each stage of processing and the roles of those performing the functions. The use of operations over the data can be restricted according to the rules of either role-based access control or access matrix models.
Authenticity. Each filter stage can authenticate its users before they are authorized to perform specific functions, and can authenticate the filter sending data to it. Authentication is necessary if we apply authorization at each filter.
Message protection. The use of encryption between stages is possible, adding the possibilities of secure messages (preventing eavesdropping) and digital signatures (to confirm the origin of a message).
Controlled reconfiguration. The administrator role can control the reconfiguration of stages to accommodate changes in the process.
Recording. Logging can be performed at each stage to keep track of any accesses and changes to the data. This allows us to prove that we have followed any regulations: we can prosecute illegal actions, and we can improve the system if it failed to prevent an attack.
Transparency. The security restrictions are transparent to the users provided that they do not attempt illegal actions.

The pattern also has the following potential liabilities:

The general performance of the system worsens due to the overhead of the security checks. With careful implementations of these functions, the loss in performance should be small. For example, encryption/decryption takes time and should be used only when needed; access control to the filters happens only when a new type of data is being analyzed. In parallel pipelines the performance loss can be further reduced by performing some security functions in parallel with normal functions.
The system is more complex, due to the extra services that have been added.

KNOWN USES

Microsoft’s BizTalk Server 2004 [Biz04] can implement the Pipes and Filters pattern. In addition to security features that are provided by the transport, such as encryption when using HTTPS, BizTalk Server 2004 provides security at the message level. It can receive decrypted messages and validate digital signatures that are attached to these messages. Similarly, it can encrypt messages and attach digital signatures to messages before sending them.
Apache Cocoon [Coc07] is a web development framework using components. It can be used to build XML pipelines in which security restrictions can be added.
The tax offices of some countries implement a human pipeline to process tax returns. Workers may check different aspects of a tax return either manually or using computers, and need to be authorized to do this.
[Ten05] discusses the use of XML pipelines for document preparation, including stages for adding content, formatting and personalization. What is done at each stage can be controlled.
Pipelines are common for data reduction when large volumes of data must be handled. [Sco05] discusses a data reduction pipeline for spectroscopic data, in which different transformations by different researchers are applied at each stage. What is done at each stage is controlled according to the functions of the researchers.
A cloud-based secure pipeline for document processing and management is discussed in [Joo11].

13.4 Secure Blackboard

The SECURE BLACKBOARD pattern describes how to provide secure handling of data when its blackboard is accessed by knowledge sources. Each knowledge source reads data from the blackboard, applies some processing or data transformation, and updates the blackboard. In order to prevent violations of integrity and confidentiality, the rights to reading and updating data are controlled according to their predefined rights, and their actions are logged. The sources are authenticated before being allowed to access the blackboard.

EXAMPLE

Suppose we are developing an application for a law firm [Fer07c]. The conduction of a case requires inputs from many data sources: lawyers, witnesses, defendants and so on. Court appearances are scheduled according to court and lawyer availability. All this makes the sequence of actions unpredictable. A blackboard is used to conduct a case, where immediate results of court appearances and case strategy are kept for analysis and updating by lawyers. The data handled is very sensitive and access to it needs to be controlled. If we are not careful, we might end up with invalid data, or data will leak to our opponent, which will damage our chances of winning the case.

CONTEXT

A blackboard system is used to receive and modify information about a problem in progress from several data sources. The execution platform for this kind of system is normally distributed, with knowledge sources possibly remote. The data is exchanged between blackboard and knowledge sources in a client/server fashion.

This pattern useful for problems for which no deterministic solution is known. In the Blackboard pattern several specialized subsystems assemble their knowledge to build a possibly partial or approximate solution [Bus96].

The organization of this process has been well defined and converted into patterns: the Blackboard pattern (Figure 13.8), and its parallel counterpart, the Shared Resource pattern [Ort03]. The descriptions provided for these patterns take into consideration only functional properties, such as their potential for improving performance. These patterns have been proposed assuming that all components (blackboard, control, and knowledge sources) ‘implicitly trust’ each other, and there is no concern about unwanted activity among them. However, many distributed applications (such as those mentioned earlier) require taking security into consideration, since data sources may handle sensitive or valuable data such as personal or business information.

Figure 13.8: Object diagram of the Blackboard pattern

PROBLEM

Usually we want a variety of knowledge sources to solve a difficult problem or conduct a process. Nevertheless, how can we control the actions to be performed in the blackboard so that we provide the required level of security for the system?

The solution to this problem must resolve the following forces:

Nondeterminism. The sequence of activities or operations over data is usually unpredictable. Also, the number of knowledge sources might be hard to predict.
Access control. Blackboard data should only be read or modified by authorized knowledge sources, otherwise users may see or override important information.
Authenticity. It might be necessary to verify that the knowledge sources are authentic, otherwise we might receive false information, or our information could be leaked outside our system. The channels they use must be secure.
Controlled reconfiguration. Due to regulatory constraints, work changes or efficiency, we need to be able to reconfigure the number of knowledge sources or their order of operation. This reconfiguration must be controlled. A faulty reconfiguration could lead to incorrect conclusions, or to the inclusion of inconsistent or erroneous information.
Records. For billing and security purposes, logging the actions at each update of the blackboard may be necessary. This information can be audited later.
Transparency. The security controls should be transparent to the users of the system, or they might not use them.
Overhead. The security controls should not impose a significant overhead on the functions of the system.

SOLUTION

Add security mechanisms to control the threats. The SECURE BLACKBOARD pattern provides a way to access blackboard data from a variety of knowledge sources in a secure way, by adding some basic security mechanisms to the control component (as instances of security patterns), providing authentication (AUTHENTICATOR, page 52), authorization (ROLE-BASED ACCESS CONTROL, page 78) and logging (SECURITY LOGGER AND AUDITOR, page 111) in each access operation.

STRUCTURE

Figure 13.9 shows a class diagram of the SECURE BLACKBOARD pattern, in which security pattern instances have been added to the components of the original Blackboard pattern. SecurityLogger indicates an instance of the SECURITY LOGGER AND AUDITOR pattern [Fer11d]. The Reference Monitor associated with the control indicates the enforcement of authorization (page 100). KnowledgeSources can be humans, not just software components. Nevertheless, either automated or human knowledge sources require that their access is authenticated by the Authenticator (page 52) to verify their origin. The sources belong to Roles, according to their functions, and their Rights depend on these Roles.

Figure 13.9: Class diagram for the SECURE BLACKBOARD pattern

DYNAMICS

Figure 13.10 shows a sequence diagram in which a KnowledgeSource (with a specific role) requests an operation on the Blackboard. The Control receives the request and invokes the Authenticator to validate that it originates from a legitimate source. After source validation, the ReferenceMonitor checks whether its role is allowed to use the operation and, if true, it performs the operation on the Blackboard. A SecurityLogger record is created after the operation is performed.

Figure 13.10: Sequence diagram for the use case ‘Apply an operation to the Blackboard’

IMPLEMENTATION

[Bus96] list several general implementation aspects. From a security point of view we need to consider the following points:

The authentication system should be appropriate to the value of the information handled; passwords are enough for most cases.
Instead of Role-Base Access Control, we could use an access matrix (page 74) or even a multilevel access control model [Gol06], depending on the environment.
Since the repository and its control are centralized, applying the proposed security functions is relatively simple. Knowledge sources could be remote, and they could require digital signatures in addition to device authentication.

EXAMPLE RESOLVED

The law firm now uses a SECURE BLACKBOARD structure to conduct its cases. The case blackboard receives changes for the case documents, which are stored in specific classes. The blackboard can be protected from unauthorized access.

CONSEQUENCES

The SECURE BLACKBOARD pattern shares the same general benefits of the original Blackboard pattern [Bus96], but adds the following:

Nondeterminism. Knowledge sources can be added or removed dynamically.
Access control. We can define precise role rights; for example, an expert can only add to the information, not change it; a lawyer can decide on the next step, bring new witnesses, but cannot change depositions, and so on. The access control mechanism in the blackboard enforces controlled access to the information.
Authenticity. Authentication services can validate the fact that the data sources are legitimate. The channels can be encrypted.
Controlled reconfiguration. We can control who can reconfigure the knowledge sources
Records. We can log accesses to the blackboard for future auditing.
Transparency. The specific security controls used are transparent to the users of the system.
Overhead. The security controls should not impose a significant overhead on the functions of the system. Blackboard systems are not real-time systems, so the added overhead is easy to accept.

The SECURE BLACKBOARD pattern shares the same liabilities as the original Blackboard pattern [Bus96], and also:

Even though the implementation of the Blackboard pattern normally requires developing the blackboard, the control and the knowledge sources as simple, loosely connected components, when adding security capabilities a more complex implementation is required. Several software components, such as the reference monitor, the authenticator, the logger, and authorization components should be taken into consideration in order to build the correct functionality.
The three security mechanisms incorporated in this pattern are not enough to control all possible security threats, and must be complemented with additional mechanisms according to the needs of the application.

KNOWN USES

The software system used by many news agencies (such as AP, AFP or Reuters) has a structure similar to the SECURE BLACKBOARD pattern. All information retrieved by reporters and correspondents (articles, editorials, notes, photographs and so on) is gathered into a single blackboard, which at the same time is read by many other news and media enterprises (newspapers, television, radio and so on), who distribute the information. Nevertheless, all the information written to or read from the blackboard should be secure. This means that nobody should be allowed to modify or read the blackboard unless authentication and authorization are applied.
A Wiki web is also an example of the use of the SECURE BLACKBOARD pattern. In this case the knowledge sources are humans, whose role within the Wiki could be ‘reader’, ‘editor’, ‘administrator’ and so on. The Wiki should function like a blackboard, whose secure use requires that users are always authenticated, and access is controlled according to their roles within the Wiki system.
Designs for applications that may use this pattern include a travel booking system [Tem], a law firm [Fer07c] and a Java-based knowledge processing and agent programming software framework [Tar02].
The Reflective Blackboard pattern [Sil02] includes security services.

13.5 Secure Adapter

Also known as Secure Wrapper

The SECURE ADAPTER pattern describes how to convert the interface of an existing class into a more convenient interface, while preserving the security of the adapted entity.

EXAMPLE

We have a text message system that sends, receives and manipulates text messages. We want to convert our text messages into XML messages so that we can handle more complex transactions. We purchased an off-the-shelf tool, XmlMessage, which manipulates XML messages. The problem is that these two interfaces are incompatible: XmlMessage expects an XML message, while our text message system does not know how to create an XML message. Our messages are sensitive and we don’t want unauthorized people to read or change the adapted data.

CONTEXT

A computational environment in which users or processes need to use a class that has an interface that is incompatible with the current class. The old class may have sensitive data.

PROBLEM

The Adapter converts the interface of an existing class into a more convenient interface, but its original description does not take in consideration security issues.

To illustrate and identify some possible attacks, consider the following example: we have an interface, RequestServices, which is used to request services from various servers. We want to be able to send requests to a JDBC API; however, our interface is incompatible with the JDBC API. We create a RequestServicesAdapter that adapts requests to JDBC. For example, a client sends a request for a database connection. The RequestServicesAdapter converts the request to a JDBC request, which in turn returns a response containing the requested data items.

We can identify the following threats in this case:


Threat 1	The database accessed through the JDBC interface could be an imposter, and we could be sending or receiving data from a malicious database.
Threat 2	The client may be an imposter, trying to access the data of an authorized user.
Threat 3	The client making the request may not have permission to send such a request; that is, the client may try to access data to which it is not authorized.
Threat 4	If the client is remote, the data sent and received may be intercepted by intruders.

SOLUTION

After we identify the possible threats to the adapter, we need to define policies and their corresponding mechanisms to stop them:


Threat 1	Authenticate the database.
Threat 2	Authenticate the client.
Threat 3	Control access to the adaptee functions through the adapter.
Threat 4	Add a secure channel between the client and the adapter.

STRUCTURE

Figure 13.11 shows a class diagram for the SECURE ADAPTER pattern. We add role-based access control for the clients and a corresponding set of authorization rules. Requests made to the Adapter have to be authorized, ensuring that the client has permission to send such requests. The Adapter also checks responses returned by the Adaptee. For example, when a client requests a database connection, the Adapter authenticates the database identity returned in the response from the Adaptee. (The secure channel is not shown in the figure.)

Figure 13.11: Class diagram of the SECURE ADAPTER pattern

DYNAMICS

Figure 13.12 shows a sequence diagram for the use case ‘Request data via the secure adapter’. The client sends a request to the Target. The request is captured by the Adapter, which is responsible for authorizing the Client. Once the Client’s permission is verified, the Adapter converts the request to a specific request. The Adaptee fulfills the request and sends a response back to the Adapter. At this point the Adapter needs to make sure that the identity of the subject in the response is not an imposter. After authenticating the response subject, the Adapter sends the response to the Client.

Figure 13.12: Sequence diagram for the use case ‘Request data via the Secure Adapter’

EXAMPLE RESOLVED

We can create an adapter class, Message, which receives all requests to create XML messages and returns XML messages. The text message is structured in a certain format; for example, sender’s ID, location, name, message and so forth. We use this format to create the XML message.

CONSEQUENCES

We can stop the threats identified on page 359 as follows:

Threat 1. The database can be authenticated.
Threat 2. The client can be authenticated.
Threat 3. We can apply authorization to user requests.
Threat 4. We can use cryptography to avoid attacks to the messages used in these interactions.

KNOWN USES

CORBA-based systems use adaptors to adapt a remote request to the servant object [Sch00b]. The adaptor also applies authorization constraints.
Microkernels use adaptors to adapt process requests that might have different formats [Bus96]. This makes the microkernel more reusable. In some implementations the adaptor applies authorization restrictions.

13.6 Secure Three-Tier Architecture

The Three-Tier Architecture pattern provides a means of structuring and decomposing applications into tiers or layers in which each tier provides a different level of responsibility. One tier deals with the presentation part of the system (user and system interfaces), another handles the business logic – the core of the system – and the last tier handles the data storage.

The SECURE THREE-TIER ARCHITECTURE pattern extends the Three-tier Architecture pattern by enforcing a global view of security for all three layers. In the presentation part of the system, security aspects dealing with user interaction are enforced; in the business logic, global security constraints are applied, while the data storage applies policies to constrain access of users to data.

CONTEXT

The SECURE THREE-TIER ARCHITECTURE pattern is applicable to distributed systems and systems executing complex and heterogeneous applications, involving databases, with data and documents that contain sensitive information.

PROBLEM

Systems that contain sensitive and valuable data will attract attackers. How can we provide security in the presence of internal and external threats?

The solution to this problem must resolve the following forces:

Completeness. We need to secure all the tiers of the system. Leaving any layer unprotected will allow some attacks to succeed.
Threats. Attacks may come from legitimate users, using the resources available to them, while other attacks may come from external users through Internet vulnerabilities. Possible misuses of the system include illegal reading or modification of information. These actions may have serious negative effects on the institution that owns the information, and so cannot be tolerated. We need to stop or mitigate these attacks.
Availability and recovery. We need to provide availability through service continuity and robust recovery in case of disaster, otherwise economic losses might result.
Transparency. The security system should be mostly transparent to the users. If the users need to perform special actions for security, they may just skip them.
Accountability. A user may deny having carried out some action. We need to be able to show that they actually performed the action.
Policies. We should be able to apply institution policies to control the use of the information.

SOLUTION

Apply appropriate security services to each layer. The presentation layer requires authentication and authorization of users. Secure the communication channel between the users and the system and enforce encryption of the data sent between the user and the system. The business tier defines a unified access control model for the complete system, while the presentation layer shows subsets of this model to the users and controls their interactions. The storage layer may have additional constraints based on the sensitivity of the data; for example, some parts may be encrypted.

STRUCTURE

The main architectural view of the SECURE THREE-TIER ARCHITECTURE pattern is shown in Figure 13.13. The PresentationTier includes user and system interfaces; the PresentationSecurityServices include authentication and authorization. The BusinessTier includes a unified model of the enterprise data and provides global authorization rules and their reference monitor. Its BusinessSecurityServices include global authorization rules, and must be coordinated with a SECURE BROKER (not shown), which may introduce additional restrictions. The DataTier defines authorization to access stored data items and mechanisms for encryption. The specific services used depend on the application, but to support a variety of applications we need a complete set of services.

Figure 13.13: Class diagram for the SECURE THREE-TIER ARCHITECTURE pattern

DYNAMICS

The dynamic behavior of the SECURE THREE-TIER ARCHITECTURE pattern is illustrated by the sequence diagram of Figure 13.14, which shows the use case ‘Process a database request’.

Figure 13.14: Sequence diagram for the use case ‘Process a database request’

A request is issued by a Client, which goes to the Presentation layer for processing. This layer cannot satisfy the request by itself, so it calls the next layer, the Business (logical) layer, for more support with the request. As with the Presentation layer, part of the request can be handled here, but there are some parts which need support from the Data layer, so this is finally called. Here, at the last level, the subtask specific to this layer is performed and the results are sent back to the Business layer, which aggregates its results with what was received and returns them to the Presentation layer. The Presentation, Business and the Data layers may apply access and authorization constraints.

The Business layer will typically include a global enterprise model and will centralize authorization rules, but these may be applied at other layers. Each layer protects the layer below. For example, the Presentation layer may protect the Business layers from a denial of service attack. Communication between Clients and the Presentation layer may require authentication, as part of the first phase shown in Figure 13.14. Processing in the Data layer may require authorization from the requesting business component, or directly from the client – that is, through an authorization granted on the Presentation layer.

IMPLEMENTATION

The following steps are needed to implement this pattern:

Define a global authorization model for the enterprise, unifying the possible variety of authorization models used by the databases. Typically, ROLE-BASED ACCESS CONTROL (page 78) is used.
Select authentication approaches based on the needs of the applications. For example, remote user interfaces may need to be authenticated. The type of authentication depends on the sensitivity of the data.
Select an approach for encrypting messages and for digital signatures. Languages such as Java and C# include cryptographic libraries with different algorithms.

CONSEQUENCES

The SECURE THREE-TIER ARCHITECTURE pattern offers the following benefits:

Centralized security. Authorization constraints, authentication information and logging repositories can be associated with the Business layer.
Coverage. All layers may apply security restrictions, tailored to the needs of the applications.
Unified security. The pattern achieves this by the use of a global business model with its corresponding authorization structure. We can enforce any semantic constraints on access.
Transparency. The application of security controls is transparent to the users.
Availability. Because this is a distributed architecture, we can introduce some redundancy and improve availability.
Non-repudiation. The user interfaces can apply digital signatures for specific interactions.

The pattern also has the following potential liabilities:

Security overhead. Security actions imply some overhead.
Extra complexity. The addition of security functions makes the system more complex; for example, it may not be clear where to apply specific security constraints.

KNOWN USES

A three-tier security dashboard for cloud computing is presented in [Joo11].
Sun One Application Server offers services to clients [SunD], protected using certificates, SSL/TLS encryption, authentication and auditing.
IBM WebSphere’s architecture can be mapped into three-tier architecture, and users can enable security by making use of the LTPA mechanism [IBMd]. Security mechanisms such as authentication, certificates, SSL, and PKI can be configured to provide security.
The BEA Web Logic Server architecture is built using three layers [BEA]. Certificates and different encryption mechanisms can be used to provide security.

13.7 Secure Enterprise Service Bus

The SECURE ENTERPRISE SERVICE BUS pattern describes how to provide a convenient infrastructure to integrate a variety of distributed services and related components in a simple and secure way.

EXAMPLE

A travel agency interacts with many services to make flight reservations, check hotel availability, check customer credit and others. This interaction is currently done by direct interaction, which results in many ad hoc interfaces and requires many format conversions. The system is not scalable and it is hard to support standards. It is also insecure.

CONTEXT

Distributed applications using web services, as well as related services such as directories, databases, security and monitoring, or other types of components (J2EE, .NET). There may be different standards applying to specific components, as well as components that do not follow any standards.

PROBLEM

When an organization has many scattered services, how can we aggregate them so they can be used together to assemble applications, at the same time keeping the architectural structure as simple as possible, and apply uniform standards?

The solution to this problem must resolve the following forces:

Interoperability. It is fundamental for a business unit in an institution to be able to interact with a variety of services, internal or external.
Simplicity of structure. We want a simple way to interconnect services; this simplifies the work of the integrators.
Scalability. We need to have the ability to expand the number of interconnected services without making changes to the basic architecture.
Message flexibility. We need to provide a variety of message invocation styles (synchronous and asynchronous) and formatting. We can thus accommodate all service needs.
Simplicity of management. We need to monitor and manage many services, performing load balancing, logging, routing, format conversion and filtering.
Flexibility. New types of services should be accommodated easily.
Transparency. We should be able to find services without needing to know their locations.
Quality of service. We may need to provide different degrees of security, reliability, availability or performance.
Use of policies. We need a policy-based configuration and management. This allows convenient governance and systematic changes. Policies are high-level guidelines about architectural or institutional aspects, and are important in any system that supports systematic governance, as well as security and compliance [Sch06b].
Standard interfaces. We need explicit and formal interface contracts.
Recording. We need to record sensitive transactions.
Security. We can enumerate threats and add defenses.

SOLUTION

Introduce a common bus structure that provides basic brokerage functions as well as a set of other appropriate services. Figure 13.15 shows a typical structure. One can think of this bus as an intermediate layer of processing that can include services to handle problems associated with reliability, scalability, security and communications disparity. An ESB is typically part of a Service-Oriented Architecture (SOA) implementation framework, which includes the infrastructure needed to implement a SOA system. This infrastructure may also include support for stateful services.

Figure 13.15: An Enterprise Service Bus (from [Zdu06])

STRUCTURE

Figure 13.16 shows the class diagram of the SECURE ENTERPRISE SERVICE BUS pattern. The ESB connects business services with each other, providing support for the needs of these services through a service that can be made up of Business Application Services (BASs), which in turn use Internal Services to perform their functions. BASs are accessed through Service Interfaces (SIs).

Figure 13.16: Class diagram for the SECURE ENTERPRISE SERVICE BUS pattern

DYNAMICS

Figure 13.17 shows the sequence diagram for the use case ‘Access a service’. A Client sends a request for a BAS through the ESB, which finds the corresponding service interface.

Figure 13.17: Sequence diagram for the use case ‘Access a service’

IMPLEMENTATION

The SECURE ENTERPRISE SERVICE BUS itself is an example of a SOA architecture, since it performs its functions using internal services.

An important implementation decision is whether stateful services should be supported or not. Stateless services are easier to design and manage, but there are some applications that require stateful execution.

CONSEQUENCES

The SECURE ENTERPRISE SERVICE BUS pattern offers the following benefits:

Interoperability. The SESB, through its architecture and use of adapters, provides a way to interact with a variety of services, internal or external.
Simplicity of structure. The pattern is much simpler – has fewer interconnections – than point-to-point or any other interconnection structure.
Scalability. The number of interconnected services can be increased easily.
Message flexibility. We can provide a variety of message invocation styles (synchronous and asynchronous) by using different message patterns.
Flexibility. New types of services can be accommodated easily, since they only need to conform to the interface standards.
Simplicity of management. We can centralize the functions of monitoring and management of services, as well as any other required functions.
Transparency. We can find services conveniently by providing lookup services.
Quality of service. By using appropriate associated services we can provide different degrees of security, reliability, availability or performance.
Use of policies. We can use institution policies for configuration and management. This allows convenient governance and systematic changes. Security policies can define rights for the users with respect to the services.
Standard interfaces. We can define explicit and formal interface contracts that must be followed by all aggregated functions.
Recording. We can add a SECURITY LOGGER AND AUDITOR (page 111) to record sensitive transactions.
Security. We can enumerate threats and add defenses. Specifically, we could add a SECURE BROKER (page 339), SECURE ADAPTERs (page 358), SECURE MODEL-VIEW-CONTROLLER (page 375) and others.

The pattern also has the following potential liabilities:

Extra overhead compared to point-to-point, because of the indirection involved and the overhead of the ESB itself.
The bus is a single point of failure, but this can be overcome using redundancy.
A common interface standard may not be the most convenient for some services. Some applications may need more functions or parameters to interact than those defined in the common interfaces. Designing such a common interface may not be easy either.
The bus may hide component dependencies.

VARIANTS

According to [Fer], the ESB will evolve into an Internet bus.
The Secure Broker pattern has access control for web services, secure channels and logging [Mor06b].

KNOWN USES

BEA AquaLogic Service Bus, now Oracle Service Bus, has operational service-management. It allows interaction between services, routing relationships, transformations and policies [BEA][bea11].
WebSphere Application Server [Sph]. IBM’s Business Integration Reference Architecture consists of products from the WebSphere family.
The Service Provider Delivery Environment (SPDE) architecture is an implementation of this reference architecture for the Telecommunications industry [WSE].
Microsoft BizTalk Server [Biz09] also uses ESBs and SESBs.
Mule ESB Enterprise is a supported version of the open source product Mule ESB [Mul]. [Swa08] shows its use to integrate web services written in Java and Ada using SOAP and REST protocols with an Ada web server.

13.8 Secure Distributed Publish/Subscribe

The SECURE DISTRIBUTED PUBLISH/SUBSCRIBE pattern describes how to decouple the publishers of events from those interested in the events (subscribers) in a distributed system. Subscription and publishing are performed securely.

CONTEXT

Distributed applications using web services, as well as related services such as directories, databases, security and monitoring. There may be also other types of components (J2EE, .NET). Different standards may apply to specific components, and there may be components that do not follow any standards.

PROBLEM

Subscribers register and receive messages in which they are interested. How can we organize publishers and subscribers such that their interactions are secure?

We relate threats to use cases as goals of the attacker [Fer06b]:

Subscription
- S1: An imposter subscribes to receive information.
- S2: The publisher is an imposter and collects information (and maybe money) from potential subscribers.
- S3: The subscription messages are intercepted and read or modified by an attacker.
Unsubscription
- U1: An imposter removes a subscriber.
Publish
- P1: An imposter receives information illegally.
- P2: An imposter publishes illegal information.
- P3: An attacker reads or modifies intercepted information.

SOLUTION

Use a secure event channel by which publishers send their events and interested subscribers can receive the events. Subscribers register for the events in which they are interested.

DEFENSES

S1, S2, U1, P1: Mutual authentication
S3, P3: Message encryption
P2: Digital signature
P4: Authorization

STRUCTURE

Figure 13.19 shows the class diagram for this pattern. Subscribers can register to receive specific events. Their conditions are described in the class Subscription. The Channel represents different ways of publishing events.

Figure 13.19: Class diagram for the SECURE DISTRIBUTED PPUBLISH/SUBSCRIBE pattern

DYNAMICS

Figure 13.20 shows a sequence diagram for the use case ‘Publish event’. Other use cases include ‘Register subscriber’ and ‘Remove subscriber’.

Figure 13.20: Sequence diagram for the use case ‘Publish event’

CONSEQUENCES

The SECURE DISTRIBUTED PUBLISH/SUBSCRIBE pattern offers the following benefits:

Loose coupling. Publishers can work without knowledge of their subscriber details, and vice versa. This fact protects the subscribers if the publisher is compromised.
Location transparency. Neither subscribers nor publishers need to know each other’s locations; a lookup service can find their locations. This aspect protects both publishers and subscribers.
Threats. If events are sensitive we can encrypt the event channel. We can also use digital signatures for authenticity.

The pattern also has the following potential liabilities:

Overhead. There is some overhead in the event structure; tight coupling of subscribers to their publishers would have better performance at the cost of flexibility.
Excessive interoperability. Because of its decoupling effect, this pattern allows the interaction of any type of publishers and subscribers, and hence is liable to attackers gaining easier access (the extended version of the pattern in the Variants section can mitigate this).
A distributed system may also suffer denial of service attacks which cannot be controlled at the middleware level (a network problem).

VARIANTS

The Secure Distributed Publish/Subscribe with Access Control pattern extends the basic pattern presented here by adding authorization and a reference monitor (see the Secure Facade pattern, [Fer12e]) to control the publish and subscribe functions.
An example that uses an instance of this variant can be found in [Bac08], which describes a Hermes-based secure publish/subscribe middleware using role-based access control for controlling access.
Other authorization patterns such as Attribute-Based Access Control (ABAC) [Pri04] could be useful to determine whether subscription is allowed based on subject attributes.

KNOWN USES

[Won08] describes an architecture for secure content-based publish/subscribe networks.
[Sse10] describes an e-commerce network using secure publish/subscribe units.
[Sri05] presents a security architecture of a publish/subscribe system (including a consideration of possible attacks) based on event guards.

13.9 Secure Model-View-Controller

The SECURE MODEL-VIEW-CONTROLLER pattern describes how to add security to the interactions of users with systems configured using the Model-View-Controller pattern.

EXAMPLE

eLeague is a company that provides tournament management applications to a variety of sport leagues. The company develops service-based mobile applications allowing sport administrators, athletes and coaches to view and/or maintain their teams, schedules and scores from any location. The user interface of the application is susceptible to frequent change, as it has to adapt to new generations of mobile devices, whereas the structure of a tournament’s information changes less often. In addition, tournament information is sensitive and should be modified only by authorized users.

CONTEXT

The Model-View-Controller (MVC) pattern [Bus96] provides a way to add modularity to an application by separating its functionalities into three loosely-coupled components, the Model, the View and the Controller, thus rendering the entire application more maintainable. This pattern has long been applied to both standalone applications and distributed systems. The MVC pattern is now widely used in web applications, ranging from service-based applications to mobile web applications. Figure 13.21 shows the class diagram of the structure of the MVC pattern.

Figure 13.21: Class diagram of the structure of the MVC pattern (adapted from [Bus96])

Systems applying the MVC pattern are typically multi-user systems, and their model should be accessible and/or modifiable only by certain categories of users. At the same time, the use of the web as a transport layer has brought some new threats that must be mitigated: eavesdropping, impersonation via session hijacking, unauthorized modification via such attacks as SQL injection, or cross-site scripting.

PROBLEM

How can we maintain an acceptable level of security between the model, the view and the controller in the presence of possible attacks?

The solution to this problem must resolve the following forces:

Authenticity. We need to be sure that users who interact with our system are legitimate. Remote users will want to be sure that our system is authentic.
Confidentiality. We may need to restrict access to the model’s information to some users or roles. Also some portions of the data in transit from the model to the view must be protected against eavesdropping.
Integrity. We may want to allow only some users or roles to make changes to the model, and only authorized changes.
Records. The model may contain sensitive information and we want to have a record of all accesses to it.

SOLUTION

The SECURE MODEL-VIEW-CONTROLLER pattern allows users to securely access and/or modify sensitive information located in the Model component. Basic security patterns are applied to provide authentication, authorization, secure communications and logging. In addition, it might be necessary to sanitize incoming and/or outgoing data, to prevent malicious payload attacks such as SQL injection or cross-site scripting attacks.

Access control can be added at the Model level and/or at the Controller and View levels. Adding access control at the Controller and View levels is less intrusive for the model; however, it is coarse-grained. Access control at the Model level can be finer-grained and could be based on specific attributes of the Model.

STRUCTURE

Security is added to the MVC pattern by applying several security patterns (Figure 13.22). An Authenticator identifies and authenticates the User requesting access to the Model and/or to the Controller through the View. We apply the ROLE-BASED ACCESS CONTROL (RBAC) pattern to the MVC pattern. Users are members of Roles, and Rights are assigned to Roles. A Right defines the access type that can be applied by a Role to the Model, to the Controller or to the View. A ReferenceMonitor enforces the access control rights defined in the RBAC pattern. A SecureChannel is responsible for securing traffic between the elements of the MVC pattern. A SecureLogger records all security-sensitive actions on the model. Finally, incoming data and outgoing data must be filtered by an DataSanitizer to prevent malicious payloads embedded into otherwise authorized requests from accessing the model.

Figure 13.22: Structure of the SECURE MODEL-VIEW-CONTROLLER pattern

DYNAMICS

Figure 13.23 (page 380) shows a sequence diagram in which an authenticated user enters some input through the currently displayed View. The data embedded in the request sent to the Controller is first inspected by the DataSanitizer, then the request is intercepted by the ReferenceMonitor, and if a Right exists for the requested operation on the Controller, it can accept the user input.

Figure 13.23: Sequence diagram for the use case ‘Propagation of a change to the model’

The Controller handles a user event by updating the Model and selecting another View. The request for updating the Model can also be intercepted by the ReferenceMonitor for finer access control. The access control decision is recorded by the SecurityLogger. Finally the selected View gets data from the Model. The request is again intercepted by the ReferenceMonitor.

IMPLEMENTATION

In order for the View to obtain data updates from the Model, it is possible to use a push or pull strategy. In an asymmetric context such as the web, the View has no choice but to constantly poll the Model. In [Str11], a method called long poll is used. In standalone applications, the Observer pattern can be applied [Gam94].

[Gal10] indicates how to avoid open redirection attacks in ASP MVC. An open redirection attack is performed by a tampered-with web application that redirects a request to a URL to an external, malicious URL.

EXAMPLE RESOLVED

eLeague can apply the SECURE MODEL-VIEW-CONTROLLER pattern. The following roles are defined: administrator, coach, athlete. Each individual user is asked to register with the system so that they can be authenticated whenever they need to access it. Each operation of the controller can be mapped to a set of authorized roles; for accessing sensitive data, it can be modified to use a secure transport protocol.

CONSEQUENCES

The SECURE MODEL-VIEW-CONTROLLER pattern offers the following benefits:

Authenticity. An authentication system may confirm to the users that they are talking to the right model. Conversely, authentication indicates that the users accessing the model are legitimate.
Confidentiality and integrity. An authorization system can enforce confidentiality and integrity. A secure communication protocol ensures that data in transit remains confidential. The integrity of the system is also guaranteed by the data sanitizer, which eliminates attacks from malicious embedded payloads.
Records. A security logger (page 111) can record all security-sensitive actions. The pattern also has the following potential liabilities:
The security controls introduce some overhead.
The security controls add complexity to the architecture.

KNOWN USES

The ASP .NET MVC framework [Mic11] provides authentication and authorization functionalities at the Controller’s method level. In addition, AntiXSSLibrary and HtmlSanitizationLibrary are two libraries that can be used for protecting against XSS (cross-site scripting) attacks as well as CSRF or XSRF (cross-site request forgery) attacks.
The Struts web framework [The12] provides a validation framework, which is the primary method of validating a Struts-based application. Output sanitization is the process of ensuring that your output does not contain HTML- or XML-specific characters. In addition, roles can be mapped to action mapping objects, a Controller component, and authentication attributes can be specified. The framework supports multiple authentication schemes, such as password authentication, FORM-based authentication, authentication using encrypted passwords, and authentication using client-side digital certificates. SSL can be enabled as a secure transport layer.
The Spring Web MVC framework [Spr12] offers similar security features.

第 13 章 安全中间件的模式

第 13 章 安全中间件的模式

13.1 Introduction

13.2 Secure Broker

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

Use Case: Secure Service Request – Figure 13.3

IMPLEMENTATION

CORBA

.NET REMOTING

EXAMPLE RESOLVED

CONSEQUENCES

KNOWN USES

SEE ALSO

13.3 Secure Pipes and Filters

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

IMPLEMENTATION

EXAMPLE RESOLVED

CONSEQUENCES

KNOWN USES

SEE ALSO

13.4 Secure Blackboard

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

IMPLEMENTATION

EXAMPLE RESOLVED

CONSEQUENCES

KNOWN USES

SEE ALSO

13.5 Secure Adapter

Also known as Secure Wrapper

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

EXAMPLE RESOLVED

CONSEQUENCES

KNOWN USES

SEE ALSO

13.6 Secure Three-Tier Architecture

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

IMPLEMENTATION

CONSEQUENCES

KNOWN USES

SEE ALSO

13.7 Secure Enterprise Service Bus

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

IMPLEMENTATION

CONSEQUENCES

VARIANTS

KNOWN USES

SEE ALSO

13.8 Secure Distributed Publish/Subscribe

CONTEXT

PROBLEM

SOLUTION

第 13 章安全中间件的模式

第 13 章安全中间件的模式