Mastering Web Services Security phần 5 pot

Nonetheless, keep this figure in mind when you read about the implementa-tion of client and server security services and the secure channels connecting them.The client and server securit

Figure 7.1 Basic client/server paradigm and RPC model

Keep in mind that the relationship between a client and server is always associatedwith a particular invocation For example, in Figure 7.2, B acts as a server when it isinvoked by A, and as a client when it invokes C If B invokes C while processing the

request from A, it demonstrates a request propagation—a request travels from A to B and then, possibly changed, to C This is also referred to as an invocation chain, in which B acts as an intermediate, as opposed to C, a target.

Invocation chains introduce new aspects to the security of distributed systems andmake the security picture much more complex If B invokes C while processing arequest from A, several questions arise First, should B use its own identity, and theaccompanying attributes, when it calls C? Or should it use A’s, so that C believes it

received a request from A? Credentials delegation takes different forms, from a very ple impersonation, in which C does not even know that the request is actually from B, to very complex composite delegation, in which C knows the credentials of all the interme-

sim-diates through which the invocation was propagated In the case of composite tion, C’s access control and other security policies become significantly more complex

delega-to accommodate compound principals Second, should A trust B delega-to use A’s credentials delega-to

call others? Some middleware security models give A this level of control over whom

B can call on behalf of A, which is known as constrained delegation.

Some RPC models support “fire-and-forget” invocations—for example, in Figure7.2, if B sends a request to C, and no response is sent back One example is CORBA’sone-way functions, whereby the client does not expect any response from the serverand is not even guaranteed that its request will be processed at all This is also the casefor the world of SOAP-based Web Services, where, if a method does not return any-thing, no response message is sent to the client

N OT E If you want to learn more about client/server computing, we

recommend Client/Server Survival Guide, Third Edition, by Robert Orfali, Dan

Harkey, and Jeri Edwards (Orfali 1999)—a fun-to-read and very comprehensive

A

Brequest

response

A

Security and the Object Paradigm

CORBA, COM+, NET, and J2EE are all object-based These days, the computing world

takes for granted that any modern computational technology—distributed or not—hasinherent support for objects For the purposes of this section, we assume that you have

a good grasp of objects, and are familiar with terms such as “class,” “method,” sulation,” “polymorphism,” and “inheritance.” For a good book on the basics ofobjects, we recommend Taylor (1997)

“encap-When you add objects to a client/server computing model, there are significanteffects on the overall security infrastructure of your enterprise Objects tend to be offine granularity, that is, they encapsulate small amounts of data and provide diversemethods to manipulate that data Object-based systems usually have many moreobjects of many different varieties, increasing the number of resources in your systemsthat you need to protect, compared to conventional, procedural systems The number

of resource-operation pairs also skyrockets even higher

An object-based security architecture must support large numbers of protectedresources Traditionally, this has been done via resource groupings Objects aregrouped, and policies are defined on those groups Objects with similar names, orthose that reside in the same location, should not be required to belong to the samegroup, since policies do not necessarily follow your application’s topology or namingorganization The same is true for objects to be assigned to the same group; name sim-ilarity and co-location should not be required for being governed by similar policies.There are also transient and short-lived objects, such as those implementing shop-ping carts in the ePortal example used throughout this book Such objects are likely to

be nameless and created without administrator’s control Manually assigning transientobjects to security policies would be unrealistic

In addition, object-based systems tend to have less rigid naming hierarchies, and thenaming mechanism may allow an object to have more than one name Also a concern

is the object identity in some systems, in which two opaque object references may bereused by middleware, making it difficult to determine if the objects they point to aredifferent or the same Whatever middleware security architecture is in place, it mustallow security administrators to define security policies without assuming that theyknow the name of every object in the system Even if an object has more than one name,the same policy should be applied to it no matter what name is used

Of additional security concern is that the methods on objects are no longer limited

to just two or three universal “read,” “write,” and “delete” operations The methodscould be very complex and potentially involve many diverse activities Consequently,security administrators should not have to understand the semantics of the methods

on objects to secure them

Due to encapsulation and other advanced techniques—such as dynamic bindingand on-demand reincarnation of object implementations—that make large distributedsystems scalable and simpler to design, it is difficult to understand which actualresources are manipulated behind an object interface While the job of client develop-ers is simplified by using objects, the encapsulation makes it difficult to determinewhich security policies should govern access to which application objects The securityarchitecture of object-based systems must also have some mechanisms in place thathelp with this problem

Bob Blakley (1999) has a good introductory chapter on object security, which vides some additional information on this topic.

pro-What All Middleware Security Is About

The next sections will describe the four middleware security technologies individually,how they implement the security functionalities for client/server systems, and howthey address the requirements specific to object-based systems To unify this discus-sion, we treat every technology described as an instance of the same scheme No mat-ter if it is NET or Java, COM+ or CORBA, each middleware technology reduces to thisone scheme, shown in Figure 7.3, which we put together to help you understand thegeneral concepts

N OT E Because applications written for COM and COM+ have a lot in

common, we will refer to COM and/or COM+ v1.0 as COM(+) when we do not

need to distinguish between the two.

In the list below, we explain the levels of the middleware stack as depicted in Figure 7.3:

Client application. Makes RPC-like calls to the server Because of the abstractionprovided by the proxy of the server object, the client application does not have

to be aware of any layers below the proxy.2

Server application. Receives RPC calls, serves them, and returns replies

