Mastering Web Services Security phần 5 pdf

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

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 sages between client and server

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

Client Intermediate

Object

TargetObject

• Simple delegation: impersonation or controlled

client credentials client credentials

Client Intermediate

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

In summary, CSIv2 has three layers that support secure channel in CORBA and EJBsystems, and the layers match the basic trio of security—authorization, authentication,and message protection Once the security context is safely established between theCSS and the TSS using CSIv2, it is used on the server to protect target objects.

In the next sections, we will explain how CSS and TSS responsibilities are fulfilledvia security mechanisms implemented by the CORBA security service

Implementation of Security Functions

Similar to other middleware security technologies, security policies in CORBA areenforced completely outside of an application system Everything, including obtaininginformation necessary for making policy decisions, is done before the method invoca-tion is dispatched to the target object As Figure 7.8 shows, the security enforcementcode is executed inside of a CORBA security service when a message from a clientapplication to a target object is passed through the ORB

Authentication

A principal may be authenticated in a number of ways—the most common of whichfor human users is a password For system entities, on the other hand, authenticationdata, such as a long-term key, must be associated with the corresponding object InCORBA, a principal has at least one and possibly several different identities When aprincipal is being authenticated, it normally supplies:

■■ Its security name

■■ The authentication data needed by the particular authentication method used

■■ Requested privilege attributes (although the principal may change them later)

Figure 7.8 Enforcement of policies in CORBA security

ClientApplication

TargetObject

DomainPolicy

PolicyEnforcementCode

DomainExecution Context

Credential

IdentitiesPrivileges

Security Enforcement Subsystem

ORBMessage

The principal may have privilege attributes that the TSS can use to decide what theprincipal can access A variety of privilege attributes may be available, depending onaccess policies The privilege attributes that a principal is permitted to take are known

to the system At any given time, the principal may be using only a subset of these mitted attributes, chosen either by the principal (or an application running on itsbehalf) or by using a default set specified for the principal There may be limits on theduration for which these privilege attributes are valid and controls on where and whenthey can be used Because CORBASec defines an extensible privilege attribute model,

per-it enables access control policies based on roles, groups, clearance, and any other rity-related attributes of the principal These attributes, once established through prin-cipal authentication, are carried from CSS to TSS in the CSIv2 attribute layer

secu-Message Integrity and Confidentiality Protection

Although the CORBASec architecture does not have any explicit provisions for sage origin authenticity protection, it is performed implicitly if the other entity isauthenticated and messages are encrypted with the session key, or if the message camethrough one of CSIv2’s secure transport layers from an authenticated party As for mes-sage confidentiality and integrity protection, they are both supported by CORBA secu-rity and referred to as quality of protection (QoP) Similar to other technologiesdescribed in this chapter, CORBA’s QoP is set by policy, and has four possible values:

mes-no protection, integrity protection only, confidentiality protection only, and bothintegrity and confidentiality protection

Access Control

CORBA security has an extensible model for subject security attributes to enable rity run-time and administration scaling with possibly large numbers of subjects.Another application of grouping in CORBA security is policy domains that allow scal-ing on the number of objects Domains are used for most security policies in CORBA

secu-A third grouping mechanism, which is also specific to access control, introducesrequired and effective rights and allows scaling on the number of operations The role

of all three grouping mechanisms in CORBA is illustrated in Figure 7.9

Being the finest level of access control granularity in CORBA, operations could liferate in your system and cause scaling problems You might not realize that the num-ber of methods accessible on distributed objects in your enterprise is quite large In thecomplete version of our eBusiness example, we have over 20 different operations, soyou can easily imagine that in real enterprises there are hundreds of distinguishedoperations on distributed objects Any security administrator can tell you that it’s com-mon to grant the same access to more than one resource in the enterprise As a result,

pro-an administrator’s job cpro-an be significpro-antly eased if the operations that are alike in rity requirements can somehow be grouped and administered at a group level instead

secu-of using individual operations In addition, the use secu-of such groups prevents securityadministrators from having to understand the semantics of methods This is exactlywhat CORBA’s required rights do

Figure 7.9 Users, operations, and target objects are grouped via attributes, rights, and

using the ExtensibleFamily attribute Examples of required rights can be found in Table

7.1, which shows some of the settings for our eBusiness example

Depending on the domain access policy (DAP) enforced in a particular access policy domain, a subject is granted different rights (GrantedRights) according to what privi-

lege attributes it has We show the granted rights for our eBusiness example in Table7.2 For instance, Johnson is only granted right “g” (get) in the Products domain, so hecan’t invoke Product::setPrice because the operation requires “s” (set) and “m” (man-age) However, if Johnson invokes Account::deleteOrder on an object belonging to theAccounts domain where he is granted both “s” and “u” (use) rights, then the invoca-tion will succeed, since that operation requires only “s.”

Table 7.1 Examples of Required Rights for eBusiness

Attributes

Users

Required Rights Domains

TargetsClients Operations