Xem mẫu

Security of Infrastructures for Web Services 209 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. Aspecial 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. Server ProductHome Container Create Home Object Client Product Invoke create ProductBean EJB Object Figure 7.17 Main parts of EJB architecture. 210 Chapter 7 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— Security of Infrastructures for Web Services 211 Container address space (JVM) Client address space (JVM) EJB object stub Caller Identity EJB object Enterprise Bean instance Caller Identity Enterprise Bean class AccessControlEntries BeanIdentity Container EJB server 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 CORBACSS: (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 212 Chapter 7 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 CORBAsection 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 Security of Infrastructures for Web Services 213 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 ... - --nqh--
nguon tai.lieu . vn