Mastering Web Services Security phần 6 ppt

Fully compliant EJB products support the IIOP protocol, leveraging IIOP and CSIv2capabilities and allowing CORBA clients that can be written in languages other thanJava to access enterpr

uses the NET Framework configuration GUI to create a security policy deploymentpackage, and then installs it across multiple machines.

Synchronization of machine-level policies and changes to the enterprise policies aredone the same way Since the whole technology is so new, it’s hard to predict how thisrelatively low-tech way, with questionable administration scalability, will be accepted

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 thatthe same principal can be associated with several threads, and the same identity can berelated to several principals, as shown in Figure 7.15

Since a thread’s principal and the associated identity are not bound to the Windowsidentity of the process, a piece of code, provided it has enough privileges, can replaceboth the principal and the identity on its thread with any other implementation of theinterfaces This makes the whole model of NET principal and identity very flexibleand provides opportunities for custom authentication schemes to be integrated withbuilt-in access control—a key enabler of electronic commerce applications At the sametime, the flexibility demands very careful permission administration to avoid openingsecurity holes in NET

The UML class diagram in the figure also shows public methods and properties thatcan be used to inspect the corresponding interface implementations A security-aware

application can check if a principal has a particular attribute by invoking method Role(string attribute), and obtain a reference to the corresponding identity via property

IsIn-Identity Identity interface implementation can be queried if it has been created as aresult 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 run-ning 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

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 eventwhen 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, tion, flexibility, and extensibility of security mechanisms Its architecture is tailored forpractical problems, not for academic challenges Because it is not as extensive asCOM(+) and CORBA security, it is closer to Java in its relative minimalism and exten-sibility More an execution framework than a middleware platform, NET with itsremoting mechanisms does not implement authentication, message protection, andother functionalities essential for distributed applications Instead, it relies on the host-ing application server platform, such as IIS and COM+, to complete the protectiontask Similarly, J2EE serves as an application server platform for distributed Java appli-cations You can find a detailed description of NET Framework’s security architecture

Java 2 Platform, Enterprise Edition (J2EE) is gaining popularity as a platform forserver-side Java deployments Like CORBA, J2EE is a specification that defines a con-tract between application developers and vendors of the runtime infrastructure andservices In addition to the specification, Sun Microsystems—which defines J2EE, withthe help of Java Community Process member companies—provides a test suite, a ref-erence implementation, and “BluePrints” documents The latter describe how to usethe J2EE technologies together The current version of J2EE, v1.3, contains the follow-ing 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

direc-tory 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

mid-dleware (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

informa-tion systems

Java API for XML Parsing (JAXP). For working with XML documents

Java Authentication and Authorization Service (JAAS). For accessing

authenti-cation and authorization services

To improve your understanding of this multitude of services and the relationshipsamong them, we show the key elements in Figure 7.16

For our discussion, the most interesting items in the list are EJB and JAAS Eventhough Java Servlets are the first entry point for SOAP requests, Enterprise JavaBeansare the focal middle-tier point in J2EE applications because they contain the main busi-ness logic Therefore, in the next sections, we will describe the EJB security architec-ture 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 standardconsists of the specification and the APIs Products based on the EJB specification havecompelling advantages:

■■ They shield application developers from many of the low-level object servicedetails (such as transactions, state management, persistence management, loadbalancing, security, and others)

Business Partner

or other system

Applets, Applications, CORBA clients

■■ 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 CSIv2capabilities and allowing CORBA clients (that can be written in languages other thanJava) 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 wheremost 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.

ProductBean Create

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 remoteinterface 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 thanthat, 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 theapplication in the deployment descriptor—an XML file with predefined syntax thatholds all the explicit metadata for the assembly The descriptor can be later augmentedand altered in other ways by an application assembler and deployer, who also playspecific 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 MethodInvocation (RMI) API, all invocations between J2EE components are performed usingIIOP 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 EJB2.0), the standard mapping of the EJB architecture to CORBA enables interoperabilitywith multi-vendor ORBs, other EJB servers, and CORBA clients written in a languageother than Java

Because of the IIOP, the same object reference used for CORBA is used in the EJBworld 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 betweenCORBA and EJB lie in their use of a secure channel, as well as their client and serversecurity 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 thesubject 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 thecalling subject has a right to invoke the requested method If so, the container permitsthe invocation on the method

