Mastering Web Services Security phần 6 ppsx

■■ They enable enterprise beans to be ported to another environment with mini- mal effort. ■■ They are interoperable with other EJB products. Fully compliant EJB products support the IIOP protocol, leveraging IIOP and CSIv2 capabilities and allowing CORBA clients (that can be written in languages other than Java) to access enterprise bean objects. EJB architecture has the following basic parts, as illustrated in Figure 7.17: Enterprise bean. A special Java component that implements business logic exe- cuted in the runtime environment provided by the component’s container. EJB container. Where the EJB component “lives.” An EJB container provides ser- vices such as transaction and resource management, versioning, scalability, mobility, persistence, and security to the enterprise beans it contains. Multiple enterprise beans typically exist inside a single container. EJB server. Provides runtime environment to one or more containers. Since EJB does not explicitly define the separation of roles between containers and servers, containers and servers usually come inseparable in one system. Remote interface. The remote interface of an enterprise bean represents the bean’s business logic to remote clients. That is, the clients access the bean busi- ness logic via its remote interface. EJB object. Provided by the container and serving as an interception point where most of the work for serving the bean is done. Implements the remote interface on the way to the bean. Home interface. Provides factory methods that allow remote clients to request that an instance of an enterprise bean be created and initialized. Home object. Implements the methods specified in the home interface. Local interface and EJB local object. Provide local access to the bean from other enterprise beans running in the same container. Figure 7.17 Main parts of EJB architecture. Client ProductHome Product create Container Server ProductBean Create Invoke Home Object EJB Object Security of Infrastructures for Web Services 209 Declarative Part Defining remote, home, and local interfaces as well as implementing the business logic in EJB is as easy as in standard Java. Here, for example, is the definition of the remote interface for the Product enterprise bean. package com.ebusiness; public interface Product extends javax.ejb.EJBObject { public float getPrice(); public void setPrice(float newPrice) throws InvalidPriceException; }; The product interface, to be an eligible remote interface, inherits from the EJBObject interface, which defines additional methods needed by an EJB container. Other than that, it is regular standalone Java code that can use all the capabilities including stan- dard or application-specific exceptions, inheritance, method overloading, and so on. A bean developer specifies transactional, security, and other requirements for the application in the deployment descriptor—an XML file with predefined syntax that holds all the explicit metadata for the assembly. The descriptor can be later augmented and altered in other ways by an application assembler and deployer, who also play specific roles in the life cycle of enterprise beans predefined by EJB specification. If you want to extend your knowledge of EJB, we recommend reading a definitive guide, Mastering Enterprise JavaBeans by Ed Roman (Roman 2002). Runtime Part While the remote object model for EJB components is based on the Remote Method Invocation (RMI) API, all invocations between J2EE components are performed using IIOP. The use of the RMI remote invocation model over the IIOP wire protocol is usu- ally referred to as RMI-IIOP. When EJB components use RMI-IIOP (mandatory for EJB 2.0), the standard mapping of the EJB architecture to CORBA enables interoperability with multi-vendor ORBs, other EJB servers, and CORBA clients written in a language other than Java. Because of the IIOP, the same object reference used for CORBA is used in the EJB world. Moreover, it would not be surprising if your EJB server uses a CORBA-like ORB as an underlying layer that handles networking for the server. The similarities between CORBA and EJB lie in their use of a secure channel, as well as their client and server security layer architectures. Roles and Responsibilities of CSS, TSS, and Secure Channel The basic security model for EJB, as depicted in Figure 7.18, is conceptually simple: When the client program invokes a method on a target EJB object, the identity of the subject associated with the calling client is transmitted to the EJB object’s container— 210 Chapter 7 Figure 7.18 The EJB security model. the major part of an EJB application server. The container checks to see whether the calling subject has a right to invoke the requested method. If so, the container permits the invocation on the method. Client Security Service Because of the use of IIOP and CSIv2, the responsibilities of an EJB CSS are similar to those of a CORBA CSS: (1) creating a secure channel with the TSS and (2) obtaining the user’s authenticated credentials or passing username and password over the CSIv2 con- text to TSS, as well as (3) protecting request messages and verifying response messages. The main distinction is that EJB does not mandate that the client or server security subsystem be compliant to CORBASec. Therefore, as long as CSS and TSS can “talk” to each other using CSIv2 level 0, they can be implemented in any form. This also means that neither CSS nor TSS has to implement auditing or nonrepudiation functions, or any of the CORBASec APIs, for the client or server to enforce application-specific secu- rity policies. However, as will be described later, the server container provides a num- ber of methods useful to security-aware applications. Target Security Service Treated by the EJB security model as an integral part of the server container, a TSS establishes and maintains a secure channel with the clients, verifies authenticated cre- dentials or performs client authentication itself, implements message protection poli- cies, and performs access checks before an invocation is dispatched to an enterprise bean. Depending on the application configuration, which is done through the deploy- ment descriptor, the container associates the runtime security context of the dispatched Client address space (JVM) Container address space (JVM) Container EJB server EJB object stub Caller Identity Caller Identity EJB object Enterprise Bean instance Enterprise Bean class AccessControlEntries BeanIdentity Security of Infrastructures for Web Services 211 method either with the identity of the calling client or with some other principal. Other security-related responsibilities of a container include the following: ■■ Isolating the enterprise bean instances from each other and from other applica- tion components running on the server ■■ Preventing enterprise bean instances from gaining unauthorized access to the system information of the server and its resources ■■ Ensuring the security of the persistent state of the enterprise beans ■■ Managing the mapping of principals on calls to other enterprise beans, or on access to resource managers, according to the defined security policy ■■ Allowing the same enterprise bean to be deployed independently multiple times, each time with a different security policy Secure Channel The secure interoperability requirements for EJB v2.0 and other J2EE v1.3 containers is based on the CSIv2 specification that we discussed in the CORBA section of this chap- ter. J2EE requires CSIv2 Level 0 conformance, which defines the base level of secure interoperability that all CSIv2 implementations are required to support. This includes SSLv3.0/TLSv1.0 protected connections with all mandatory TLS (and their SSL equiv- alent) cryptographic mechanisms. Level 0 implementations are also required to sup- port the Security Attribute Service (SAS) layer with stateless CSS and TSS, and with support for username/password client authentication and identity assertion by using the service context protocol. Implementation of Security functions The EJB 2.0 specification focuses largely on authentication and access control. It relies on CSIv2 level 0 for message protection, and it leaves support for security auditing to the discretion of container vendors. Authentication Although EJB v2.0 does not mandate any particular mechanism or protocol for client authentication, it suggests using the Java Authentication and Authorization Service (JAAS) (Sun 2001) API. JAAS provides a standard and uniform interface behind which authentication modules, each responsible for a particular authentication mechanism, can acquire client credentials. Adhering to the JAAS interface, such modules can be provided by different parties and used in concert in the same runtime environment on the client side. Unfortunately, the JAAS specification does not define how client credentials, authen- ticated via JAAS, are passed from CSS to TSS. JAAS is a generic architecture used not only by J2EE but also by J2SE applications. It leaves the transport of client credentials to the EJB server implementation, which could jeopardize secure interoperability between 212 Chapter 7 heterogeneous implementations. This is where CSIv2 comes in. As you remember from its description at the beginning of the chapter, CSIv2 enables client credentials or authentication data to be transported to the TSS in an interoperable form. If a TSS receives authentication data (only username and password for CSIv2 level 0) or creden- tials from a client over CSIv2, it can again use JAAS APIs to authenticate the client or verify the received credentials. Once the container knows the authenticated identity of the client, it enforces access control policies as defined by EJB specification. Access Control The EJB access control model is undergoing an update from the predefined model con- figured in the deployment descriptor to a new one, which will allow third-party autho- rization engines supporting different access models to be used by EJB containers. The committee of Java Specification Request (JSR) involving 115 experts had just submitted a proposal on this topic for public comments at the time this book was written, so it is too early to know exactly what the upcoming changes will be. For that reason, we rec- ommend that you track the work of this JSR at the Java Community Process Web site (http://www.jcp.org), where you will find the latest version of the “J2EE Authoriza- tion Contract for Containers” specification. The rest of this section describes the cur- rent version of the access control model for EJB, which is quite straightforward. Configured by an application deployment descriptor, the container controls access to enterprise beans down to the level of an individual method on a bean class, although not a bean instance. If different instances of the same bean have different access control requirements, they should be placed in different application assemblies. This means that the scope of the EJB’s policy domain is the application assembly. In addition, it is possible to grant different permissions for methods with the same names but different parameter types. The EJB access control model allows us to group methods with “method permissions” and grant access on all methods in a method permission group to one or more “security roles.” Both method permissions and security roles enable administration scalability, which we will describe in detail in the section on security administration for EJB. Delegation EJB v2.0 requires containers to support simple unconstrained delegation, when a bean method is executed in a context with the caller’s identity. It is possible to configure each bean to either impersonate the caller or to run as a particular security role. This delegation is supported in remote calls through the CSIv2 protocol. Administration Some security administration tasks of EJB servers are performed through changes in deployment descriptors. This includes definition of security roles, method permis- sions, and specification of security identity, either delegated or predetermined, for dis- patching calls to bean methods. Other tasks, such as mapping users to roles, specifying Security of Infrastructures for Web Services 213 message protection, administering an audit, and authentication mechanisms, are beyond the scope of the EJB specification and are therefore left up to the vendors of container products and deployment tools. Defined independently in each deployment descriptor, access control and delegation policies have natural limits on their effects—all the beans are located in the same EJB JAR file. However, this does not preclude development of administrative tools that can ensure consistency of the policies across deployment descriptors in multiple JAR files. Access Control Policy A deployment descriptor, besides other things, specifies the access policy for the corre- sponding application composed of one or more enterprise beans. An application access policy is constructed using sections called “security roles” and “method permissions.” Although called a “security role,” it is in fact “a semantic grouping of permissions that a given type of users of the application must have to successfully use the application” as the EJB v2.0 defines it. These permission groupings could have different meanings in each assembly and should be treated as unrelated in most cases. The following deployment descriptor fragment depicts the security portion that would be created for our eBusiness company. In this example, there are four security roles nested in the <assembly-descriptor> element, and a role name and an optional description are nested in each <security-role> element. Also, note that the names of the tags, such as <role-name>, have been defined by the specification and should be used as specified. <assembly-descriptor> <security-role> <description> This role includes the members of the online business who are allowed to access the special products application. Only users who have the role member can access the special products. </description> <role-name>member</role-name> </security-role> <security-role> <description> This role includes the customers of the online business. This role is only allowed to access the regular products. </description> <role-name>customer</role-name> </security-role> <security-role> <description> This role should be assigned to the personnel of the online store who are authorized to perform administrative functions. 214 Chapter 7 </description> <role-name>staff</role-name> </security-role> </assembly-descriptor> This portion of the deployment descriptor defines the security roles called member, customer, and staff and provides a description of each. The EJB specification deliber- ately leaves the mapping between user identities and these roles up to the EJB con- tainer implementation or the employed security technology. Once roles are defined, they can be used in “method permissions” to specify who can invoke what methods. A “method permission” element of a deployment descriptor defines a permission to invoke a specified group of methods of the enterprise beans’ home and remote inter- faces. Here is an example showing how one could define access rights for the roles cus- tomer, member, and staff on Product beans. <method-permission> <role-name>staff</role-name> <method> <ejb-name>Product</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <role-name>customer</role-name> <role-name>member</role-name> <method> <ejb-name>Product</ejb-name> <method-name>getPrice</method-name> </method> </method-permission> Here, we grant full access on both bean classes to staff, and allow customers and members to obtain product prices. Access control is one of the few security policies that can be administered through standard deployment descriptors. Delegation Policy Delegation is another policy configurable via the deployment descriptor. The <security- identity> element, which can be defined for each bean, serves two purposes. If it con- tains the <use-caller-identity> element, then the bean impersonates the caller while serving requests, providing simple unconstrained delegation. If, on the other hand, <security-identity> contains the <runAs-specified-identity> element with a nested role name, then no delegation takes place, and the specified role is associated with the run- time context of the bean for processing all invocations. Here is a usage example that specifies that the security role customer should be used by ShoppingCart beans. Keep in mind that access to a bean is controlled independently of the bean’s identity. Security of Infrastructures for Web Services 215 <enterprise-beans> <session> <ejb-name>ShoppingCart</ejb-name> <security-identity> <runAs-specified-identity> <role-name>customer</role-name> </runAs-specified-identity> </security-identity> </session> </enterprise-beans> There is one more security setting available in EJB deployment descriptors. Since it is useful only to security-aware applications, we describe it in the following section. Enforcing Fine-Grained Security EJB supports fine-grained application-specific access control by defining the following methods, similar to those in COM+ and .NET, on the runtime context available to the business logic: ■■ getCallerPrincipal() returning implementation of the Principal interface, which can be used for obtaining its name and hash code, associated with the execu- tion context ■■ isCallerInRole(String roleName) testing if the current caller is in the specified role NOTE These methods perform their checks on the principal associated with the caller, not the principal that corresponds to the <security-identity> element of the executing bean. EJB makes the life of application deployers easier by having provisions for bean developers to specify in the deployment descriptor what roles an application checks in the calls to isCallerInRole(). It also defines syntax for linking these roles with the ones defined for the application. As you can see, the overall support for fine-grained application-specific security policies in EJB is limited to the basic tasks. However, container vendors could have proprietary extensions supporting more demanding applications. 216 Chapter 7 Summary We hope that this long and dense chapter helped you to get familiar with the security of today’s commercial middleware technologies—CORBA, .NET and Java—and appli- cation server platforms—CCM, COM+ and EJB. Understanding the security of your middle tier is a prerequisite to the advanced task of safely exposing the mid-tier func- tionality through SOAP gateways. The first section explained the security aspects of client/server and object para- digms and traced a recognizable pattern in all of them: client and server security ser- vices, along with a secure channel, constitute a security layer that implements the security functionalities used by the ORB layer. The majority of the discussed technolo- gies implement (to different extents) the main groups of mechanisms, particularly authentication, message protection, access control, credentials delegation, auditing, and administration. All other sections reviewed CORBA, COM+, .NET, and EJB in the light of the frame- work we described in the first section. Through these sections, you could see a multi- tude of ways security functions are designed. CORBA and COM+ security is mostly defined through APIs. .NET and EJB mix APIs with declarative policy files. COM+ and .NET are defined through implementations, whereas CORBA and EJB are specified by standards. COM(+) and CORBA belong to approximately the same generation of middleware technologies and provide a similarly rich—though complex and harder to use—func- tionality. Part of a newer wave, EJB and .NET focus more on flexibility and extensibility, including security design, which enables us to hide the complexity behind configurable interfaces and bundling basic implementations for the majority of users, while letting more sophisticated users plug in complex logic. Users building client/server and simple point-to-point systems can be satisfied with the protection models of .NET and EJB, while those with advanced requirements will need to extend the technologies or use CORBA and COM+, which is more suitable for their end-to-end scalable security needs. This is yet another example of having to make trade-offs: programming models of EJB and .NET are more modern and hide quite a bit of complexity of distributed application development, and yet CORBA and COM+ have more advanced distributed security mechanisms exposed to security developers and administrators. Next, we shift our emphasis away from an overview of available security technolo- gies that support Web Services. In the following chapters, we will discuss how those security technologies can be applied when building a Web Service generally, and our ePortal and eBusiness Web Service example in particular. We will begin by examining how to secure a Web Services implementation using .NET. Security of Infrastructures for Web Services 217 [...]... the security of ASP.NET We will also explain how it all works in concert We will describe ASP.NET security while explaining how all these mechanisms could be selected and mixed together to secure your Web Services Securing NET Web Services ASP.NET Web Services Security SOAP Security ASP.NET Security NET CLR Security IIS Security Windows Security Figure 8.12 Building blocks for ASP.NET-based Web Services. .. using ASP.NET Web Services, which comes next ASP.NET Web Services ASP.NET NET Framework IIS Windows Figure 8.9 Main building blocks for ASP.NET Web Services Securing NET Web Services Implementing Access to eBusiness with ASP.NET Web Services To illustrate the use of ASP.NET in building Web Services, we implemented a subset of the e-commerce scenario used throughout the book The purpose of the Web Service... middle-tier services with their security infrastructure can be exposed securely over HTTP transport to the business partners by means of SOAP gateways The latter are implemented using Web Services technologies How security mechanisms are used to protect this sample system will be described after we first explain the security of Web Services built with ASP.NET ASP.NET Web Services Security The security. ..CHAPTER 8 Securing NET Web Services The previous chapters discussed the security needs of Web Services and ways of addressing them in general Your specific Web Services security solution depends on the security mechanisms available on your selected application platform This chapter describes the security features you can use when your Web Services are implemented using the Microsoft... Request handling by ASP.NET Web Services Securing NET Web Services Web Server StoreFrontService Application web service developer StoreFrontService.asmx StoreFrontService.wsdl WSDL compiler StoreFrontServiceProxy.cs C# compiler web service consumer developer Web Server GrocerToGo Application StoreFrontServiceProxy.dll StoreFrontServiceClient.aspx Figure 8.8 ASP.NET Web Services development process... in Chapter 7, Security of Infrastructures for Web Services. ” IIS Security Mechanisms We begin by providing you with a brief background on the security features of Microsoft’s Internet Information Server (IIS) An important building block of Microsoft’s Web Services solutions, IIS plays a critical role in protecting the hosted NET Web Services that we will describe in this chapter The security mechanisms... mechanisms of ASP.NET Web Services consist of the security available for the building blocks of these services and SOAP security, as shown in Figure 8.12 We have already covered most of the mechanisms in Figure 8.12 We described SOAP security in Chapter 6, and the security of NET’s common language runtime (CLR) was described in Chapter 7 Finally, you became familiar with IIS security mechanisms earlier... next section, we will explain in depth how to employ ASP.NET security for creating secure Web Services Creating Web Services Using ASP.NET All three techniques for creating Web Services discussed so far have their own advantages, but despite this, they share one problem—their computational and distribution models don’t match that of SOAP Web Services For example, COM and COM+ natively support passing... show you the connections back to what was discussed previously, and spend the rest of the chapter discussing additional security mechanisms that support ASP.NET-based Web Services Securing NET Web Services Creating Web Services out of COM+ Components The easiest way to create a Web Service using a Microsoft technology is to use COM+ v1.5 (Lowy 2001), available on Windows.NET Server and Windows XP... Microsoft Corporation) As we have already pointed out, the two key advantages of Web Services based on COM+ v1.5 components are the ease of creating Web Services and the strong COM+ security Additionally, you don’t have to do anything special to protect such Web Services just use the same methods described in Chapter 7 on COM+ security This approach may be straightforward, but what if you don’t use Windows.NET . .NET. Security of Infrastructures for Web Services 217 219 The previous chapters discussed the security needs of Web Services and ways of addressing them in general. Your specific Web Services security. of Web Services based on COM+ v1.5 components are the ease of creating Web Services and the strong COM+ security. Additionally, you don’t have to do anything special to protect such Web Services just. distributed security mechanisms exposed to security developers and administrators. Next, we shift our emphasis away from an overview of available security technolo- gies that support Web Services.