Application server. The runtime environment that provides important services

to the critical high-performance and high-scale business applications Its

pres-ence in the stack distinguishes CORBA component model (CCM) from plain

CORBA, COM+ from COM, and J2EE from Java 2 Platform, Standard Edition

(J2SE) If you have ever tried to implement a business application using plain

COM, Java, or CORBA, you are familiar with how much you need to do to age the object life cycle, engage in distributed transactions, and implement load

man-balancing and fault tolerance The application server layer handles those

func-tions in CCM, COM+, and J2EE Due to its complexity, the layer is often tightly

integrated with the ORB and object adapters (defined below) and therefore

comes bundled with them

Proxy. A local implementation of the remote server object on the client It isolatesthe application from all the details and complexities of the RPC implementation

by realizing syntactically the same interface as the object on the target A proxy

marshals requests to and unmarshals responses from the server, and could

per-form some other housekeeping work A client must have a proxy for each

inter-face it uses on the server Proxies are usually compiled out of the interinter-face

descriptions These are interface definition language (IDL) files in COM(+) and

2 Technically, the application code has to perform some steps to initialize the middleware layer: via CoInitialize call and its friends in COM(+), and ORB.init() in CORBA We omit such details to keep the discussion at the higher abstraction layer for now.

CORBA, WSDL files in Web Services, files with Java interfaces extending ject in J2EE, and “remoted” class files in NET.

EJBOb-Skeleton. The server’s counterpart of the proxy Also created from the interfacedefinition, a skeleton performs marshaling/unmarshaling of the call parametersand return values, and hides specifics of the particular ORB implementation

Object adapter. Sits on top of the object request broker (ORB) and acceptsrequests on behalf of the server’s objects It provides the runtime environmentfor instantiating server objects, passing requests to them, and assigning the

object IDs, called object references The object adapter also registers object

imple-mentations with the ORB and, sometimes, with the implementation repository,

so that the server objects can be discovered at run time Not all middlewaretechnologies (for example, COM(+)) distinguish object adapters from theirORBs, although the adapters are still there

Object request broker (ORB). Constitutes the core of the middleware layer andimplements most of the plumbing, including composition of the messages given

to the network layer for sending, determining where to send messages based onthe object reference, establishing virtual (session) channels with other ORBs, anddispatching requests to the server objects An ORB could be implemented just as

a library (like most CORBA ORBs), or could be a set of system services (as inCOM+) It cooperates with various services, such as naming, fault tolerance,transactions, and load balancing, to make the life of clients and servers easier Inthis discussion, we concentrate on the security service

Security service. Often tightly integrated with the ORB, the service intercepts theclient’s and server’s interactions to enforce various security policies Some ofthem, such as access control, have request granularity and therefore are enforced

by request security interceptors Other policies, such as integrity and ity protection, are commonly enforced by message security interceptors.

confidential-Security mechanism implementation. An implementation of generic networksecurity technology such as Kerberos, NTLM, SSL, or IPSEC By and large real-ized as a set of libraries, a security mechanism implementation generates sessionkeys and performs authentication, encryption/decryption, data signing, andvalidation

OS and network layers Perform their usual roles of transmitting the actual

mes-sages between client and server

Figure 7.3 is an adequate abstraction of the middleware security, although it is notalways completely accurate For example, it shows all the elements in one elegantstack, whereas this is not the case in real situations; the ORB, security service, and secu-rity mechanism layers have a more complex interaction topology, and most elements

in the figure interact with the OS Some applications, due to their security ments, could also call the ORB security service and even the security mechanismdirectly Nonetheless, keep this figure in mind when you read about the implementa-tion of client and server security services and the secure channels connecting them.The client and server security services and mechanisms, in cooperation with theirORBs, are the basis for three abstractions very useful for reasoning about distributedsystems’ security: client security service, secure channel, and target security service

require-We will explain them next

Figure 7.3 Security stack of middleware-based distributed applications.

Roles and Responsibilities of CSS,

TSS, and Secure Channel

The security structure of most distributed systems that are based on the client/server

paradigm is composed of a client security service (CSS) and a target security service (TSS),

which are connected by one or more secure channels Their roles are based on the

secu-rity requirements for client/server systems (discussed in the previous section, Secusecu-rity and the Client/Server Paradigm) As we discuss what’s expected from these three ele-

ments, keep the generic scheme for middleware security from Figure 7.3 in mind

To enforce client security policies, a CSS should be able to establish and maintainsecure channels with TSSs and enforce client-side trust, message confidentiality, andintegrity, as well as delegation control and audit policies To perform these tasks, a CSSrelies on client application authentication to obtain the credentials used to representthe principal on behalf of whom requests on the server are made To enforce trust anddelegation control policies, a CSS also needs to authenticate the target Once a CSS andTSS have authenticated each other, both can negotiate the level of channel protection

A secure channel is a useful abstraction that encompasses the functionality necessary

for message confidentiality, integrity, and authenticity protection To retain a channel’sstate, CSS and TSS must establish and maintain a security association The securityassociation establishes the trust in each party’s credentials and creates the security con-text that will be used when protecting requests and responses in transit between theclient and the target

Network

RPC Abstration

OS

ServerApplicationApplicationServerSkeletonAdapterORBSecurityService

Security

Service

NetworkOSMiddleware Security

Actual messages

TSS responsibilities are similar to those of a CSS and have an additional obligation