Client Security Service

Because of the use of IIOP and CSIv2, the responsibilities of an EJB CSS are similar tothose of a CORBA CSS: (1) creating a secure channel with the TSS and (2) obtaining theuser’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 securitysubsystem be compliant to CORBASec Therefore, as long as CSS and TSS can “talk” toeach other using CSIv2 level 0, they can be implemented in any form This also meansthat neither CSS nor TSS has to implement auditing or nonrepudiation functions, orany 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 TSSestablishes 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 enterprisebean 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)

ContainerEJB server

EJB object stub

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 Othersecurity-related responsibilities of a container include the following:

■■ Isolating the enterprise bean instances from each other and from other tion components running on the server

applica-■■ Preventing enterprise bean instances from gaining unauthorized access to thesystem 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 onaccess to resource managers, according to the defined security policy

■■ Allowing the same enterprise bean to be deployed independently multipletimes, each time with a different security policy

Secure Channel

The secure interoperability requirements for EJB v2.0 and other J2EE v1.3 containers isbased 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 secureinteroperability that all CSIv2 implementations are required to support This includesSSLv3.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 withsupport for username/password client authentication and identity assertion by usingthe 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 tothe discretion of container vendors

Authentication

Although EJB v2.0 does not mandate any particular mechanism or protocol for clientauthentication, it suggests using the Java Authentication and Authorization Service(JAAS) (Sun 2001) API JAAS provides a standard and uniform interface behind whichauthentication modules, each responsible for a particular authentication mechanism,can acquire client credentials Adhering to the JAAS interface, such modules can beprovided by different parties and used in concert in the same runtime environment onthe client side

Unfortunately, the JAAS specification does not define how client credentials, ticated via JAAS, are passed from CSS to TSS JAAS is a generic architecture used notonly by J2EE but also by J2SE applications It leaves the transport of client credentials tothe EJB server implementation, which could jeopardize secure interoperability between

authen-212 Chapter 7

heterogeneous implementations This is where CSIv2 comes in As you remember fromits description at the beginning of the chapter, CSIv2 enables client credentials orauthentication data to be transported to the TSS in an interoperable form If a TSSreceives 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 orverify the received credentials Once the container knows the authenticated identity ofthe 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 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 Thecommittee of Java Specification Request (JSR) involving 115 experts had just submitted

con-a proposcon-al on this topic for public comments con-at the time this book wcon-as written, so it istoo 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, althoughnot a bean instance If different instances of the same bean have different access controlrequirements, they should be placed in different application assemblies This meansthat the scope of the EJB’s policy domain is the application assembly In addition, it ispossible to grant different permissions for methods with the same names but differentparameter 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 “securityroles.” 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 beanmethod is executed in a context with the caller’s identity It is possible to configureeach bean to either impersonate the caller or to run as a particular security role Thisdelegation is supported in remote calls through the CSIv2 protocol

Administration

Some security administration tasks of EJB servers are performed through changes indeployment 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, arebeyond the scope of the EJB specification and are therefore left up to the vendors ofcontainer products and deployment tools.

Defined independently in each deployment descriptor, access control and delegationpolicies have natural limits on their effects—all the beans are located in the same EJBJAR file However, this does not preclude development of administrative tools that canensure 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 sponding application composed of one or more enterprise beans An application accesspolicy 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

corre-a given type of users of the corre-appliccorre-ation must hcorre-ave to successfully use the corre-appliccorre-ation”

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 thatwould 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

This role should be assigned to the personnel

of the online store who are authorized

214 Chapter 7

con-“method permission” element of a deployment descriptor defines a permission toinvoke 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 tomer, member, and staff on Product beans.

Delegation Policy

Delegation is another policy configurable via the deployment descriptor The 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

<security-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 time context of the bean for processing all invocations Here is a usage example that

run-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

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 followingmethods, similar to those in COM+ and NET, on the runtime context available to thebusiness logic:

■■ getCallerPrincipal() returning implementation of the Principal interface, which

can be used for obtaining its name and hash code, associated with the tion context

execu-■■ isCallerInRole(String roleName) testing if the current caller is in the specified role

