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 






footer




 

 

 

 

 Home | About Us | Network | Services | Support | FAQ | Control Panel | Order Online | Sitemap | Contact

 

Our web partners: Inexpensive Web Hosting Java Web Hosting personal webspace webspace php  linux webhost

 html web templates DreamweaverQuality Web Templates PSD Web Templates

cheap webhost j2ee web Hosting buy webspace ftp webspace adult webspace

frontpage WebHosting webspace hosting cheap webhost

Visionwebhosting.net Business web hosting division of Vision Web Hosting Inc.. All rights reserved

aol web hosting