Mastering Web Services Security phần 6 ppt

uses the .NET Framework configuration GUI to create a security policy deployment package, and then installs it across multiple machines. Synchronization of machine-level policies and changes to the enterprise policies are done the same way. Since the whole technology is so new, it’s hard to predict how this relatively low-tech way, with questionable administration scalability, will be accepted by enterprises. Code access security is devised to protect against Trojan horses and other malicious code, but it is not as effective in protecting middleware servers as the other mechanism of the .NET security model—access checks against the identity of the executing context. Its core abstractions are principals and identities. Identity represents the user on whose behalf the code is executing. This could be a logical user as defined by the .NET application or developer, and not necessarily the user associated with the operating system process in which the application is running. A principal is an aggregation of a user and the user security attributes, called “roles” in .NET. There is only one principal per thread, and one identity per principal. Note that the same principal can be associated with several threads, and the same identity can be related to several principals, as shown in Figure 7.15. Since a thread’s principal and the associated identity are not bound to the Windows identity of the process, a piece of code, provided it has enough privileges, can replace both the principal and the identity on its thread with any other implementation of the interfaces. This makes the whole model of .NET principal and identity very flexible and provides opportunities for custom authentication schemes to be integrated with built-in access control—a key enabler of electronic commerce applications. At the same time, the flexibility demands very careful permission administration to avoid opening security holes in .NET. The UML class diagram in the figure also shows public methods and properties that can be used to inspect the corresponding interface implementations. A security-aware application can check if a principal has a particular attribute by invoking method IsIn- Role(string attribute), and obtain a reference to the corresponding identity via property Identity. Identity interface implementation can be queried if it has been created as a result of an authentication, the type of authentication used, and the name. Thanks to the .NET declarative attributes that can decorate assemblies, classes, interfaces, and methods, it is possible to instruct the CLR security to ensure that a class, interface, or method is accessed by code only if the principal associated with the running thread has required attributes. As shown in the code below, the developer only needs to put the attribute PrincipalPermissionAttribute in front of the protected element. public class Product : IProduct { [PrincipalPermissionAttribute(SecurityAction.Demand, Role=”customer”)] public double GetPrice() { It is also possible to use the Microsoft Windows security model, if developers wish. In this situation, users and roles are tied to those on the hosting machine; therefore, accounts may need to be created on the hosting system. Security of Infrastructures for Web Services 205 Figure 7.15 Relationships among .NET thread, principal, and identity. Regarding accountability, developers can program an application to send log records to the Windows event log service on a local or remote machine, using the EventLog class that comes with .NET SDK libraries. It even allows an application to receive an event when an entry is written to a log. Unfortunately, there are no declarative means to make .NET Framework perform an audit for security-unaware applications. The .NET security model follows the modern trend towards practicality, simplifica- tion, flexibility, and extensibility of security mechanisms. Its architecture is tailored for practical problems, not for academic challenges. Because it is not as extensive as COM(+) and CORBA security, it is closer to Java in its relative minimalism and extensibility. More an execution framework than a middleware platform, .NET with its remoting mechanisms does not implement authentication, message protection, and other functionalities essential for distributed applications. Instead, it relies on the hosting application server platform, such as IIS and COM+, to complete the protection task. Similarly, J2EE serves as an application server platform for distributed Java applications. You can find a detailed description of .NET Framework’s security architecture in LaMacchia (2002). Thread Interface IPrincipal IsInRole 0 * 0 * 1 1 CurrentPrincipal Identity Interface IIdentity IsAuthenticated AuthenticationType Name 206 Chapter 7 J2EE Java 2 Platform, Enterprise Edition (J2EE) is gaining popularity as a platform for server-side Java deployments. Like CORBA, J2EE is a specification that defines a contract between application developers and vendors of the runtime infrastructure and services. In addition to the specification, Sun Microsystems—which defines J2EE, with the help of Java Community Process member companies—provides a test suite, a reference implementation, and “BluePrints” documents. The latter describe how to use the J2EE technologies together. The current version of J2EE, v1.3, contains the following groups of APIs that can be used by server application developers: Enterprise Java Beans (EJB). These define a standard contract between server- side components and the application servers. Java Remote Method Invocation (RMI) and RMI-IIOP. The latter is the API for standard RMI over IIOP wire protocol used between J2EE components. Java Naming and Directory Interface (JNDI). For accessing naming and directory services. Java Database Connectivity (JDBC). For accessing relational databases. Java Transaction API (JTA) and Java Transaction Service (JTS). Used for utiliz- ing transactional services by applications. Java Messaging Service (JMS). For communicating via message-oriented middleware (MOM) such as IBM MQSeries or Microsoft Messaging Queue. Java Servlets and Java Server Pages (JSPs). For programming presentation logic in Web servers. Java IDL. For programming with Sun’s CORBA ORB. JavaMail. For sending email messages from inside of applications. J2EE Connector Architecture (JCA). For accessing existing enterprise information systems. Java API for XML Parsing (JAXP). For working with XML documents. Java Authentication and Authorization Service (JAAS). For accessing authentication and authorization services. To improve your understanding of this multitude of services and the relationships among them, we show the key elements in Figure 7.16. For our discussion, the most interesting items in the list are EJB and JAAS. Even though Java Servlets are the first entry point for SOAP requests, Enterprise JavaBeans are the focal middle-tier point in J2EE applications because they contain the main business logic. Therefore, in the next sections, we will describe the EJB security architecture. We will cover JAAS when we discuss J2EE support for authentication. Security of Infrastructures for Web Services 207 Figure 7.16 A J2EE deployment (adopted from Roman, Ed. Mastering Enterprise JavaBeans, 2e. Wiley 2002). How EJB Works The EJB standard is an architecture for deployable server-side components in Java. Serving as an agreement between components and application servers, this standard consists of the specification and the APIs. Products based on the EJB specification have compelling advantages: ■■ They shield application developers from many of the low-level object service details (such as transactions, state management, persistence management, load balancing, security, and others). Client Tier Firewall J2EE Server Back-End Systems Message Queue Databases Business Partner or other system Existing System Legacy System ERP System Business Partner or other system Applets, Applications, CORBA clients IIOP HTTP HTTP Web services technologies (SOAP, UDDI, WSDL, ebXML) Web Browser Wireless Device Servlets JMS SQL Proprietary Protocol Web services technologies (SOAP, UDDI, WSDL, ebXML) EJBs JSPs Connectors 208 Chapter 7 ■■ 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 executed in the runtime environment provided by the component’s container. EJB container. Where the EJB component “lives.” An EJB container provides services 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 business 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 standard 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 usually 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 context 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 security 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 credentials or performs client authentication itself, implements message protection policies, and performs access checks before an invocation is dispatched to an enterprise bean. Depending on the application configuration, which is done through the deployment 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 application 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 chapter. 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 support 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, authenticated 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 credentials 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 configured in the deployment descriptor to a new one, which will allow third-party authorization 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 recommend 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 current 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 permissions, 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 corresponding 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 [...]... 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. .. 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 217 CHAPTER 8 Securing NET Web Services The previous chapters discussed the security needs of Web Services. .. 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... 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 NET framework You’ll see that not only are there multiple options for building a Web Service with NET, there are also multiple alternatives for protecting Web Services. .. eBusiness Web Service when using NET This chapter requires basic knowledge of the NET framework and its security mechanisms, which were explained 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. .. 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 . .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. system Applets, Applications, CORBA clients IIOP HTTP HTTP Web services technologies (SOAP, UDDI, WSDL, ebXML) Web Browser Wireless Device Servlets JMS SQL Proprietary Protocol Web services technologies (SOAP, UDDI,. distributed security mechanisms exposed to security developers and administrators. Next, we shift our emphasis away from an overview of available security technologies that support Web Services.

Định dạng
Số trang	46
Dung lượng	651,04 KB