N OT E 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 beandevelopers 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 securitypolicies in EJB is limited to the basic tasks However, container vendors could haveproprietary extensions supporting more demanding applications

216 Chapter 7

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 cation server platforms—CCM, COM+ and EJB Understanding the security of yourmiddle tier is a prerequisite to the advanced task of safely exposing the mid-tier func-tionality through SOAP gateways

appli-The first section explained the security aspects of client/server and object 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 thesecurity functionalities used by the ORB layer The majority of the discussed technolo-gies implement (to different extents) the main groups of mechanisms, particularlyauthentication, message protection, access control, credentials delegation, auditing,and administration

para-All other sections reviewed CORBA, COM+, NET, and EJB in the light of the 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 mostlydefined through APIs .NET and EJB mix APIs with declarative policy files COM+ and.NET are defined through implementations, whereas CORBA and EJB are specified bystandards

frame-COM(+) and CORBA belong to approximately the same generation of middlewaretechnologies 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 configurableinterfaces and bundling basic implementations for the majority of users, while lettingmore 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 andEJB, while those with advanced requirements will need to extend the technologies oruse CORBA and COM+, which is more suitable for their end-to-end scalable securityneeds 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 distributedapplication development, and yet CORBA and COM+ have more advanced distributedsecurity mechanisms exposed to security developers and administrators

Next, we shift our emphasis away from an overview of available security gies that support Web Services In the following chapters, we will discuss how thosesecurity technologies can be applied when building a Web Service generally, and ourePortal and eBusiness Web Service example in particular We will begin by examininghow to secure a Web Services implementation using NET

technolo-Security of Infrastructures for Web Services 217

The previous chapters discussed the security needs of Web Services and ways ofaddressing them in general Your specific Web Services security solution depends onthe security mechanisms available on your selected application platform This chapterdescribes the security features you can use when your Web Services are implementedusing the Microsoft NET framework You’ll see that not only are there multipleoptions for building a Web Service with NET, there are also multiple alternatives forprotecting Web Services applications To help you with the multitude of decisions youwill face, we describe at the end of the chapter a prospective approach for protectingour sample eBusiness Web Service when using NET This chapter requires basicknowledge 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 ofMicrosoft’s Internet Information Server (IIS) An important building block ofMicrosoft’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 IISprovides can be classified in the following basic groups: authentication, message pro-tection, access control, logging, and fault isolation, which we describe below

Securing NET Web Services

C H A P T E R

8

IIS authentication mechanisms are not that much different from what most other Webservers provide For each directory, one or more authentication options, shown in Fig-ure 8.1, may be selected

All of the features, except the last method in the figure, are likely to be found on anyother vendor’s Web server Tailored specifically to Windows environments not sepa-rated by firewalls, integrated Windows authentication can use either NTLM or Ker-beros V5 and only works with Internet Explorer 2.0 and later When a user with an IEbrowser attempts to access a protected resource, IIS negotiates with the browser, andone of the two mechanisms gets used

All these methods authenticate incoming HTTP requests If, however, the server isconfigured with SSL/TLS support, then client connections could be authenticated withclient X.509 certificates mapped into OS accounts (Microsoft 2000) Even without clientcertificates, use of SSL/TLS is always a good idea in the case of basic and digestauthentication, because it protects the exchange of authentication data, otherwise vul-nerable to eavesdropping and/or replay attacks

We provided background on these authentication mechanisms in Chapter 3, ting Started with Web Services Security.” If you are looking for additional information,Microsoft 2001a provides a brief summary and also lists pros and cons for each Dis-tinctive to IIS is the way it implements anonymous authentication It is important tounderstand that any, even anonymous, HTTP request is handled by some HTTP han-dler running with a particular identity recognized by the OS If simple delegation, alsoknown as impersonation, is not turned on, then all handlers use the same identity asthe IIS itself Once the administrator enables impersonation, the handlers start work-ing with the identity of the authenticated user But anonymous requests don’t have anyidentity, you might guess Wrong! (See Figure 8.2.)

“Get-Figure 8.1 Per-directory authentication methods available for IIS-hosted applications.

(Courtesy: Microsoft Corporation).

220 Chapter 8

