306

J2EE Platform Security Model

rity constraints with associated roles also protect Web resource collections, that is,

a URL pattern and an associated HTTP method, such as 

GET or POST

. 

Although deployment descriptors define authorization constraints for an

application, security mechanisms often require more refinement plus careful

mapping to mechanisms in the operational environment in which the application

is ultimately deployed. Both the EJB and Web tiers define access control policy at

deployment, rather than during application development. The access control

policy can be stated in the deployment descriptors, and the policy is often adjusted

at deployment to suit the operational environment. 

It is also possible during deployment to refine the privileges required to

access components. At the same time, you can define the correspondence between

the security attributes presented by callers and the container privileges. The

mapping from security attributes to container privileges is kept to the scope of the

application. Thus, the mapping applied to the components of one application may

be different from that of another application.

A client interacts with resources hosted in a Web or EJB container. These

resources may be protected or unprotected. Protected resources have authorization

rules defined in deployment descriptors that restrict access to some subset of non 

anonymous identities. To access protected resources, clients must present non 

anonymous credentials to enable their identities to be evaluated against the

resource authorization policy.

You control access to Web resources by properly defining their access ele 

ments in the deployment descriptor. For accessing enterprise beans, you define

method permissions on individual bean methods. See  Handling Authorization 

on page 320.

7.2.2.2

Programmatic Authorization

A J2EE container decides access control before dispatching method calls to a com 

ponent. In addition to these container pre dispatch access control decisions, a devel 

oper might need to include some additional application logic for access control

decisions. This logic may be based on the state of the component, the parameters of

the invocation, or some other information. A component can use two methods,

EJBContext.isCallerInRole

 (for use by enterprise bean code) and

HttpServletRequest.isUserInRole

 (for use by Web components), to perform

additional access control within the component code. 

To use these functions, a component must specify in the deployment descrip 

tor the complete set of distinct 

roleName

 values used in all calls. These declara