Mastering Web Services Security phần 5 pdf

CORBA, WSDL files in Web Services, files with Java interfaces extending EJBOb- ject in J2EE, and “remoted” class files in .NET. Skeleton. The server’s counterpart of the proxy. Also created from the interface definition, a skeleton performs marshaling/unmarshaling of the call parameters and return values, and hides specifics of the particular ORB implementation. Object adapter. Sits on top of the object request broker (ORB) and accepts requests on behalf of the server’s objects. It provides the runtime environment for instantiating server objects, passing requests to them, and assigning the object IDs, called object references. The object adapter also registers object imple- mentations with the ORB and, sometimes, with the implementation repository, so that the server objects can be discovered at run time. Not all middleware technologies (for example, COM(+)) distinguish object adapters from their ORBs, although the adapters are still there. Object request broker (ORB). Constitutes the core of the middleware layer and implements most of the plumbing, including composition of the messages given to the network layer for sending, determining where to send messages based on the object reference, establishing virtual (session) channels with other ORBs, and dispatching requests to the server objects. An ORB could be implemented just as a library (like most CORBA ORBs), or could be a set of system services (as in COM+). It cooperates with various services, such as naming, fault tolerance, transactions, and load balancing, to make the life of clients and servers easier. In this discussion, we concentrate on the security service. Security service. Often tightly integrated with the ORB, the service intercepts the client’s and server’s interactions to enforce various security policies. Some of them, such as access control, have request granularity and therefore are enforced by request security interceptors. Other policies, such as integrity and confidential- ity protection, are commonly enforced by message security interceptors. Security mechanism implementation. An implementation of generic network security technology such as Kerberos, NTLM, SSL, or IPSEC. By and large real- ized as a set of libraries, a security mechanism implementation generates session keys and performs authentication, encryption/decryption, data signing, and validation. OS and network layers. Perform their usual roles of transmitting the actual mes- sages between client and server. Figure 7.3 is an adequate abstraction of the middleware security, although it is not always completely accurate. For example, it shows all the elements in one elegant stack, whereas this is not the case in real situations; the ORB, security service, and secu- rity mechanism layers have a more complex interaction topology, and most elements in the figure interact with the OS. Some applications, due to their security require- ments, could also call the ORB security service and even the security mechanism directly. Nonetheless, keep this figure in mind when you read about the implementa- tion of client and server security services and the secure channels connecting them. The client and server security services and mechanisms, in cooperation with their ORBs, are the basis for three abstractions very useful for reasoning about distributed systems’ security: client security service, secure channel, and target security service. We will explain them next. 162 Chapter 7 Figure 7.3 Security stack of middleware-based distributed applications. Roles and Responsibilities of CSS, TSS, and Secure Channel The security structure of most distributed systems that are based on the client/server paradigm is composed of a client security service (CSS) and a target security service (TSS), which are connected by one or more secure channels. Their roles are based on the secu- rity requirements for client/server systems (discussed in the previous section, Security and the Client/Server Paradigm). As we discuss what’s expected from these three ele- ments, keep the generic scheme for middleware security from Figure 7.3 in mind. To enforce client security policies, a CSS should be able to establish and maintain secure channels with TSSs and enforce client-side trust, message confidentiality, and integrity, as well as delegation control and audit policies. To perform these tasks, a CSS relies on client application authentication to obtain the credentials used to represent the principal on behalf of whom requests on the server are made. To enforce trust and delegation control policies, a CSS also needs to authenticate the target. Once a CSS and TSS have authenticated each other, both can negotiate the level of channel protection. A secure channel is a useful abstraction that encompasses the functionality necessary for message confidentiality, integrity, and authenticity protection. To retain a channel’s state, CSS and TSS must establish and maintain a security association. The security association establishes the trust in each party’s credentials and creates the security con- text that will be used when protecting requests and responses in transit between the client and the target. Client Application Proxy ORB Security Mechanism Implementation Security Mechanism Implementation Network RPC Abstration OS Server Application Application Server Skeleton Adapter ORB Security Service Security Service Network OS Middleware Security Actual messages Security of Infrastructures for Web Services 163 TSS responsibilities are similar to those of a CSS and have an additional obligation to enforce access control and, possibly, nonrepudiation policies. Although CORBA, COM+, .NET, and J2EE all have different security architectures, they implement the roles and responsibilities of CSS, TSS, and secure channel in simi- lar ways. We describe these common security functions in the following section. How Middleware Systems Implement Security The main distributed security functionalities are: ■■ Authentication ■■ Message protection ■■ Access control ■■ Audit ■■ Delegation ■■ Trust ■■ Administration of all the above Even though some of these functions are more critical than others, it is important to employ all of them to implement a complete security solution for your system. Distributed Authentication Authentication is mainly used by middleware security services to verify the origins of incoming requests and responses. Acting on behalf of the principals, CSS and TSS first authenticate each other using the credentials of the principals (on behalf of which they participate in the exchange of application messages), generate a channel-specific ses- sion key, and use it to encrypt the traffic through the channel. Therefore, the messages comprising requests and responses received from the channel are authenticated by the virtue of being encrypted with the session key. Although, strictly speaking, there are multiple principals involved on each side (the channel, the host, the OS, the ORB, the application, and the user—if any—using the application) and there are even theories of principal calculus (Abadi 1991; Lampson 1991), in practice, those who use the corre- sponding entities assume that everything but the applications and their users can be trusted. This assumption, though not always justifiable, allows significant simplifica- tions of the administration of access control and other policies that rely on authentica- tion, and of the authentication protocols themselves. Authentication Protocols Authentication in a distributed system environment is performed using an authentica- tion protocol, which consists of cryptographic computations and a message exchange protocol. All authentication protocols can be classified according to the cryptosystem 164 Chapter 7 they use. Since most popular cryptosystems today are either symmetric (secret key only) or asymmetric (private and public keys), the authentication protocols also fall in one of the two groups. We described symmetric and asymmetric authentication proto- cols in detail in Chapter 3, “Getting Started with Web Services Security.” NOTE Surprisingly, the authentication of most of today’s commercially distributed systems still relies on sending a plain username and password to the server, possibly using secure channels or hashing the password with a digest algorithm. To perform authentication, a CSS and TSS first need to determine the authentication protocol to be used. The next section briefly describes available methods. Choosing an Authentication Protocol There are commonly two ways to determine which protocol and its parameters should be used for authenticating a CSS and TSS to each other. One way is for the TSS to advertise the protocols it wants to use. The other is to employ a special negotiation phase when establishing a secure channel. A customary place for the information about supported authentication protocols is the target’s object reference. Despite being inherently insecure, an object reference is considered an adequate solution for most systems. NOTE Those security service implementations that employ the Simple Authentication and Security Layer (SASL) protocol (IETF 1997b) specify the type of authentication mechanism they support. This means that the client and server can be configured to negotiate and use one of the standard or customized mechanisms for authentication, depending on the level of protection desired by the client and the server. SASL supports the Generic Security Service (GSS) API, which is a popular programming interface that supports many different authentication protocols. Another method of negotiating a GSS-API-based authentication protocol is to use Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) (IETF 1998). This standard negotiation protocol enables GSS-API peers to determine in-band whether their credentials share common GSS-API security mechanism(s), and, if so, to invoke normal security context establishment for the selected mechanism. The protocol allows negotiating different security mechanisms, different options within a given security mechanism, or different options from several security mechanisms. Once identified, the security mechanism may also negotiate mechanism-specific options during its context establishment. Security of Infrastructures for Web Services 165 Message Protection Once CSS and TSS authenticate each other, they can establish a shared secret session key to be used for verifying message origin authenticity and protecting the integrity and confidentiality of the messages. Using the same principle as in the symmetric key authentication protocols, the sender encrypts the message and the receiver decrypts it with the session key generated as a result of their mutual authentication and known only to them. This ensures that the message was sent by the other peer, a property known as message origin authenticity. Encrypting messages using the session key also provides message confidentiality pro- tection (secrecy). Message integrity is commonly protected by tagging a key-dependent message authentication code (MAC) onto a message before it is sent. Upon receipt, the MAC is recomputed and compared with the one attached to determine if the message has been altered in transit. All three protections do not have to be enforced on all messages flowing between a CSS and TSS. Some objects on a TSS might not require protection for the messages comprising requests and responses for those objects. Some might require only message authenticity. Message protection enforced on each side is governed by the correspond- ing policies. Who defines those policies depends on the capabilities of a particular mid- dleware security technology. Generally speaking, there are several stakeholders who define message protection policies: object owners, system owners, and principals (users). Object owners decide what protection they need for the information supplied to and sent back from the methods on their objects. System owners mandate the pro- tection policy for the messages flowing back and forth from their systems. Principals interacting with remote objects decide what is an acceptable protection level for the information they send to and receive from the servers. Therefore a CSS and TSS need to determine message protection policies for each stakeholder and determine the level that satisfies all parties. In this and the previous sections, we discussed CSS and TSS authentication and pro- tection of the messages flowing between them. The next important element of secure middleware-based computing is controlling access to the server objects. Distributed Access Control Access control in middleware consists of two functions: (1) the TSS making an access decision and (2) enforcing it. See Figure 7.4. The enforcement part is fairly easy since the ORB gives the TSS an opportunity to intercept an invocation and enforce the poli- cies. The hard part here is the access control decision (authorization). Authorizations are challenging because they have to be quick to reduce security-related overhead, but depending on the authorization policies and the number of objects in the application system, the decision process can be quite complex. First, we need to figure out what policies should govern authorization decisions for the request in question. Since the policies are needed for message protection, auditing, and other security functionalities, this task is not as trivial as it might sound. The rea- son is that objects are often organized into groups, each protected by a distinct policy, to achieve scalability in middleware object-based systems. The groups are then orga- nized in complex relations so that large numbers of objects with similar security requirements can be governed by a few base policies. Policies for objects with peculiar 166 Chapter 7 requirements could be obtained through some composition of the policies according to the group relations. An example of such relations is the use of hierarchies, where each node is associated with a policy and leaves in the hierarchy are objects “hanging off” the nodes. This object hierarchy approach allows you to impose base policies near the hierarchy root and to fine-tune the protection of some objects located down the tree. A simple example illustrating object hierarchies is shown in Figure 7.5. Besides the difficulty of determining policies due to the scale, as you remember from the section on the object paradigm, some objects may have many names and some may be anonymous, making it difficult to identify what group(s) they belong to. Addition- ally, object encapsulation and method semantic complexity make objects and their methods opaque to the outside world (at least to the poor security administrators), which then means that an extra level of indirection is required to compute those attrib- utes of objects and methods that can be used for calculating applicable policies. Every middleware security technology described in this chapter categorizes methods into related groups in some way. We will discuss the techniques for determining object group membership and method categorization for each technology. Then, various policies governing access to the object’s method might have to be composed into one “ultimate” policy that is evaluated to come up with a final access decision. The composition may not be trivial since the policies could contradict each other, with one policy granting and the other denying access. Consequently a “metapolicy”, which is a policy about composing policies, is required to resolve the conflicts. How a resulting policy is computed depends on the semantics of the relation and varies from technology to technology. For some, more specific policies take higher priority. For others, all policies are compiled into a list and those at the top of the list take precedence over later ones. There are other strategies as well. Figure 7.4 Access control is a combination of decision and enforcement functions. Middleware Target Security Service Decision Request Access Request Decision Target Application Access Request Enforcement Function Decision Function Security of Infrastructures for Web Services 167 Figure 7.5 Sample hierarchy of object groups. Most practical security policies consist of statements that either grant or deny access. The statements usually contain references to one or more of the following: ■■ Subject attributes such as groups, identity, roles, and clearance, age, location ■■ Resource attributes such as name, the owner identity, security label, location ■■ Operation on the resource ■■ Environmental information such as time of day, day of week, global state (for example, emergency, under terrorist attack) ■■ History information, such as how many times the principal has accessed the resource before ■■ Request information, such as the level of the channel protection through which the request came and through which the response will be sent back ■■ Obligations that specify additional conditions to be satisfied before access is granted, such as an agreement to be signed by the end user, auditing the trans- action, or availability of funds. Policy A Policy B Policy C Group B Group C Group D Group A Object F Object G Object J Object H Policy D 168 Chapter 7 These references need to be resolved before their values can be used in policy eval- uation. The CSS and TSS gather the values in two ways: Push model. In this mechanism, information is “pushed” to the TSS although it was not requested. For instance, the CSS may send an access request including the subject attributes as well as the operation name to the TSS. Pull model. Not all information can be obtained by the CSS beforehand, due to, for example, the cost associated with retrieving it, the inability to do so, or even the low trust that the TSS has in client-provided information. In this situation, a pull model becomes indispensable. The TSS will need to request this security information to have it “pulled” from a security policy server. Some information, such as environmental data, is better to “pull.” At the same time, one can find a combination of push and pull models for a principal or resource attrib- utes. A good example of mixing the push and pull models is the Dynamic Attribute Service (DAS) object in the Resource Access Decision (RAD) architecture (Hartman et al 2001). With RAD, before an access request is dispatched to the policy engines, all principal attributes pushed with the access request are sent to a DAS along with the resource name. The DAS could “pull” additional attributes, which are specific to the access request in question, and add them to the “pushed” ones. It could even replace “pushed” attributes with “pulled” or even drop some, depending on the governing logic. Since access control plays a key role in both middleware and Web Services security, we devote a significant amount of material to the subject in this chapter and several others. Distributed Auditing For any distributed computer system, the purpose of security auditing is to provide support for: Accountability. That is, holding users of a distributed system accountable for their actions Detection of security policy violations. That is, the detection of attempts by unauthorized individuals to access the system and by authorized users to mis- use their access to the system Security auditing is usually implemented by means of an audit service called by the security, OS, and application layers. The audit records are created and collected by the service in a repository called an audit log. The audit log may be used to re-create a global picture of the security-related activities in the system and reveal which users performed which activities. Analysis of this picture, either in real time or after the fact, permits security administrators and auditors to detect violations of security policies or to make system users accountable for their actions. Many components of distributed systems now include some form of security- auditing or event-logging capability, used by applications and middleware to record Security of Infrastructures for Web Services 169 security-relevant events. These services are provided via component-specific inter- faces and use component-specific audit record formats. The distributed nature of middleware systems makes security auditing a more chal- lenging task because of the following related factors: ■■ Within distributed systems, security-relevant activity is not isolated within individual components but spans many components. For example, intrusion attempts may be made via multiple entry points rather than a single point of entry. It is therefore necessary to monitor activity across and between distrib- uted components. As a result, audit records from the components need to be stored in a central place to re-create the state of the whole system and see what happened to it. ■■ It is difficult to maintain global time across distributed components. The order of the audit records in the central log, and even their timestamps, do not neces- sarily reflect the order of the events captured in those records. ■■ Since audit records are sent over the network to a central place, it might take a while before the recording is completed. Synchronous audit calls are usually prohibitively expensive from a performance point of view. To remedy this, modern distributed audit techniques employ store-and-forward solutions and allow asynchronous calls to an audit service. ■■ The lack of guarantees that an event has been logged in the audit repository potentially exposes a system to intrusion attacks. The system could be attacked, but the corresponding audit records may not be logged because the attacker shut down the audit service during the first phase of the intrusion. Another challenge for security auditing in today’s object-based middleware systems is due to the fine-grained nature of the resources and operations on them. Because there are many more methods invoked during each transaction, the amount of col- lected audit records is increased significantly. This makes the audit log far more diffi- cult for security administrators to understand. For that reason, selective use of audited events becomes critical and deserves a security audit policy, which specifies which events in what circumstances should be recorded in the audit log. Audit policies are commonly encapsulated into audit decision objects that decide if a given event should be audited. When we describe the security of the four middleware technologies later in the chapter, we will explain how they implement audit channels, what audit policies they support, and how the policies can be queried via audit decision objects. Distributed Delegation As we described earlier in our section, Security and the Client/Server Paradigm, there are situations in which it is necessary for an intermediate object to use the attributes of the initiating client in a chain of invocations on objects. These situations call for delegation, which allows an intermediate object to act on a principal’s behalf. Strictly speaking, there are two commonly used meanings for “delegation” in the context of distributed applications. One is the delegation of privileges (responsibility) 170 Chapter 7 from one person to another. The second is the delegation of credentials in a security con- text from one application to another. Delegation of privileges from one person to another is a common security requirement, but it is not itself a security service. Delegation of credentials in a security context, which is the focus of this section, is a security service that is supported by the CSS and TSS. To implement delegation of privileges from one person to another, a developer could use delegation of credentials, but this is unusual. Typically, delegation between people is accomplished by granting one person a privilege (for example, “I grant John Smith the privilege of security officer for the next week”). This approach only requires that the user’s security profile be updated via the security administration service; it does not require the use of delegation of credentials between applications. Delegation of credentials defines how a principal’s security attributes are transmit- ted to other objects to allow them to act on the principal’s behalf. It is of particular rel- evance in distributed object systems. Since an object invocation frequently results in a whole chain of calls on other objects, it is common for a target object in the call chain to use the client’s privileges, which allows the target object to pass the access control checks and perform an operation on behalf of the client. See Figure 7.6. As illustrated in Figure 7.6, when an intermediate object receives a client request, it also receives credentials for the client, which are known as received credentials. The TSS uses the received credentials for making access control decisions to determine if the client is allowed to call the intermediate. The intermediate object also has its own cre- dentials, which contain the intermediate’s own security attributes for use when the intermediate acts as a client. When the intermediate then calls the next target, it makes use of invocation credentials, which consist of its own and received credentials. The com- position of the invocation credentials depends on the type of the credential delegation implemented by the middleware technology and the delegation policy that governs the invocation chains in your system. Figure 7.6 Use of credentials by intermediate objects during delegation. incoming request request to next target get_credentials set_credentials Security Current received credentials invocation credentials own credentials Intermediate Object (acts as target, then client) Security of Infrastructures for Web Services 171 [...]... for generating and checking evidence of claimed events Replaceability of security services Allows replacement of security services that are enforced by the ORB Security services Standard set of object security interfaces ORB services Low-level interceptor interface within the ORB to extend beyond security Security ready The ORB has security interfaces, but no implementation; designed for future extensions... Unlike most other middleware security technologies, CORBA objects residing on different Security of Infrastructures for Web Services computers can belong to the same domains, because CORBA security policy domains span multiple computers, and therefore can be governed by the same security policies Enforcing Fine-Grained Security There are several interfaces available to security- aware applications for... The CORBA security specification (CORBASec) defines a framework for providing security services to applications via the CORBA object request broker (ORB) The security service is one of several Common Object Services defined as part of the CORBA standard CORBASec defines two conformance levels for ORB security Any product compliant with CORBASec must support Level 1 or both Level 1 and Level 2: Security. .. to keep a Security of Infrastructures for Web Services variety of security policies consistent if the only way to configure them is on an objectby-object or some other small-scale basis Therefore, the means of administering the security of your distributed applications should scale with the number of resources, the number of users, and the number of resource locations A common way to achieve security. .. its security functionality can fit into a Web Services security architecture How CORBA Works CORBA technology, including the CORBA security service, defines a general-purpose language and OS-independent infrastructure for developing and deploying distributed object-based systems in a broad range of specialized application domains Application systems and the CORBA infrastructure, including the security. .. protection Once the security context is safely established between the CSS and the TSS using CSIv2, it is used on the server to protect target objects In the next sections, we will explain how CSS and TSS responsibilities are fulfilled via security mechanisms implemented by the CORBA security service Implementation of Security Functions Similar to other middleware security technologies, security policies... for Web Services Level 1 ■ ■ Support security- unaware applications ■ ■ Have ORB-enforced authentication, secure invocation, authorization, and auditing ■ ■ Perform simple delegation Level 2 ■ ■ Support security- aware applications ■ ■ Have the ability to select quality of protection, change credentials, select delegation options, and use audit services ■ ■ Support administration interfaces using security. .. a particular permission grouping ■ ■ Inspect the security data of the invocation chain (if the channels are configured to track it), specifically: ■ ■ The number of hops in the chain Security of Infrastructures for Web Services ■ ■ The security information about each of the calls in the chain that crossed an application boundary, such as the caller’s security identifier and name, the authentication... middleware security technology described in this chapter, we explain provisions for configuring and administering available security mechanisms Independent of technology type, security mechanisms are configured and administered through changes to security policies The policies could be presented to the administrators and application deployers as textual configuration files that drive corresponding security. .. eBusiness example to illustrate situations when you might need to enforce fine-grained security specific to a particular application As you recall from the eBusiness example described in Chapter 1, “Overview of Web Services Security, ” users may access information about accounts and products If you go back and look at the security requirements more carefully, you may notice that they do not prevent any user . events Replaceability of security services. Allows replacement of security services that are enforced by the ORB Security services. Standard set of object security interfaces ORB services. Low-level interceptor. approach still keeps your application from being security- aware, Security of Infrastructures for Web Services 1 75 although it requires the middleware security to be capable of using your custom autho- rization. Middleware Target Security Service Decision Request Access Request Decision Target Application Access Request Enforcement Function Decision Function Security of Infrastructures for Web Services 167 Figure 7.5