Chapter 7 Security

319

the target Web service establishes the identity of calls to its service endpoint. The

Web service bases this identity on the mapping principals designated by when the

service was deployed, which may be based on either the client's username and

password identity or the digital certificate attributes supplied by the client's con 

tainer. However, since no standard mechanism exists for a target Web service to

map an authenticated client to the identity of a component, each application server

handles this mapping differently.

For example, Figure 7.4 illustrates how a caller identifier is propagated from

clients to Web service endpoints and J2EE components. The initial client makes a

request of Web service endpoint 

X

. To fulfill the request, endpoint 

X

 makes a call

on entity bean 

J

, which in turn invokes a method on entity bean 

K

. The client caller

identifier 

A

 propagates from the endpoint through both entity beans. However,

when entity bean 

K

 calls a method on service endpoint 

Y

, since the Web service is

not in the same protection domain, reauthentication must occur. Similarly, when

endpoint 

X

 calls endpoint 

Z

, the caller identifier cannot be propagated. 

Applications can also use programmatic APIs to check client identity, and use

that client identity to make identity decisions. For example, a Web tier endpoint,

as well as other Web components, can use the 

getUserPrincipal

 method on the

HttpServletRequest

 interface. An EJB endpoint, just like other enterprise bean

components, can use the 

EJBContext

 method 

getCallerPrincipal

. An applica 

tion can use these methods to obtain information about the caller and then pass

that information to business logic or use it to perform custom security checks.

Client:

request

caller id A

Service

endpoint

Entity

response

X

id A

bean J

Entity

id A

bean K

reauthenticate

reauthenticate

Service

Service

endpoint

endpoint

Z

Y

Figure 7.4

Security Propagation