EJB的安全性中英文资料外文翻译文献.docx

1、EJB的安全性中英文资料外文翻译文献 (文档含英文原文和中文翻译)EJB的安全性中英文资料外文翻译文献EJB securityINTRODUCTIONSecurity management is one of the important services that EJB offers. The low_level security infrastructure in EJB is implemented by the container provider. Security policies are set at deployment time in order to make the be

2、ans portable across applications. EJB security boils down to which user has permission to call which method of a bean. Users are defined outside EJB in a specific operational environment(for example, a user named Gurmail Kandola, working on a UNIX machine with username kandola, is a member of user g

3、roup engineering, has access permission to a MySQL database server and so on). To the EJB code, a user is represented by an instance of the of the class java.security.principal. Principals are mapped to security roles, which determine the methods a principal can access. The application assembler def

4、ines the logical security roles,and the deployer maps them them to the principals. A method call from a client may trigger a bean-to-bean chain of calls, as you saw in the previous chapter while exploring transactions. How does security propagate along this chain of calls? How do the varous EjB role

5、s split the responsibility for setting security policies? These questions point to some of the important issues that we will explore in this chapter. Your goal for this chapter is to understand EJB security and how the security assignments and responsibilities flow from method to method and role to

6、role.To accomplish that, we will explore three avenues: declarative and programmatic security in EJB, the flow of responsibilities from role to role in determining security policy, and the flow of security identity within a sequence of method calls.IMPLEMENTING SECURITY IN EJBThe security infrastruc

7、ture in EJB is implemented by the container provider, while the security policies are determined by other EJB roles at deployment and runtime. In this section, we discuss the security requirements presented by the EJB architecture and how they are met. First, we introduce the basic security concepts

8、 that you need to grasp in order to comprehend the rest of the material in this chapter.Understanding basic security conceptsTo understand the different features of EJB security and how the carious pieces fit together, you need to know what the basic security terms mean. First, we briefly introduce

9、those terms.Authentication and authorizationAuthentication authorization resent two levels of security on a system, such as a computer system or an application running on a computer. Authentication involves showing your id in order to get into the system,for example, your login and password. Authori

10、zation determines what you can and cannot do once you are in the system. For example, first you log on to a file server using authentication. By typing in your login and password.Once you are logged in, you find a set of files that you can only read, another set of files that you can read and change

11、, and yet another set that you cannot even read. This is the authorization part of security. In EJB, authorization means that a client is authorized to call a bean method.Principals and rolesA Principal is an entity that can be authenticated by a system. It can be, for instance, an end user or an ap

12、plication trying to access another application. In Java, once an entity is authenticated to a system it is represented by an instance of java.security.Principal. In EJB, a Principal can be associated with once or more secruity roles defined by the application assembler. A secruity role has a set of

13、permissions assigned to it. A Principal can be mapped to these roles, and then the Principal will have the permission attached to the role. In other words, a security role is a set of application permissions that can be assigned to a user(or a group of users).Users and groupsA user is a real person

14、with an account on a system. A group is a collection of users. Either a user or a group can be mapped to a logical security role. In the operational environment, it is the users and groups who use the application, but they live outside of EJB. So, in order to get into the EJB application, they chang

15、e into Principals and security roles.A user of an EJB application lives in a specific operational environment and enters the Java world as a Principal, and the Principal accesses the application by acquiring one or more roles defined within the EJB architecture. NOTE The EJB architecture for distrib

16、uted and portable enterprise applications has some implications as to how EJB security should look. Lets explore this issue next.Secutity in EJBImplementation of security in any system generally involves two stages;implementing the security infrastructure and allowing an administrator to set and imp

17、lement security policies on a given system. Keeping this in mind, not that the distributed nature and the portability characteristic of the EJB architecture set the following goals for EJB security:Separate the security infrastructure from the business logic of an application, because the bean provi

18、der, who is an expert in implementing business logic, may not be a security expert, and some other roles are.Remember that EJB applications should be portable across multiple EJB servers, and those servers may possibly be using different security mechanisms.Allow security policies to be set at deplo

19、yment rather than at coding time in order to support portability.The EJB role responsibilities the security infrastructure. The application assembler, the deployer, and the system administrator participate in setting security policies. The EJB spec recommends that the bean provider should neither im

20、plement security mechanisms nor hard-code the security policies in the beans business methods. Security in EJB is about authorization, for example, who can have access to a certain bean method. The clients of an application exercise certain security roles, and the permission to call methods is assig

21、ned to the roles.DEFINING THE SECURITY ROLESIt is the deployers responsibility to deploy the application securely. To do this correctly the deployer needs to know what each business method does in order to determine which user can call it. However, the deployer is not expected to go into the source

22、code. So we have a problem. Here is the solution: the application assembler helps the deployer by providing the security view of an application in the deployment descriptor. The security view contains a set of logical security roles and a set of method permissions for each security role. The deploym

23、ent descriptor contains two parts hat are related to security: , which is written by the bean provider, and , which is written by the application assembler. The application assembler defines the security roles in the part of the deployment descriptor. The application assembler is responsible for the

24、 following:Defining each security role using a element in the section of the deployment descriptor.Defining the element as a subelement of to give the security role a name. This step is mandatory.Defining the element as a subelement of to provide a description for the security role. This step is opt

25、ional.A security role applies to all the enterprise beans in the same ejb-jar file. Listing 14.1 shows two secrity roles defined within the element.Two security roles named employee and hr-director defined within the element. The element is the only mandatory element for a . Listing 14.1 In a given

26、, the element is the only mandatory element. The element is used by the deployer to assign the security role to a user or a group in the actual operational environment. The element is optional and is there to help the deployer understand what this role is before assigning it to an appropriate user o

27、r group.The role name in the element is only logical and does not represent a user or a group in a real operational environment. However, the deployer can map it to a Principal that represents a user in the real operational environment. NOTE Security in EJB is about authorization, namely, permission

28、s to call the bean methods. This is implemented in two steps: granting method permissions to security roles and mapping security roles to Principals, which represent users. Lets examine how method permissions are defined and granted.DEFINING MEHOD PERMISSIONSAfter defining the security roles, the ap

29、plication assembler can assign method permissions to the roles, that is, the methods of a bean that a user in that role can call. The assembler can assign any of the methods exposed in the component and home interfaces of a bean to a role. We discuss four different techniques for assigning method pe

30、rmissions to a role.Granting permission to all methodsBy using the wildcard *, the application assembler can grant a role permission to all the methods in the home and component interfaces of a bean. An example is shown here:This code means that the role hr director has been granted permission to ca

31、ll all methods in the home and component interfaces of the beans EmployeeRecordBean and EmployeeProgressBean. In other other words, a bean client in the role of hr-director can all any method from the client views of the beans EmployeeRecordBean and EmployeeProgressBean. This is a sweeping authorization for a role but not an ultimate one. The ultimate authorization would be that any client could call any method of a bean without being checked for authorization, and that is accomplished with the element. The following code fragment mea