to enforce access control and, possibly, nonrepudiation policies

Although CORBA, COM+, NET, and J2EE all have different security architectures,they implement the roles and responsibilities of CSS, TSS, and secure channel in simi-lar ways We describe these common security functions in the following section

How Middleware Systems Implement Security

The main distributed security functionalities are:

■■ Administration of all the above

Even though some of these functions are more critical than others, it is important toemploy all of them to implement a complete security solution for your system

Distributed Authentication

Authentication is mainly used by middleware security services to verify the origins ofincoming requests and responses Acting on behalf of the principals, CSS and TSS firstauthenticate each other using the credentials of the principals (on behalf of which theyparticipate in the exchange of application messages), generate a channel-specific ses-sion key, and use it to encrypt the traffic through the channel Therefore, the messagescomprising requests and responses received from the channel are authenticated by thevirtue of being encrypted with the session key Although, strictly speaking, there aremultiple principals involved on each side (the channel, the host, the OS, the ORB, theapplication, and the user—if any—using the application) and there are even theories ofprincipal calculus (Abadi 1991; Lampson 1991), in practice, those who use the corre-sponding entities assume that everything but the applications and their users can betrusted This assumption, though not always justifiable, allows significant simplifica-tions of the administration of access control and other policies that rely on authentica-tion, and of the authentication protocols themselves

Authentication Protocols

Authentication in a distributed system environment is performed using an tion protocol, which consists of cryptographic computations and a message exchangeprotocol All authentication protocols can be classified according to the cryptosystem

authentica-they use Since most popular cryptosystems today are either symmetric (secret keyonly) or asymmetric (private and public keys), the authentication protocols also fall inone of the two groups We described symmetric and asymmetric authentication proto-cols in detail in Chapter 3, “Getting Started with Web Services Security.”

N OT E Surprisingly, the authentication of most of today’s commercially

distributed systems still relies on sending a plain username and password to

the server, possibly using secure channels or hashing the password with a

digest algorithm.

To perform authentication, a CSS and TSS first need to determine the authenticationprotocol to be used The next section briefly describes available methods

Choosing an Authentication Protocol

There are commonly two ways to determine which protocol and its parameters should

be used for authenticating a CSS and TSS to each other One way is for the TSS toadvertise the protocols it wants to use The other is to employ a special negotiationphase when establishing a secure channel A customary place for the informationabout supported authentication protocols is the target’s object reference Despite beinginherently insecure, an object reference is considered an adequate solution for mostsystems

N OT E Those security service implementations that employ the Simple

Authentication and Security Layer (SASL) protocol (IETF 1997b) specify the type

of authentication mechanism they support This means that the client and

server can be configured to negotiate and use one of the standard or

customized mechanisms for authentication, depending on the level of

protection desired by the client and the server.

SASL supports the Generic Security Service (GSS) API, which is a popular

programming interface that supports many different authentication protocols.

Another method of negotiating a GSS-API-based authentication protocol is to

use Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) (IETF

1998) This standard negotiation protocol enables GSS-API peers to determine

in-band whether their credentials share common GSS-API security

mechanism(s), and, if so, to invoke normal security context establishment for

the selected mechanism The protocol allows negotiating different security

mechanisms, different options within a given security mechanism, or different

options from several security mechanisms Once identified, the security

mechanism may also negotiate mechanism-specific options during its context

establishment

Message Protection

Once CSS and TSS authenticate each other, they can establish a shared secret sessionkey to be used for verifying message origin authenticity and protecting the integrityand confidentiality of the messages Using the same principle as in the symmetric keyauthentication protocols, the sender encrypts the message and the receiver decrypts itwith the session key generated as a result of their mutual authentication and knownonly to them This ensures that the message was sent by the other peer, a property

known as message origin authenticity.

Encrypting messages using the session key also provides message confidentiality tection (secrecy) Message integrity is commonly protected by tagging a key-dependent

pro-message authentication code (MAC) onto a pro-message before it is sent Upon receipt, theMAC is recomputed and compared with the one attached to determine if the messagehas been altered in transit

All three protections do not have to be enforced on all messages flowing between aCSS and TSS Some objects on a TSS might not require protection for the messagescomprising requests and responses for those objects Some might require only messageauthenticity Message protection enforced on each side is governed by the correspond-ing policies Who defines those policies depends on the capabilities of a particular mid-dleware security technology Generally speaking, there are several stakeholders whodefine message protection policies: object owners, system owners, and principals(users) Object owners decide what protection they need for the information supplied

to and sent back from the methods on their objects System owners mandate the tection policy for the messages flowing back and forth from their systems Principalsinteracting with remote objects decide what is an acceptable protection level for theinformation they send to and receive from the servers Therefore a CSS and TSS need

pro-to determine message protection policies for each stakeholder and determine the levelthat satisfies all parties

In this and the previous sections, we discussed CSS and TSS authentication and tection of the messages flowing between them The next important element of securemiddleware-based computing is controlling access to the server objects

pro-Distributed Access Control

Access control in middleware consists of two functions: (1) the TSS making an accessdecision and (2) enforcing it See Figure 7.4 The enforcement part is fairly easy sincethe ORB gives the TSS an opportunity to intercept an invocation and enforce the poli-cies The hard part here is the access control decision (authorization) Authorizationsare challenging because they have to be quick to reduce security-related overhead, butdepending on the authorization policies and the number of objects in the applicationsystem, the decision process can be quite complex