Figure 8.2 IIS uses a configurable user account for anonymous requests.

(Courtesy: Microsoft Corporation).

As Figure 8.2 illustrates, IIS provides stored credentials to Windows using a specialuser account, IUSR_<machinename>, which can be changed to any other account.Even for anonymous requests, HTTP handlers impersonate a legitimate user account,which is assigned particular privileges and granted some permissions Whether or notIIS controls the password, the check box at the bottom of Figure 8.2, affects the permis-sions the anonymous user has When IIS controls the password, Windows authenti-cates the user and creates a network logon that prevents the user from accessingresources on other machines When IIS does not control the password, it uses slightlydifferent means and, as a result, a local logon is created instead A local logon makes itpossible for the corresponding HTTP handler to impersonate an anonymous userwhile accessing network resources, including calls to remote COM and COM+ compo-nents With natively supporting multi-hop delegation Kerberos, introduced in Win-dows 2000, things became even trickier At the end of the day, all this requires you to

be even more careful while designing distributed applications with Microsoft technologies

Protecting Data in Transit

Authenticity, confidentiality, and integrity protection of messages in transit betweenHTTP clients and IIS can be implemented using either SSL/TLS, by configuring theWeb server, or IPSEC (IETF 2002, Microsoft 1999), if this technology is part of yourcompany’s (and your partners’) infrastructure Since SSL is a mature technology thatevery Webmaster is familiar with these days, we will skip the description of particularsteps necessary to configure an IIS server for SSL If you need detailed instructions,there are numerous sources of information Just for starters, read “ConfiguringSSL/TLS” in Chapter 5 of Howard (2000), and you can get up-to-date information bysearching for “IIS SSL” at the Microsoft MSDN Web site (http://msdn.microsoft.com) Keep in mind that both approaches give, at most, point-to-point pro-tection, which may or may not be sufficient, depending on your use of Web Services, as

we discussed in Chapter 6, “Principles of Securing Web Services.”

Securing NET Web Services 221

Access Control

All these efforts by IIS—to use a system account for anonymous requests, map clientsauthenticated with X.509 certificates into user accounts, and support impersonation byHTTP handlers—are mainly for the sake of leveraging native OS access control mech-anisms for protecting IIS resources When an HTTP handler accesses an HTML or anyother file in order to process the corresponding HTTP request, Windows file systempermissions in the form of a discretionary access control list (DACL) are used by the

OS to enforce access control policies Keep in mind that this mechanism is only able on NTFS file systems If a file to be accessed resides on a FAT partition, no accesschecks are done

avail-Two other access control mechanisms—Web permissions and IP-based tions—could be used in addition to DACL controls, if any Web permissions allow you

restric-to set coarse-grained authorization policies per Web site, virtual direcrestric-tory, direcrestric-tory, orfile Since user identity is not taken into account in Web permissions, the same policyapplies to all requests, which could be useful when you need to set a common lowwatermark for a branch of your IIS resources Web permissions allow tweaking the fol-lowing options that are important for Web Services, shown also in Figure 8.3:

■■ Read - Data can be read or downloaded

■■ Write - Data can be written to or files can be uploaded using HTTP PUT verb

■■ Directory Browsing - Clients are able to receive directory listing

■■ Execute Permissions:

■■ None—ASP (.ASP) files and executable (batch, EXE, and DLL) files willnot run

■■ Scripts Only—ASP, but not executable, files will run

■■ Scripts and Executables—Both ASP and executable files will run

Even more coarse grained is the IP address and domain name restriction mechanismprovided by IIS on Windows Server installations Using it, you can grant access to allhosts other than specified, or reversibly, deny access to all but particular hosts As withWeb permissions, this mechanism can be configured to control access to an entire Website or down to specific files

Logging

Security auditing is not an option for IIS, although its logging facilities can serve as apartial substitution If configured to do so, IIS logs information in text format aboutHTTP requests into %winnt%\system32\LogFiles\W3SVC<n>, where <n> is thenumber of the Web site instance You can select, per Web site instance, what informa-tion is recorded about processed requests There are around 20 request-specific detailsand a number of process accounting properties that could be recorded on each request.Figure 8.4 shows the logging properties selection window

222 Chapter 8

Figure 8.3 Web permission options for a virtual directory

(Courtesy: Microsoft Corporation).

Whether to log a request to a particular IIS resource is determined by the option

“Log visits,” shown in Figure 8.3 You can turn this inheritable switch on or off per Website, virtual directory, subdirectory, or file

Figure 8.4 Selecting information to be logged on each HTTP request

(Courtesy: Microsoft Corporation).

Securing NET Web Services 223

Fault Isolation

Fault isolation can be considered as a part of the group of security mechanisms known

as service continuity Although IIS does not offer full-blown service continuity

solu-tions, at least it provides a way to isolate HTTP handlers from the main process inwhich IIS is executing, InetInfo.exe, and from each other This is done through config-uring applications in virtual directories to run with one of the following options (sup-ported by IIS v5):

IIS process. All requests to the files in the virtual directory are handled in thespace of InetInfo.exe Having the best performance, this option does not offerany fault isolation That is, if the handler crashes because of an error in theapplication code, IIS will crash as well

Pooled. Requests to the resources of all virtual directories configured with thisoption run in the same process external to InetInfo.exe The process runs underthe identity of an account controlled by IIS, IWAM_<machinename> This offersthe best performance versus robustness trade-off, because if a Web applicationcrashes, it takes down only other applications, but not InetInfo.exe, which will

be able to relaunch the pool process on the next request that needs one of thepooled handlers This is the default option

Isolated. Executes each Web application in its own process that runs under theIWAM_<machinename> account This option has the highest level of fault isolation—no faulty application could bring down any other application—but it

is not as fast as the previous one

As you can see, IIS security mechanisms provide a regular set of functions ing of authentication, message protection, authorization, logging, and fault isolation.All these functions are integrated with user accounts and file system access controls Ifyou want to find out more about IIS security, look at Howard (2000) The last chapter

consist-of Brown (2000), contains a lot consist-of useful details on this subject as well

In the next section, we will describe the role of IIS in hosting and protecting a ety of Web Services implementations on COM+ and NET

vari-Creating Web Services with Microsoft Technologies

You will need to understand how to build a Web Service if you have a business cation running on a Windows machine and need to expose it to SOAP clients Or, youmay be designing a Web Service from scratch and want to use this new product called.NET but are not sure how to go about it

appli-You have four options to create Web Services with Microsoft technologies, whichwill be explained in this section at a level of detail that will allow you to understandhow to secure the resulting application We have already prepared you in Chapter 7with a description of the supporting infrastructure for building secure Web Services Inthis chapter we will show you the connections back to what was discussed previously,and spend the rest of the chapter discussing additional security mechanisms that sup-port ASP.NET-based Web Services

224 Chapter 8

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 Pro platforms.Turning on SOAP support with this newest version of Microsoft’s application servertechnology is just a matter of selecting a check box in the application properties win-dow and filling in the name of the IIS virtual directory where the application objectswill have their endpoints published, as shown in Figure 8.5 Selection of the check boxinduces the COM+ infrastructure to provide the necessary adapters, install the WebServices bridge with IIS, and generate the proper Web Service configuration and infor-mation files You should note that IIS must be installed on your machine to enableSOAP activation mode for your application After that, all the application’s compo-nents become available via DCOM as well as SOAP/HTTP In addition to exposingobjects via SOAP, your newly created Web Service will get all of the support for theobject life cycle, just-in-time activation, object pooling, and, most important, the secu-rity of COM+, as we described in Chapter 7

This does not mean, however, that SOAP clients will access COM+-based servicesvia a secure channel Unfortunately, message integrity, confidentiality, and authentic-ity protection, provided with DCOM-based secure channels, are not available toSOAP/HTTP channels unless the use of SSL is turned on

Besides the ease of turning SOAP support on, you are also getting an HTTP-basedalternative to DCOM wire protocol for client/server communications This becomeshandy in those situations when COM+ clients and servers are separated by a firewalland you want to reduce the DCOM-related burden of firewall administration DCOMsupport could be hard on firewall administrators because each COM+ server hostrequires one statically configured TCP and/or UDP port for Service Control Manager(SCM), which activates objects and makes them ready to invoke, and a range of ports—one per active COM+ object This port range needs to be large enough to accommodatebursts in the client’s activity and object population Access to COM+ objects viaSOAP/HTTP, on the other hand, requires administration of only one port (tradition-ally, TCP port 80) However, this port has to be better protected because, as with anytunneling solution, once a client is allowed to send its requests to the server, a simpleTCP firewall cannot control what objects on the other side of the tunnel the client isaccessing

Even with all the ease and benefits available for COM+-based Web Services, thereare some limitations and drawbacks The foremost limitation is due to the differencebetween COM and SOAP distribution and computational models Unlike service-

based SOAP, COM is object-based, and passing object references as method in and/or out parameters is a common and widely used practice for COM applications This is

not the case with SOAP, which has no direct counterpart of an object reference

Addi-tionally, the COM computational model allows multiple return values via out

parame-ters This all means that you cannot take an arbitrary COM+ application server andpublish all its components as Web Services and still expect strict interoperability withSOAP-compliant clients

Also, if a COM+ component has to be placed in a transaction context, it will notwork with SOAP clients, because transactions are not supported in SOAP Thereforethe use of COM+ components as SOAP endpoints requires compliance with Web Ser-vices design guidelines that limit design of COM+ applications

Securing NET Web Services 225

Figure 8.5 Turning on SOAP support for COM+v1.5 applications via the properties

window

(Courtesy: Microsoft Corporation).

As we have already pointed out, the two key advantages of Web Services based onCOM+ 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.NETServer or Windows XP Pro in your production environment, so COM+ v1.5 is out ofthe question? In that case, “wrapping” your application’s COM DLLs using tools fromthe Microsoft SOAP toolkit could be an option, as we describe next

Creating Web Services out of COM

Components Using SOAP Toolkit

If the previous option of creating Web Services with Microsoft technologies is the est, the one that we describe in this section is the most affordable You don’t need tohave COM+ components, or Windows.NET Server, or Windows XP Pro machines, oreven the NET framework, for that matter, to create Web Services this way All youneed is your application developed as a set of COM components, and SOAP Toolkitversion 2 or higher from Microsoft’s Web site This is a good way to reuse existingCOM components that may not have been developed with Web Services in mind.Once you have IIS and Microsoft SOAP Toolkit installed, simply launch the WSDLgenerator GUI tool from the toolkit, and select the name of the COM library whereyour application components reside Note that another Web server besides IIS could beused to host a COM-based server, as long as the generic Internet Server Application

easi-226 Chapter 8

Programmer’s Interface (ISAPI) and Active Server Pages (ASP) listener from the SOAPtoolkit can be registered with such a Web server, as discussed below.

The WSDL generator asks to check the methods and objects that will become able through the wrapper On completion, the tool generates a Web Service Meta Lan-guage (WSML) file, with extension WSML, used by the runtime environment to findout which COM objects serve which SOAP requests Another file it generates is in stan-dard WSDL format and describes the newly configured Web Service The last step left

avail-is creating a virtual directory and putting the generated WSDL and WSML files in thatdirectory

The runtime part is as straightforward as the setup With the installation of theSOAP toolkit, a SOAP handler in the form of an ISAPI or ASP (depending on theoptions selected while running the WSDL generator) listener is registered with IIS.When an HTTP message that contains a SOAP request and points to the endpoint cor-responding to the virtual directory you have created comes in, IIS dispatches the body

of the HTTP message to this listener, as shown in Figure 8.6 The WSDL and WSMLfiles, which were created by the WSDL generator at configuration time, drive thisgeneric listener Specifically, the WSML file contains information necessary for the lis-tener to perform the work of loading the DLL, creating an object responsible for serv-ing the request, converting request parameters into a format suitable for calling theobject’s method, invoking the method, and shipping the returned data back to theSOAP client

As with the previous way of creating Web Services, while SOAP Toolkit 2.0 mayallow you to expose existing COM objects through SOAP, this is not true in all cases

(Microsoft 2001c) The main roadblocks are support for Dispatchable interfaces only, and no support for user custom types, such as MS IDL struct Again, many DCOM

features such as lifetime-management, passing objects by reference, and some COMdata types are not supported since they don’t have counterparts in the current SOAPspecification

Figure 8.6 Processing SOAP requests by a SOAP listener and dispatching them to the