| From a list of responsibilities, identify which belong to the application assembler, bean provider, deployer, container provider, or system administrator. | ||
|---|---|---|
| Prev | Chapter 14. Security Management | Next |
In the life cycle of an application, different people perform different roles. From a security point of view, we can say that:
The bean provider can use programmatic security:
if ( isUserInRole("manager") ) { showAllCustomers(); } else { showCurrentCustomer(); }The application assembler will use declarative security to set permissions on methods of beans.
The application deployer links users and groups to roles.
The system administrator tells the application server where to find the users (for example in an LDAP directory).
Bean Provider's responsibilities
The Bean Provider should neither implement security mechanisms nor hard-code security policies in the enterprise beans' business methods. Rather, the Bean Provider should rely on the security mechanisms provided by the EJB Container, and should let the Application Assembler and Deployer define the appropriate security policies for the application.
The Bean Provider and Application Assembler may use the deployment descriptor to convey security-related information to the Deployer. The information helps the Deployer to set up the appropriate security policy for the enterprise bean application.
The Bean Provider is responsible for DECLARING in the security-role-ref elements of the deployment descriptor all the security ROLE NAMES used in the enterprise bean CODE. Declaring the security roles references in the code allows the Application Assembler or Deployer to LINK the names of the security roles used in the code to the security roles defined for an assembled application through the security-role elements.
Application Assembler's responsibilities
The Application Assembler may define a SECURITY VIEW of the enterprise beans contained in the ejb-jar file. Providing the security view in the deployment descriptor is optional for the Bean Provider and Application Assembler.
The security view consists of a set of SECURITY ROLES. A security role is a semantic grouping of permissions that a given type of users of an application must have in order to successfully use the application.
The Application Assembler defines METHOD PERMISSIONS for each security role. A method permission is a permission to invoke a specified group of methods of the enterprise beans' home and component interfaces.
It is important to keep in mind that the security roles are used to define the LOGICAL security view of an application. They should not be confused with the user groups, users, principals, and other concepts that exist in the target enterprise's operational environment.
If the Bean Provider has declared any security role references using the security-role-ref elements, the Application Assembler must LINK all the security role references listed in the security-role-ref elements to the security roles defined in the security-role elements.
If the Application Assembler has defined security roles for the enterprise beans in the ejb-jar file, he or she can also specify (using the method-permission elements) the methods of the home and component interfaces that each security role is allowed to invoke.
The Application Assembler can indicate that some methods should not be checked for authorization prior to invocation by the Container. The Application Assembler uses the unchecked element instead of a role name in the method-permission element to indicate that a method should not be checked for authorization.
The Application Assembler can use the exclude-list element to indicate the set of methods that should not be called. The Deployer should configure the enterprise bean's security such that NO ACCESS is permitted to any method contained in the exclude-list.
The Application Assembler uses the security-identity deployment descriptor element to specify whether the caller's security identity should be used for the execution of the methods of an enterprise bean or whether a specific run-as identity should be used. The value of the security-identity element is either use-caller-identity or run-as. The use-caller-identity element cannot be specified for message-driven beans (there is NO caller).
Because the Application Assembler does not, in general, know the security environment of the operational environment, the run-as identity is designated by a LOGICAL role-name, which corresponds to one of the security roles defined by the Application Assembler in the deployment descriptor.
Deployer's responsibilities
The Deployer uses deployment tools provided by the EJB Container Provider to read the security view of the application supplied by the Application Assembler in the deployment descriptor. The Deployer's job is to MAP the security view that was specified by the Application Assembler to the mechanisms and policies used by the SECURITY DOMAIN in the target operational environment. The output of the Deployer's work includes an application security policy descriptor that is specific to the operational environment. The format of this descriptor and the information stored in the descriptor are specific to the EJB Container.
The Deployer assigns principals and/or groups of principals (such as individual users or user groups) used for managing security in the operational environment to the security roles defined in the security-role elements of the deployment descriptor.
Typically, the Deployer does not need to change the method permissions assigned to each security role in the deployment descriptor.
It is possible that some methods are not assigned to any security roles nor contained in the exclude-list element. In this case, it is the responsibility of the Deployer to assign method permissions for all of the unspecified methods, either by assigning them to security roles, or by marking them as unchecked.
EJB Container Provider's responsibilities
The EJB Container Provider is responsible for providing the deployment tools that the Deployer can use to perform his tasks.
The EJB Container PROVIDES a SECURITY DOMAIN and one or more principal realms to the enterprise beans. The EJB architecture does not specify how an EJB Server should implement a security domain, and does not define the scope of a security domain.
A security domain can be implemented, managed, and administered by the EJB Server. For example, the EJB Server may store X509 certificates or it might use an external security provider such as Kerberos.
The EJB Container must be capable of allowing the Deployer to specify that, for all calls from a single application within a single J2EE product, the caller principal is PROPAGATED on calls from one enterprise bean to another (i.e., the multiple beans in the call chain will see the same return value from getCallerPrincipal()).
The EJB Container must be capable of allowing the Deployer to specify that a run-as principal be used for the execution of the home and component methods of a session or entity bean or for the onMessage method of a message-driven bean.
If the Container denies a client access to a business method, the Container must throw the java.rmi.RemoteException to the REMOTE client, or the javax.ejb.EJBException to the LOCAL client. 0
System Administrator's responsibilities
The System Administrator is responsible for the administration of principals. Security domain administration is beyond the scope of the EJB specification.
Typically, the System Administrator is responsible for creating a new user account, adding a user to a user group, removing a user from a user group, and removing or freezing a user account. 1
Visit http://java.boot.by for the updates.