First, we need to figure out what policies should govern authorization decisions forthe request in question Since the policies are needed for message protection, auditing,and other security functionalities, this task is not as trivial as it might sound The rea-son is that objects are often organized into groups, each protected by a distinct policy,

to achieve scalability in middleware object-based systems The groups are then nized in complex relations so that large numbers of objects with similar securityrequirements can be governed by a few base policies Policies for objects with peculiar

orga-requirements could be obtained through some composition of the policies according tothe group relations An example of such relations is the use of hierarchies, where eachnode is associated with a policy and leaves in the hierarchy are objects “hanging off”the nodes This object hierarchy approach allows you to impose base policies near thehierarchy root and to fine-tune the protection of some objects located down the tree Asimple example illustrating object hierarchies is shown in Figure 7.5

Besides the difficulty of determining policies due to the scale, as you remember fromthe section on the object paradigm, some objects may have many names and some may

be anonymous, making it difficult to identify what group(s) they belong to ally, object encapsulation and method semantic complexity make objects and theirmethods opaque to the outside world (at least to the poor security administrators),which then means that an extra level of indirection is required to compute those attrib-utes of objects and methods that can be used for calculating applicable policies Everymiddleware security technology described in this chapter categorizes methods intorelated groups in some way We will discuss the techniques for determining objectgroup membership and method categorization for each technology

Addition-Then, various policies governing access to the object’s method might have to becomposed into one “ultimate” policy that is evaluated to come up with a final accessdecision The composition may not be trivial since the policies could contradict eachother, with one policy granting and the other denying access Consequently a

“metapolicy”, which is a policy about composing policies, is required to resolve theconflicts How a resulting policy is computed depends on the semantics of the relationand varies from technology to technology For some, more specific policies take higherpriority For others, all policies are compiled into a list and those at the top of the listtake precedence over later ones There are other strategies as well

Figure 7.4 Access control is a combination of decision and enforcement functions

MiddlewareTarget Security Service

DecisionRequest

Access

Request

Decision

TargetApplication

Figure 7.5 Sample hierarchy of object groups.

Most practical security policies consist of statements that either grant or denyaccess The statements usually contain references to one or more of the following:

■■ Subject attributes such as groups, identity, roles, and clearance, age, location

■■ Resource attributes such as name, the owner identity, security label, location

■■ Operation on the resource

■■ Environmental information such as time of day, day of week, global state (for

example, emergency, under terrorist attack)

■■ History information, such as how many times the principal has accessed the

resource before

■■ Request information, such as the level of the channel protection through which

the request came and through which the response will be sent back

■■ Obligations that specify additional conditions to be satisfied before access is

granted, such as an agreement to be signed by the end user, auditing the action, or availability of funds

trans-PolicyA

Policy

B

PolicyC

GroupB

GroupC

GroupD

GroupA

These references need to be resolved before their values can be used in policy uation The CSS and TSS gather the values in two ways:

eval-Push model. In this mechanism, information is “pushed” to the TSS although it

was not requested For instance, the CSS may send an access request including

the subject attributes as well as the operation name to the TSS

Pull model. Not all information can be obtained by the CSS beforehand, due to,

for example, the cost associated with retrieving it, the inability to do so, or even

the low trust that the TSS has in client-provided information In this situation, a

pull model becomes indispensable The TSS will need to request this security

information to have it “pulled” from a security policy server

Some information, such as environmental data, is better to “pull.” At the same time,one can find a combination of push and pull models for a principal or resource attrib-utes A good example of mixing the push and pull models is the Dynamic AttributeService (DAS) object in the Resource Access Decision (RAD) architecture (Hartman et

al 2001) With RAD, before an access request is dispatched to the policy engines, allprincipal attributes pushed with the access request are sent to a DAS along with theresource name The DAS could “pull” additional attributes, which are specific to theaccess request in question, and add them to the “pushed” ones It could even replace

“pushed” attributes with “pulled” or even drop some, depending on the governinglogic

Since access control plays a key role in both middleware and Web Services security,

we devote a significant amount of material to the subject in this chapter and severalothers

Detection of security policy violations. That is, the detection of attempts by

unauthorized individuals to access the system and by authorized users to

mis-use their access to the system

Security auditing is usually implemented by means of an audit service called by thesecurity, OS, and application layers The audit records are created and collected by theservice in a repository called an audit log The audit log may be used to re-create aglobal picture of the security-related activities in the system and reveal which usersperformed which activities Analysis of this picture, either in real time or after the fact,permits security administrators and auditors to detect violations of security policies or

to make system users accountable for their actions

Many components of distributed systems now include some form of auditing or event-logging capability, used by applications and middleware to record

security-security-relevant events These services are provided via component-specific faces and use component-specific audit record formats.

inter-The distributed nature of middleware systems makes security auditing a more lenging task because of the following related factors:

chal-■■ Within distributed systems, security-relevant activity is not isolated withinindividual components but spans many components For example, intrusionattempts may be made via multiple entry points rather than a single point ofentry It is therefore necessary to monitor activity across and between distrib-uted components As a result, audit records from the components need to bestored in a central place to re-create the state of the whole system and see whathappened to it

■■ It is difficult to maintain global time across distributed components The order

of the audit records in the central log, and even their timestamps, do not sarily reflect the order of the events captured in those records

