Mastering Web Services Security phần 7 ppsx

[WebMethod] public double GetProductPrice(int id) { PrincipalPermission memberPerm = new PrincipalPermission(null, “member”); PrincipalPermission customerPerm = new PrincipalPermission(null, “customer”); memberPerm .Union(customerPerm ).Demand(); } The imperative role-based control adds not only more flexibility but also granular- ity of access checks that is even finer than method-level. However, developers pay for these benefits by making their application code security-aware, which is a high price unless you develop very limited applications with a small number of methods and security policies that never change. If you don’t want the trouble of coding access checks into your Web Service methods, consider instead implementing authorization enforcement by a specialized HTTP module, as described earlier. This concludes the discussion of the building blocks of access control in your ASP.NET Web Services. Depending on your application security requirements and design, you might find some built-in features sufficient for your needs—such as IP-based restriction mechanisms (preferably combined with IPSEC), Windows DACLs, and ASP.NET URL authorization. On the other hand, you might have to resort to .NET roles (using them either declaratively or programmatically) or HTTP authorization modules, or even a combination of several mechanisms. Each mechanism has its own advantages and dis- advantages, which hopefully have been explained to you well enough to allow you to make the right decisions when designing secure ASP.NET Web Services. No matter how well the access control solution has been designed and imple- mented, it is never perfect. This is why it is imperative to implement a secure audit mechanism that makes users of Web Services accountable for their actions and detects security breaches. Audit As with other security mechanisms available in ASP.NET Web Service implementa- tions, the potential choices you have for implementing auditing are Windows OS, ASP.NET itself, CLR, SOAP Security, and IIS. ASP.NET and SOAP Security don’t define any functionality specific to auditing, leaving you with the other three. Out of the three, as in the cases of access control, data protection, and authentication, you have the dilemma of choosing between simplicity and capability. We describe the options in the following subsections, starting with the simple ones. Audit on Windows Files and IIS URLs Audit mechanisms for the Windows file system allow configuring the generation of audit records on file access. For the purpose of ASP.NET Web Services auditing, you can turn on auditing for read access on asmx files, as shown in Figure 8.15. Securing .NET Web Services 251 Figure 8.15 Setting audit on a Web Service file. (Courtesy: Microsoft Corporation). A sample security audit event, which would be generated for each invocation exe- cuted by the specified clients on a Web Service, is shown in Figure 8.16. This solution for security auditing of ASP.NET Web Services is similar in its capabil- ities, advantages, and weaknesses to the audit provided by IIS, which we described earlier. The major difference between the two is the security-oriented nature of file access auditing, and the performance and access statistics orientation of IIS logs. Figure 8.16 A sample event generated as a result of an invocation on StoreFrontService. (Courtesy: Microsoft Corporation). 252 Chapter 8 Both are an easy way to turn on basic auditing for your Web Services without spend- ing much effort. As with many other approaches this book describes, since the approaches are simple, they are not very powerful. What does this mean in the case of auditing? The main limitation is granularity. Since each file or URL is an ASP.NET Web Service with one or more methods, there is no way to set up these audit mechanisms so that only access to particular methods triggers generation of audit/log records. Another important issue is the level of information provided by the audit. An audit or log record does not contain information about what method was invoked and with what parameters. If non-OS accounts are used for clients, then client identity will not be recorded either. So, these two techniques, although simple, don’t provide very effec- tive security auditing of ASP.NET Web Services. Alternately, you can “manually” cre- ate audit events using .NET basic service classes. .NET Log Classes Event-logging classes that come with the .NET Framework SDK provide a program- matic way for your ASP.NET Web Services to record important events, not necessarily related to security. Windows platforms come with a standard user interface for view- ing the logs, the Event Viewer, shown in Figure 8.17. Using the CLR’s EventLog class, you can connect to existing event logs on both local and remote computers, and write entries to these logs. You can also read entries from existing logs and create your own custom event logs with this class. Figure 8.17 Windows Event Viewer, integrated into Microsoft Management Console, provides event-viewing capabilities. (Courtesy: Microsoft Corporation). Securing .NET Web Services 253 If you write to an event log, you must specify or create an event Source. The Source registers your application with the event log as a valid source of entries. You can only use the Source to write to one log at a time. The Source can be any random string, but the name must be distinct from other sources on the computer. However, a single event log can be associated with multiple sources. Windows 2000 has three default logs: Application, System, and Security. Other installed applications and services can have additional event logs. You can use EventLog to create custom event logs. For example, the code below creates a custom event log “StoreFrontApp” first, as a side effect of cre- ating a new event source. When writing to an event log, in addition to sending the message, you can specify the type of the log entry, to indicate whether the message is an error, a warning, or information. You can also specify an application-defined event ID and category to dis- play in the Type and Category columns of the event viewer. Finally, you can also attach binary data to your event entry if you need to associate additional information with a given event. The code below illustrates steps an application would take to prepare and write to a log. using System; using System.Diagnostics; class LoggingSample { public static void Main(){ string sourceName; string logName; string eventText; short category = 11; sourceName = “StoreFrontWebService”; logName = “StoreFrontApp”; eventName = “SetProductPrice for product with id=3510934 was called”; // Create the source, if it does not already exist. if (!EventLog.SourceExists(sourceName)) EventLog.CreateEventSource(sourceName,logName); // Write an informational entry to the event log. EventLog.WriteEntry(sourceName,eventText); // Create an EventLog instance and assign its source. EventLog myLog = new EventLog(); myLog.Source = sourceName; // Another way to write detailed entries byte[] myByte=new byte[10]; for(int i=0;i<10;i++) { myByte[i]= (byte)(i % 2); } 254 Chapter 8 myLog.WriteEntry(eventText, EventLogEntryType.Information, 0, category, myByte); // Delete source optional EventLog.DeleteEventSource(sourceName); } } The code sample above generates two events, the latter of which is shown in Figure 8.18. When you develop your application service with the use of Event Log, keep in mind that an application has to have additional privileges to be able to write to Security log. Also, most of the unprivileged accounts, such as ASPNET, would not be able to create their own source. An account with more privileges (for example, Administrator) would have to do it for them. Another feature of Windows logging facilities is that records from any log, other than Security, can be erased, making the logs an unreliable place for storing security audit records. One of the items in our wish list for ASP.NET security is the provision of audit records generation outside of a Web Service. We think this is important to have in order to achieve a Web Service with good audit characteristics. Why? To have an effective audit service in your applications it is important to control audit generation without getting inside of the applications. The only way to do this with ASP.NET Web Services today is to write your own HTTP module responsible for auditing incoming SOAP requests. Figure 8.18 A sample event generated by the accompanying code fragment and viewed using Event Viewer. (Courtesy: Microsoft Corporation). Securing .NET Web Services 255 This concludes our discussion of the building blocks of ASP.NET Web Services secu- rity. We hope you now have a fairly good idea of what you can do and how you can use various means to protect your Web Services. We deliberately avoided prescribing any specific approach because you have choices for every type of security functionality— authentication, data protection, access control, and auditing—and the way you com- bine the choices depends largely on the specific risks in your application domain and on your business requirements. To give an example, we show in the next section how these choices were made for our sample application, eBusiness/ePortal. This is also an example of putting everything together and implementing protection for a concrete system based on ASP.NET and other Microsoft technologies. Securing Access to eBusiness Since StoreFrontService acts as a SOAP gateway to the actual business logic and data access layer implemented as a COM+ server, StoreFrontMiddleTier, the middle tier, enforces access control policies. The Web Service only authenticates the incoming SOAP requests, as shown in Figure 8.19. If a user of ePortal wants to see the prices of the items and potentially purchase them, the user has to log in by providing a username and password. The presentation tier at ePortal does not authenticate the user. Instead, it uses the authentication data to perform HTTP basic authentication when making SOAP/HTTP invocations to the eBusiness Web Service hosted by the IIS. Impersonation in this case comes in very handy, for it enables the Web Service to use the client’s identity when calling the COM+ server and accessing other resources. The main drawback of this schema is the neces- sity of mapping ePortal customers and members into OS accounts at the machines run- ning the Web Service and COM+ server at eBusiness. Moreover, both these machines have to share the account database by, for example, being in the same Windows domain. We did not show in this example how to use Microsoft technologies to per- form document-oriented authentication using HTTP modules architecture, since this is far from trivial. SSL is used for protecting data in transit between ePortal and eBusiness, whereas all invocations between the Web Service and COM+ server are protected by DCOM wire protocol cryptographic protection. Given the business scenario for the example, there was no need for message-oriented protection of data. We did not define any comprehensive audit service. Implementing SOAP-specific auditing at the Web Service and at ePortal would require a significant amount of work. Therefore, we just enabled IIS-based logging of requests accessing corresponding URLs. Service continuity has been increased by configuring corresponding IIS and COM+ applications in ePortal and eBusiness to run in individual processes. This allowed us to isolate faults and make sure that, for example, IIS would not crash even if the Web server process failed. 256 Chapter 8 Figure 8.19 eBusiness enforcement of authentication and access control. Summary The purpose of this chapter was to give an example of concrete mechanisms available in the Windows world that realize various security functions for protecting Web Ser- vices. We described four ways of creating Web Services using Microsoft technologies. You can make COM+v1.5 components available to SOAP clients, wrap COM DLLs with configurable bridges provided in the SOAP toolkit, use .NET remoting, or take advantage of ASP.NET. After illustrating the use of ASP.NET for building Web Services on a sample ePortal/eBusiness application, we described the options you have for securing such services. The options match the building blocks of ASP.NET Web Ser- vices: Windows OS, IIS, .NET, and ASP.NET. Once more, we illustrated these concepts by describing the protection of our sample system. Overall, Microsoft products provide a convenient family of technologies to support the security of modest-sized applications with little effort. As soon as your require- ments for authentication, access control, accountability, and availability grow to the enterprise scale, you will need either significant amounts of in-house development or IIS ASP.NET ePortal.aspx eBusiness.comePortal.com SOAP server HTTP Basic Authentication IIS ASP.NET MiddleTier Server Accounts COM+ Web browser Portal.com/ Internet customer HTTP POST DCOM Authentication Username: Password: Login Logout ********* bcustomer1 Impersonates authenticated user Securing .NET Web Services 257 additional third-party products and services to fill the gap. Fortunately, .NET in gen- eral and ASP.NET in particular have a good architecture capable of accommodating various security extensions quite well. If you want to find out more about the security of ASP.NET in general and the security of its Web Services in particular, the online book from Microsoft (2002b) is a good collection of relevant information. In the next chapter, we will describe how to secure Java-based Web Services. As you will see, the style of security solutions for those environments is significantly different than it is for .NET Web Services. 258 Chapter 8 259 In this chapter we will describe how Java platforms may be used to secure Web Ser- vices. One of the promises of Web Services is the ability to make your existing server applications available to your employees, customers, and partners whether they are local or remote, establish a casual connection, or have a long-term relationship with your company. It would seem that Java 2 Platform, Enterprise Edition (J2EE), includ- ing Enterprise Java Beans (EJB), would fit well within this new distributed paradigm. This chapter will show you how the Java community is working to define security to bring the Web Services vision to a reality. While the principles in this chapter apply to a variety of Java implementations, we will often use application servers since they are typical services platforms in Java Web Services scenarios. In the larger context, EJB, defined originally by Sun Microsystems, has gained wide acceptance as the open standard for server component architectures. Products based on the EJB specification have compelling advantages: They shield application devel- opers from many of the low-level object service details (such as transactions and secu- rity), they enable enterprise beans to be moved to another environment with minimal effort, and they are interoperable with other EJB products. All of these capabilities are desirable in a Web Services environment. The software system that supplies the EJB-related services to the application devel- oper is the application server. Application servers, which provide a convenient environ- ment for building distributed business applications, are widely available from a number of vendors, including IBM, BEA, Oracle, Sun, and Iona. Most of these vendors have upgraded their application servers to be Web Services aware. Because application Securing Java Web Services CHAPTER 9 servers are targeted at enterprise deployment, it’s no surprise that security is generally addressed in these architectures. Without a good security solution protecting the cor- porate data on an application server, most businesses would not be willing to make their data accessible to Internet Web clients. This chapter assumes that you have worked with Java applications and EJB, have written programs for some application server, and are familiar with the existing Java security mechanisms as described in Chapter 7, “Security of Infrastructures for Web Services.” We are going to look at how security can be handled in a Java-enabled Web Services environment. Although EJB is, for the most part, a server-side architecture, an enterprise bean can act as a client and call upon other beans, thus fully participating in a Web Services scenario. This chapter will examine how Java applications, as well as EJB servers, can be used in conjunction with Web Services. We will also use the ePortal-eBusiness example that we have been developing in previous chapters to give concrete examples of using Java with Web Services. We will limit detailed examination of our example to the path from the ePortal Web server to a Java server supplying prices for products at eBusiness. The previous chapter used our example to describe how to secure a Web Services system based on Microsoft’s technologies. In this chapter we will replace the COM+ portion of the example with a Java platform. We will also use a Web server other than the Microsoft IIS Web server, and we’ll replace the .ASP layer with the J2EE equivalent. You will notice that the discussion of Web Services security for Java is substantially different from our previous chapter on .NET. The chapters differ because the two tech- nologies approach Web Services in very different ways. .NET provides a specific con- crete Web Services solution that is defined and implemented by a single vendor: Microsoft. On the other hand, Java Web Services represent a whole family of different solutions from a variety of vendors. To ensure that this chapter is relevant across dif- ferent products, we focus on the Java standards that define common system features as well as the security mechanisms of a typical Java application server. Although this chapter spends less time than the previous one on specific Web Services security prod- uct solutions, we do describe the approaches of a few different representative vendors: Sun and IBM as examples of Web Services-enabled Java vendors, and Systinet as a Web Services development platform vendor for non-Web Services applications. Using Java with Web Services Even though Java is a platform-neutral system, it has a few areas that do not yet fully address Web Services requirements. For example, until recently there was no specifica- tion on how to handle SOAP messages, which is one of the basic message protocols of Web Services as they are commonly defined. Ongoing work by the Java Community Process (JCP) is defining a number of these missing pieces. These extensions to Java take the form of Java Specification Requests (JSRs). Some JSRs that are pertinent to Web Services are: ■■ JSR 31 defines a facility for compiling XML schema into Java Classes that parse, generate, and validate documents. ■■ JSR 67 defines APIs to transport Web Service messages. ■■ JSR 101 defines APIs that support XML-based RPC. 260 Chapter 9 [...]... 32 33 Securing Java Web Services 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 . existing Java security mechanisms as described in Chapter 7, Security of Infrastructures for Web Services. ” We are going to look at how security can be handled in a Java-enabled Web Services environment and IBM as examples of Web Services- enabled Java vendors, and Systinet as a Web Services development platform vendor for non -Web Services applications. Using Java with Web Services Even though. on the pre -Web Services method of requiring you to associate users with roles? Even though your Java provider may advertise itself as Web Services enabled, it may not be Web Services security enabled,