| |
The security model advocated by the EJB 1.1 spec is a declarative model that avoids the introduction of security code into the EJB business methods. From Enterprise JavaBeans Specification, v1.1, Section 15.1:“The EJB architecture encourages the Bean Provider to implement the enterprise bean class without hard-coding the security policies and mechanisms into the business methods. In most cases, the enterprise bean's business method should not contain any security-related logic. This allows the Deployer to configure the security policies for the application in a way that is most appropriate for the operational environment of the enterprise.”
The EJB1.1 declarative security model is specified using the ejb-jar security-role and method-permission elements. Figure 7.1 illustrates the security related elements of the ejb-jar.xml deployment descriptor.
The application assembler defines the required 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 remote interfaces. A security role is a semantic grouping of method permissions. A user must have at least one security role associated with a method in or to have permission invoke the method. Because the application assembler does not, in general, know the security environment of the operational environment, the security roles are meant to be logical roles, each representing a type of user that should have the same access rights to the grouping of methods.
From Enterprise JavaBeans Specification, v1.1, Section 15.3: “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.”
A security role is defined using the following ejb-jar elements:
The following EJB 1.1 spec example illustrates a security role definition in a deployment descriptor.
Example 7.1. Sample security-role usage
... <assembly-descriptor> <security-role> <description> This role includes the employees of the enterprise who are allowed to access the employee self-service application. This role is allowed only to access his/her own information. </description> <role-name>employee</role-name> </security-role> <security-role> <description> This role includes the employees of the human resources department. The role is allowed to view and update all employee records. </description> <role-name>hr-department</role-name> </security-role> <security-role> <description> This role includes the employees of the payroll department. The role is allowed to view and update the payroll entry for any employee. </description> <role-name>payroll-department</role-name> </security-role> ... </assembly-descriptor>
From Enterprise JavaBeans Specification, v1.1, Section 15.3.2, If the application assembler has defined security roles for the enterprise beans in the ejb-jar file, they can also specify the methods of the remote and home interface that each security role is allowed to invoke. The assembler defines the method permissions relation in the deployment descriptor using the method-permission elements as follows.
Each method-permission element includes a list of one or more security roles and a list of one or more methods. All the listed security roles are allowed to invoke all the listed methods.
Each security role in the list is identified by the role-name element, and each method (or a set of methods, as described below) is identified by the method element. An optional description can be associated with a method-permission element using the description element.
The method permissions relation is defined as the union of all the method permissions defined in the individual method-permission elements.
A security role or a method may appear in multiple method-permission elements. It is possible that some methods are not assigned to any security roles. This means that none of the security roles defined by the Application Assembler needs access to the methods.
The method element uses the ejb-name, method-name, and method-params elements to denote one or more methods of an enterprise bean's home and remote interfaces. There are three legal styles for composing the method element:
The following EJB 1.1 spec example illustrates how security roles are assigned method permissions in the deploymentvdescriptor:
Example 7.2. Sample method-permission Element Usage
... <method-permission> <role-name>employee</role-name> <method> <ejb-name>EmployeeService</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <role-name>employee</role-name> <method> <ejb-name>AardvarkPayroll</ejb-name> <method-name>findByPrimaryKey</method-name> </method> <method> <ejb-name>AardvarkPayroll</ejb-name> <method-name>getEmployeeInfo</method-name> </method> <method> <ejb-name>AardvarkPayroll</ejb-name> <method-name>updateEmployeeInfo</method-name> </method> </method-permission> <method-permission> <role-name>admin</role-name> <method> <ejb-name>EmployeeServiceAdmin</ejb-name> <method-name>*</method-name> </method> </method-permission> ...
The check of declarative method permissions is handled by the JBoss container SecurityInterceptor. When a method is invoked, the SecurityInterceptor obtains the set of roles declared in method-permission elements for the method and invokes RealmMapping.doesUserHaveRole(principal, methodRoles) to see if the prinicipal invoking the method has one of the roles in the methodRoles set. When the JaasSecurityManager is used as the RealmMapping implementation, the association of what roles a principal has occurs during authentication. One or more of the LoginModules associated with the security domain assigns the roles the principal belongs to the JAAS Subject instance that is created by the login process. The roles found in the Subject are then used by the JaasSecurityManager in its RealmMapping implementation.
While a good concept, in general the declarative security model is often too simplistic to cover business application security requirements. Reasons for this include:
The EJB 1.1 spec defines a mechanism by which custom security can be implemented by the bean provider. This requires introduction of security logic into the EJB's business method implementation. For this reason, Enterprise JavaBeans Specification, v1.1, Section 15.2.5 states: “Note: In general, security management should be enforced by the Container in a manner that is transparent to the enterprise beans business methods. The security API described in this section should be used only in the less frequent situations in which the enterprise bean business methods need to access the security context information.”
The EJB 1.1 custom security api consists of the following two javax.ejb.EJBContext interface methods:
Using these methods along with custom code you can add any type of security validation to your EJB. When using the isCallerInRole there must be a security-role-ref element in the ejb-jar deployment descriptor for 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. A role-link element must be used even if the value of role-name is the same as the value of the role-link reference. The following EJB 1.1 spec deployment descriptor example shows how to link the security role reference named payroll to the security role named payroll-department.
Example 7.3. Sample security-role-ref Element Usage
... <enterprise-beans> ... <entity> <ejb-name>AardvarkPayroll</ejb-name> <ejb-class>com.aardvark.payroll.PayrollBean</ejb-class> ... <security-role-ref> <description> This role should be assigned to the employees of the payroll department. Members of this role have access to anyone’s payroll record. The role has been linked to the payroll-department role. </description> <role-name>payroll</role-name> <role-link>payroll-department</role-link> </security-role-ref> ... </entity> ... </enterprise-beans> ...
A problem with this approach is that security tends to move independent of the application business logic, and it is a function of the deployment environment. The JBossSX framework provides a solution to custom security problem in a manner that is transparent to the enterprise beans business methods. This allows security logic to change independent of the business logic and the security layer can be selected at deployment time to fit operational environment.
The custom security solution that the JBossSX framework offers is an extension of the method interceptor paradigm. We will see the details of this in the section called “The JBoss Security Model”. The concept of the security proxy is an implementation of the “protection proxy” form of the Proxy pattern described in the Design Patterns book. The security proxy model allows for development of an implementation of the business object remote or home interface whose sole responsibility is the implementation of the per-method security logic. This implementation object is the security proxy. The container method interceptors first dispatch home and remote method invocations to the security proxy for custom security logic validation. If the security requirements are satisfied, the method invocation is dispatched to the business logic EJB. If the security requirements are not satisfied, a security exception is raised and the method invocation is halted.
 | |
| Наши друзья |