neces-■■ Since audit records are sent over the network to a central place, it might take awhile before the recording is completed Synchronous audit calls are usuallyprohibitively expensive from a performance point of view To remedy this,modern distributed audit techniques employ store-and-forward solutions andallow asynchronous calls to an audit service

■■ The lack of guarantees that an event has been logged in the audit repositorypotentially exposes a system to intrusion attacks The system could be attacked,but the corresponding audit records may not be logged because the attackershut down the audit service during the first phase of the intrusion

Another challenge for security auditing in today’s object-based middleware systems

is due to the fine-grained nature of the resources and operations on them Becausethere are many more methods invoked during each transaction, the amount of col-lected audit records is increased significantly This makes the audit log far more diffi-cult for security administrators to understand For that reason, selective use of audited

events becomes critical and deserves a security audit policy, which specifies which

events in what circumstances should be recorded in the audit log Audit policies are

commonly encapsulated into audit decision objects that decide if a given event should be

audited

When we describe the security of the four middleware technologies later in thechapter, we will explain how they implement audit channels, what audit policies theysupport, and how the policies can be queried via audit decision objects

Distributed Delegation

As we described earlier in our section, Security and the Client/Server Paradigm, there are

situations in which it is necessary for an intermediate object to use the attributes of theinitiating client in a chain of invocations on objects These situations call for delegation,which allows an intermediate object to act on a principal’s behalf

Strictly speaking, there are two commonly used meanings for “delegation” in the

context of distributed applications One is the delegation of privileges (responsibility)

from one person to another The second is the delegation of credentials in a security

con-text from one application to another

Delegation of privileges from one person to another is a common security requirement,but it is not itself a security service Delegation of credentials in a security context, which

is the focus of this section, is a security service that is supported by the CSS and TSS

To implement delegation of privileges from one person to another, a developercould use delegation of credentials, but this is unusual Typically, delegation betweenpeople is accomplished by granting one person a privilege (for example, “I grant JohnSmith the privilege of security officer for the next week”) This approach only requiresthat the user’s security profile be updated via the security administration service; it

does not require the use of delegation of credentials between applications.

Delegation of credentials defines how a principal’s security attributes are ted to other objects to allow them to act on the principal’s behalf It is of particular rel-evance in distributed object systems Since an object invocation frequently results in awhole chain of calls on other objects, it is common for a target object in the call chain touse the client’s privileges, which allows the target object to pass the access controlchecks and perform an operation on behalf of the client See Figure 7.6

transmit-As illustrated in Figure 7.6, when an intermediate object receives a client request, it

also receives credentials for the client, which are known as received credentials The TSS

uses the received credentials for making access control decisions to determine if the

client is allowed to call the intermediate The intermediate object also has its own dentials, which contain the intermediate’s own security attributes for use when the

cre-intermediate acts as a client When the cre-intermediate then calls the next target, it makes

use of invocation credentials, which consist of its own and received credentials The

com-position of the invocation credentials depends on the type of the credential delegationimplemented by the middleware technology and the delegation policy that governsthe invocation chains in your system

Figure 7.6 Use of credentials by intermediate objects during delegation.

incoming

request

request to next targetget_credentials set_credentials

Security Current

receivedcredentials

invocationcredentials

owncredentials

Intermediate Object(acts as target, then client)

Motivations for Using Delegation

One reason to use delegation of credentials is to preserve accountability Allowing theinitiator’s credentials to propagate through the middle-tier components enables the finaltarget application (typically a back-end system) to learn the true identity of the originalrequester Without delegation, the target application only learns the identity of an inter-mediate component application Thus, delegation allows authorization or auditing to beperformed based on the original requester rather than an intermediate application

A second reason to use delegation is to allow an intermediate application’s tials to be set at run time It allows an initiator’s credentials to be dynamically assigned

creden-to the intermediate application so that the intermediate may access a resource onbehalf of the client Delegation of security context provides the intermediate applica-tion with great flexibility because the intermediate can access resources on behalf ofclients unknown in advance

Simple delegation. The client permits an intermediate object to assume theclient’s credentials and pass them on or delegate them in subsequent invoca-tions, allowing the intermediate to access objects using the client’s credentials

In this case, the intermediate’s invocation credentials are the same as the ones itreceived from the client There are two variations of simple delegation:

Controlled (constrained or restricted) delegation. The client restricts theintermediate object’s use of the credentials (that is, it controls which privi-leges are delegated or which objects may use the privileges)

Impersonation (unconstrained or unrestricted delegation). The client passesthe credential to an intermediate object with no controls In this case, a subse-quent target cannot distinguish between an invocation from the originalclient and a delegated invocation from the intermediate

Composite delegation. The client permits the intermediate object to use theclient’s credentials as in simple delegation, but both the client’s (that is,

received) and the intermediate’s (that is, own) credentials are passed in quent invocations, allowing for access checks based on both sets of credentials

subse-Traced delegation. The credentials of all the intermediates as well as the tor’s are passed

initia-The initiator can use different credentials when it is accessing a target directly andwhen its credentials are delegated to an intermediate Thus, the initiator may limit theuse of credentials when they are delegated, reducing the privileges an intermediate canuse when acting on the initiator’s behalf

Figure 7.7 Delegation options.

Delegation can be harmful to your system’s security On the other hand, in almost allcomplex systems, delegation is either needed or very difficult to replace with an alter-nate solution In later sections, we will describe the supported delegation options foreach of the middleware security technologies

Object

TargetObject

• Simple delegation: impersonation or controlled

client credentials client credentials

Object

TargetObject

Please keep in mind that different technologies use inconsistent delegation terms, and

there is no universally accepted definition of delegation Since this book needs to define

these terms in a uniform way across a variety of technologies, we use the definitions

from the CORBA Security specification, which is one of the few standard definitions that

we are aware of We use the terms consistently across all chapters in this book for both

Microsoft and Java technologies.

There are major differences between our definitions for delegation and impersonation

and the definitions used by Microsoft In particular, in the Microsoft world impersonation

refers to what we describe in this book as simple delegation constrained to a local

resource That is, in Microsoft literature, if a server “impersonates” the client, the server

can access local resources on the client‘s behalf The ability for a server to access

resources on remote machines on behalf of the client is referred to in Microsoft literature

as delegation Note that in this book, we describe this as simple unconstrained

delegation, which we also refer to as impersonation The inconsistent and confusing use

of these terms by different technologies reflect the inherent complexity of the problem.

Distributed Security Administration

No matter how good the security mechanisms of a middleware system are, they areuseless if you cannot properly configure and administer them to implement yourorganizational security policies Inadequate administrative capabilities cause the cost

of ownership of any distributed application to skyrocket, and also result in a ation of security breaches due to human errors This is why for each middleware secu-rity technology described in this chapter, we explain provisions for configuring andadministering available security mechanisms

prolifer-Independent of technology type, security mechanisms are configured and

adminis-tered through changes to security policies The policies could be presented to the

admin-istrators and application deployers as textual configuration files that drivecorresponding security mechanisms, as GUI windows that provide more restrictedinterface to the files, as APIs, or as any combination of the three Next, we will discussthe administrative capabilities of the middleware security—that is, what organiza-tional security policies you can express and how difficult it is to do so

Security policies are commonly categorized according to the types of security mechanisms:

■■ Authentication policies define which authentication protocols should be

employed with which particular parameters to authenticate principals

■■ User attribute assignment policies govern the security attributes that are assigned

to authenticated users

■■ Message protection policies govern authenticity, confidentiality, and integrity

pro-tection of the messages traveling between system components

■■ Authorization policies are responsible for defining which principals have access

to a particular resource in the distributed application Authorization policiesare usually structured according to one or more access control models, such asmilitary clearance/label based, discretionary owner based, role based, identityand group based, and so on

■■ Audit policies determine which events must be recorded in the audit log under

what circumstances

■■ Credentials delegation policies specify how intermediates use received credentials

for making downstream calls and accessing other resources on behalf of theclient’s principal

Although one language and data model could possibly be used for all types of rity policies, it is common practice to have specific ones for each type of security func-tion For that reason, we will explain each type of security functionality, along with thecorresponding policy capabilities, when describing security technologies

secu-It is hard to imagine having one global policy that would effectively govern access toall resources in a large enterprise Most of the time, security requirements are so diversewithin an enterprise that different policies are needed It is next to impossible to keep a

variety of security policies consistent if the only way to configure them is on an by-object or some other small-scale basis Therefore, the means of administering thesecurity of your distributed applications should scale with the number of resources, thenumber of users, and the number of resource locations.

object-A common way to achieve security administration scalability is to introduce an

additional level of indirection via policy domains, or just domains for short With

domains, enterprise resources and users can be partitioned into groups containing ments of similar security requirements Policies can then be assigned to the domainsinstead of directly to the resources and users Policy domains (1) facilitate administra-tion and protection of resources with similar security requirements, (2) help to achievescale in distributed applications, and (3) enable delegated administration, where local security administrators, as opposed to central ones, administer local resourcesand users

ele-Depending on the particular model for policy domains supported by a given nology, domains could be completely disjointed, have hierarchical relationships, orhave more complex relationships Domain boundaries for policies of different typescould coincide or be independent For example, there could be only one authenticationpolicy domain for an organization, a couple of disjointed authorization domains, andthree hierarchically organized audit policy domains

tech-Normally you find security mechanisms provided by middleware to be well suited

to your needs in securing your application However, there are particular classes ofapplications that require fine-grained control of access to enterprise resources In suchcases, just using middleware security would not provide adequate security The nextsection explains how to handle such situations

Enforcing Fine-Grained Security

Let us use the eBusiness example to illustrate situations when you might need toenforce fine-grained security specific to a particular application As you recall from theeBusiness example described in Chapter 1, “Overview of Web Services Security,” usersmay access information about accounts and products If you go back and look at thesecurity requirements more carefully, you may notice that they do not prevent any userfrom accessing another user’s shopping carts (accounts) This permissive policy is def-initely not desirable, since it does not protect user privacy There are several alternatesolutions for separating users’ accounts, and some require you to build security-awareapplications or custom security logic We discuss the options below

One way to protect shopping carts from access by others is to have one separate icy domain per user This solution keeps your application from being security-aware.However, requiring as many policy domains as users may result in very slow autho-rization checks that would kill your performance More significantly, administrativeoverhead would soar, and in a matter of months your security administrators wouldquit out of frustration

pol-Another alternative is to implement your own authorization logic that would besmart enough to find out which customer a cart belongs to and use this information foraccess decisions This approach still keeps your application from being security-aware,

although it requires the middleware security to be capable of using your custom rization logic Besides developing your own authorization logic, you will also needtwo things: a means for your custom logic to find out the cart owner, and a way to con-figure your middleware security to use custom authorization logic Although theseseem to be fairly straightforward capabilities, most middleware security technologieslack them, and there is a strong chance that your middleware product will not allowyou to implement this approach

autho-One common practice is to create a security-aware application and change the ping cart implementation logic so it checks whether the accessing user is the owner ofthe corresponding account Because this allows us to get back to only one policy for allshopping cart objects, we avoid performance scalability problems, and most impor-tantly, make the life of the security administrators in eBusiness much easier However,the burden is now shifted onto application developers, who need to code the autho-rization logic within the shopping cart implementation We recommend that, when-ever possible, your security-aware applications perform security checks by calling anauthorization server, which separates application logic from authorization logic The final alternative for fine-grained access control is to use delegation to allow aseparate back-office server to enforce the check based on the caller’s credentials Inmany cases, the enterprise may already have fine-grained policies defined in a back-end database or other enterprise repository We will discuss this alternative further inChapter 12, “Planning and Building a Secure Web Services Architecture.”

shop-As you can see, there are many ways of supporting security policies that protectfine-grained application-specific resources Depending on the capabilities of your mid-dleware security, you may be in a position to employ some of them In addition todescribing CORBA, COM+, NET, and EJB in the next few sections, we will explainhow these technologies support fine-grained security

CORBASec defines two conformance levels for ORB security Any product ant with CORBASec must support Level 1 or both Level 1 and Level 2:

compli-Level 1

■■ Support security-unaware applications

■■ Have ORB-enforced authentication, secure invocation, authorization, and

auditing

■■ Perform simple delegation

Level 2

■■ Support security-aware applications

■■ Have the ability to select quality of protection, change credentials, select

delegation options, and use audit services

■■ Support administration interfaces using security policy domains

There are also the following optional functions:

Nonrepudiation.Application interface for generating and checking evidence of

claimed events

Replaceability of security services.Allows replacement of security services that

are enforced by the ORB

Security services.Standard set of object security interfaces

ORB services.Low-level interceptor interface within the ORB to extend beyondsecurity

Security ready.The ORB has security interfaces, but no implementation;

designed for future extensions

The rest of this section provides a high-level description of CORBASec so you cansee how its security functionality can fit into a Web Services security architecture

How CORBA Works

CORBA technology, including the CORBA security service, defines a general-purposelanguage and OS-independent infrastructure for developing and deploying distrib-uted object-based systems in a broad range of specialized application domains Appli-cation systems and the CORBA infrastructure, including the security service, aredefined using standard CORBA declarative facilities

Declarative Part

All entities in the CORBA computing model are identified with interfaces defined inthe OMG Interface Definition Language (IDL) CORBA IDL resembles C++ in its syn-tax and constructs A CORBA interface is a collection of three elements: operations,attributes, and exceptions Interface definitions can inherit other interfaces to allow

interface evolution and composition The following IDL fragment from our eBusinessexample shows the interface Product:

typedef string ProductID;

The interface defines the following:

■■ Attribute ID of type ProductID, which is an alias for a native type string

■■ Operation getPrice(), which returns the price of the product associated with aparticular instance of the interface

■■ Operation setPrice(), which allows the product price to be set If the price value

is out of the supported range—for example, negative—the operation throws auser-defined exception InvalidPrice

The CORBA standard defines how IDL constructs are translated into various gramming languages It allows multiple language bindings, which means that CORBAobjects can be coded in different programming languages and yet interoperate withclients and each other Because of this, objects from different environments residing ondifferent machines with different computing architectures can be integrated andshared among clients, which makes IDL-based objects inherently distributable

pro-Runtime Part

When CORBA objects are deployed, they reside in OS processes and utilize CORBAmiddleware in the form of ORBs to make their functionality available to the clients aswell as to receive and process invocations and return the results Objects can act asclients as well, that is, make invocations on other objects, creating chains of invoca-tions Clients and targets may reside in the same or different processes or in differenthosts

A CORBA ORB is responsible for core middleware functions, such as:

■■ Registering, keeping track of, and finding interface implementations

■■ Introducing clients to needed server objects

■■ Providing communication transport from a client to a target

Wire Protocol

CORBA ORBs communicate with each other, including sending object requests, bymeans of a special protocol for inter-ORB communications called Generic Inter-ORBProtocol (GIOP) Because GIOP is a connection-oriented protocol and requires reliableservice and presentation of communicated data as a byte stream, GIOP messages aredelivered over the TCP in TCP/IP networks Defined by the OMG, Internet Inter-ORBProtocol (IIOP) is a specialization of GIOP using TCP GIOP messages sent between thesender and receiver ORBs are translations of request/response interactions betweenthe corresponding CORBA client and server object

From a security point of view, it’s important to note the following about GIOPRequest messages:

■■ To identify an object, the server uses an object key that is opaque to anybody

except the hosting server The client obtains the object key from the object ence

refer-■■ A list of service contexts accompanies all request and reply messages; it’s a place

for passing request-related data that different services, such as transaction and

security, need to exchange

Security service passes all its data related to a particular request or reply in the form

of a service context list element in GIOP Request and Reply messages We’ll discussthis in more detail later in the chapter when we discuss CORBA secure channels

Object Reference

In order for a CORBA object to be accessible to its clients, it needs to have some lent of an address Object addresses are presented in the form of interoperable object ref-erences (IORs) The ORB that hosts the object, working together with the object adapter,can create such references using the host IP address, the TCP port number, and otherinformation essential for locating the object inside the ORB Obviously, this information

equiva-is specific to the TCP communication protocol because the IP address and the port ber are part of the address The information is also specific to the ORB that created thereference, because the object key is ORB-specific To make such references understand-able across ORBs from different vendors, the OMG defined a format for IORs

num-From a security perspective, the most interesting part of the IOR is the list of ponents, which allows additional information to be attached to the IOR so that it’savailable when the client establishes a connection with the server to make object invo-cations Several standard components are specifically defined for supporting security,and we’ll discuss them in the following sections

com-If you want to look further into CORBA, books include Orfali (1997), Ruh (1999),Siegel (2000), and Pope (1998)

Roles and Responsibilities of CSS,

TSS, and Secure Channel

One of the objectives of CORBA CSS, TSS, and secure channel architectures is to vide totally unobtrusive protection to applications Most CORBA objects should be

pro-able to run securely on a secure ORB without any active involvement within the cation code In the meantime, it is possible for an object to exercise stricter (application-specific) security policies than the ones enforced by CORBA security run time In thissection, we provide an overview of the CORBA CSS, TSS, and secure channel The CORBA CSS provides the following security functions:

appli-■■ Obtaining the principal’s credentials by authenticating the user or retrievingcredentials from the session environment if the principal has already beenauthenticated, and managing the principal’s credentials created as a result ofthe authentication

■■ If necessary, translating the principal’s credentials into those accepted by theTSS, before they are “pushed” to the server

■■ Creating a secure channel with the TSS While doing this, the CSS couldauthenticate the TSS if the client’s policy requires it to do so

■■ Protecting request messages and verifying response messages, depending onthe message protection policy

■■ Performing audit of the invocations

■■ Implementing client’s nonrepudiation policy

The CORBA TSS provides security functions that are very similar to those of CSS aswell as enforcing access control:

■■ Authenticating clients and verifying their credentials if they are “pushed,” orobtaining them if they are “pulled.”

■■ Obtaining credentials used to authenticate the target to clients, usually byretrieving credentials from the session environment or from trusted and securestorage for principals not associated with people

■■ Creating a secure channel with the CSS While doing this, it could authenticatethe CSS if the target’s policy requires it to do so

■■ Verifying request messages’ protection and securing response messages,depending on the target’s message protection policy

■■ Performing an access control check on the requested object and method, based

on the received credentials

■■ Performing an audit of the invocations

■■ Implementing a target’s nonrepudiation policy

The state of CORBA secure channel is maintained by CSS and TSS and managed viaservice context in GIOP messages As described in the earlier section on the runtimepart of CORBA, any GIOP Request/Reply message contains a list of service contextdata, which is used by different services for inserting service-specific information into

the stream of communications between client and server CORBASec defines a rityAttributeService (SAS) data type as an element of GIOP message service context,

Secu-which may be used to associate security-specific identity, authorization, and clientauthentication contexts with GIOP Request and Reply messages

Common Secure Interoperability Version 2

The objective of the CSIv2 specification is to define the interoperable wire protocol forCORBA and J2EE secure channels CSIv2 defines the format and rules to send the secu-rity information from a client to a server, running on either CORBA or J2EE, to supportthe secure interoperability between the client and server

CSIv2 defines the following three logical layers that are used to transfer the securitydata from a CSS to a TSS:

1 The authorization layer (or attribute layer)

2 The authentication layer

3 The transport layer

The first two layers are the subject of a new protocol defined by CSIv2, the SecurityAttribute Service The transport layer supports the security mechanism that youchoose, for example TLS/SSL or DCE/RPC All three layers work together to supportpassing the security data so that the target can satisfy all of its security requirements

The first part of the protocol, passing the authorization security information, usesthe service context in the request or reply header as defined by the GIOP protocol TheSAS protocol defines how authorization data will be passed from the client to the tar-get At the attribute layer, the principal privilege (roles and groups) and identity(access and audit identity) attributes are passed from CSS to TSS, using a cryptograph-ically signed Privilege Attribute Certificate (PAC) in a format defined by the IETFAttribute Certificate specification (IETF 2002b) The attribute layer is also responsiblefor supporting delegation

CSIv2 supports both forms of simple delegation In constrained delegation, the CSS

names the intermediates that it trusts in an extension field of the PAC called proxy attributes The TSS checks this field and makes sure that an intermediate has a right to

delegate the client’s credentials Unconstrained delegation is indicated through a cial value of this PAC field, “Any.”

spe-The second layer of CSIv2 supports authentication In some cases, the securitymechanism in the transport layer handles authentication For example, SSL will sup-port client authentication if the target requires that the client provide authenticationbased on a public key certificate This may not be desirable in all cases, because anenterprise may not want the expense of purchasing SSL certificates for all its clients,customers, and suppliers In cases where the underlying security transport does notsupport authentication, CSIv2 will do the job, since its authentication layer supportsany GSS-API request/reply mechanism, such as Kerberos, as well as simple usernameand password

The third layer defined by CSIv2 is the transport layer In this layer, CSIv2 authorschose Transport Layer Security, TLS/SSL, as the security mechanism, which all confor-mant security services should support A CSIv2 security service can work with othersecure transports such as DCE/RPC or CORBA’s Secure Inter-ORB Protocol (SECIOP),but it must support TLS/SSL so that the client and target have at least one securitymechanism in common