J2EE security introduction — turn

< H2 id = "1" > I brief introduction

Now more and more enterprise applications are built on J2EE platform, which benefits from the good framework and service support provided by J2EE for the development of enterprise applications J2EE provides various services (security, transaction, naming, etc.) for enterprise applications This article will introduce the security services provided by J2EE Firstly, the author introduces the security concept in J2EE and the security architecture of J2EE Then combined with specific examples to show readers how to apply the security features provided by J2EE in their own programs. The content introduced in this paper is based on j2ee1 Version 3.

Principal: a principal is an entity verified in the enterprise security service (principal) uses the principal name as its identification and verifies through the authentication data related to the principal. Usually, the principal name is the user's login name and the authentication data is the login password. J2EE specification does not limit what authentication method J2EE product providers use, so the content and format of the principal name and authentication data vary according to different authentication protocols. Security policy domain: also known as security domain (security domain) or realm, which is a logical scope or region in which security service administrators define and implement common security policies. It is a region divided from the perspective of security policies. For example, enterprise application systems can be divided into different security domains such as enterprise employees, suppliers and partners, and different security policies can be adopted for these security zones Security policy. Security technology domain: it is an area divided from the perspective of security technology. The same security mechanism is used to implement security policies in a security technology domain. A security technology domain can include multiple security policy domains. Security attributes: each principal (principal) has a series of security attributes related to it. Security attributes can be used to access protected resources, check the identity of users and complete other security related purposes. J2EE product providers or the implementation of specific authentication services determine how to associate security attributes with a principal. J2EE specification does not limit what security attributes will be associated with the principal Associated. Credential: the credential contains or refers to the authentication information that validates a principal for the J2EE system (security attribute). If the authentication is successfully passed, the principal will obtain a certificate including the security attribute. If allowed, one principal may also obtain the certificate of another principal. In this case, the two principals have the same security attribute in the same security domain.

In the J2EE environment, the security of components is the responsibility of their respective containers. Component developers can hardly or rarely add security code to components. This relatively independent architecture of security logic and business logic makes the enterprise application system more flexible and scalable. J2EE specification requires that J2EE products must provide two forms of container based security for application developers - illustrative security and programmable security. a. Illustrative security illustrative security represents the security requirements of an application by describing the security structure, which generally includes security roles, access control and authentication requirements. Deploying descriptors in J2EE platform is the main tool to illustrate the security of. Deployment descriptors are communication tools between component developers and application Deployers or application assemblers. Application developers use it to represent security requirements in applications. Application Deployers or application assemblers map security roles to users and groups in the deployment environment. When the program runs, the container extracts the corresponding security policy from the deployment descriptor, and then the container performs security verification according to the security policy. The security of the description does not require developers to write any security related code. Everything is completed by configuring the deployment descriptor. b. Programmable security on the basis of illustrative security, programmable security enables security sensitive applications to make security decisions by calling the API provided by the container. This is useful when illustrative security is not sufficient to meet the enterprise's security model. J2EE provides two methods in EJB ejbconext interface and servlet HttpServletRequest interface respectively: these methods allow components to make business judgments according to the security role of the caller or remote user. These methods and routines will be introduced in detail later in the article, so that readers can better understand the use of programmable security.

Authentication is the process by which users or component callers prove their identity to the system. The user submits authentication information (usually user name and password or user's digital certificate) to the system in some way. The system uses the authentication information provided by the user and the security policy of the system to verify the user's identity.

Figure I initial verification process

User authentication user authentication can be divided into two types according to different client types: Web client authentication and application client authentication A. web client authentication web clients usually request web server-side resources through HTTP protocol. These web resources usually include HTML web pages jsp (Java server page) files, Java servlets and other binary or multimedia files. In the enterprise environment, some resources of the enterprise are often only allowed to be accessed by some people, and some resources are even confidential or security sensitive. Therefore, it is very necessary to control the access of various web resources in the enterprise. In order to meet the different security levels and customization requirements of the enterprise Demand, J2EE provides three authentication methods based on Web client: http basic authentication. HTTP basic authentication is an authentication mechanism supported by HTTP protocol. This authentication mechanism uses the user's user name and password as authentication information. The web client obtains the user name and password from the user, and then passes them to the web server, which is in the specified area (REALM). However, it should be noted that this authentication method is not secure enough. This authentication method does not encrypt the user's password, but only encodes the password in basic Base64. Moreover, the target web server is also non authenticated to the user. It is not guaranteed that the web server accessed by the user is what the user wants to access. It can be adopted Use some security measures to overcome this weakness. For example, apply SSL on the transport layer or use IPSec or VPN Technology on the network layer. Form based validation (form based authentication) form based authentication enables system developers to customize the user's login page and error report page. The only difference between this authentication method and the basic HTTP authentication method is that it can formulate login and error pages according to the user's requirements. The form based authentication method also has an insecure weakness similar to the basic HTTP authentication Fill in the user name and password in the form, and then the password is transmitted in clear text in the network. If the authentication request is intercepted at a node of the network, it is easy to obtain the user's password after de coding. Therefore, when using the basic HTTP authentication method and the form based authentication method, make sure that the weaknesses of these two methods are acceptable to your application. Client certificate authentication the client certificate based authentication method is more secure than the above two methods. It ensures the security of authentication through HTTPS (HTTP over SSL). Secure socket layer (secure sockets layer) provides security guarantees for data encryption, server-side authentication, information authenticity, etc. in this verification method, the client must provide a public key certificate, which can be regarded as your digital passport. Public key certificate is also called digital certificate, which is called certificate authority (CA) - issued by a trusted organization. This digital certificate must meet the x509 public key architecture (PKI) standard. If you specify this authentication method, the web server will use the digital certificate provided by the client to verify the user's identity. B. authentication of the application client (application client user authentication) the Java client program is a java program executed on the user's local Java virtual machine. It has the main method, which can usually be directly started and executed by the user through java.exe or javaw.exe. The J2EE application client program is similar to the Java client program and also has the main method, but there are some differences in their runtime. J2EE application client The client runs in its own container like other J2EE components. The user executes the J2EE application client through the container. In this way, the J2EE application client container has the opportunity to complete user authentication before the J2EE application client is executed. J2EE provides a customizable way to obtain user authentication information. You can choose to use the default method provided by the container to obtain the authentication information of the user of the J2EE application client, or you can choose a custom method to obtain the authentication information of the user. When choosing the custom mode, the application developer must provide an implementation of javax security. auth. callback. Callbackhandler interfce class, and deploy the description file application client in J2EE Add the class name of this class to the element callback handler in XML. In this way, when the system needs to verify the user's identity, The container of the client program passes the class name of the callbackhandler implementation class in the deployment description file to the login module of the system (authentication module), and the login module instantiates this implementation class. The instance of this class is responsible for collecting user authentication information and passing the collected user authentication information to the login module. The login module uses this authentication information to authenticate users. This implementation class can have a user interface, or collect user authentication information by requiring user input, or through Obtain the user authentication information through the command line, or obtain the user's electronic certificate by reading the local or online user certificate library. Which method to choose depends on how the authentication information is stored. Some J2EE product manufacturers integrate the container authentication service with the local system authentication service or the authentication service of other application system products, so as to realize the ability of single sign on within a certain application system. Single sign on (single sign on) from the user's perspective, single sign on means that users only need to log in once in a specific logical security area to access the authorized resources in different application systems in this logical security area. They are required to log in again only when they exceed the edge of the security area. This capability is particularly valuable for enterprises where multiple IT application systems coexist. With the development of enterprises With the continuous improvement of information construction in the industry, there are more and more application systems in enterprises. In traditional application systems, each system maintains its own security policies. These security policies typically include organizational structure definition, security role definition, user authentication, resource access control and so on. Because each system is independent of each other, a user must log in according to the corresponding system identity before using each application system. For users, they must remember the user name and password of each system, which brings great trouble to users. In view of this situation, the concept of single sign on arises and is constantly applied to the integration of enterprise application systems. J2ee1. It is also suggested in the specification that J2EE products should provide single sign on capability for application systems. But j2ee1 3 specification does not specify what standards J2EE products should follow, so the implementation and application of products from different manufacturers on single sign on are different. Some J2EE products realize single sign on within the product environment, Some implement single sign on between specific system environments (for example, IBM WebSphere Application 4.0 AE implements single sign on between websphere application server and websphere application server, websphere application server and Lotus Domino server, and websphere application server and Lotus Domino server). In J2EE, single sign on is through the transfer of credentials When the user logs in to the system, the client container (including web client and application client) establishes a security context for the user according to the user's credential (security context). The security context contains the security information used to verify the user. The system uses this security context and security policy to determine whether the user has the permission to access system resources. Unfortunately, the J2EE specification does not specify the format of security context, so it is not possible to transfer security context between J2EE products of different manufacturers. So far, there are few applications that do not Sharing security context among the same J2EE products, Therefore, the implementation of single sign on between different J2EE products can only be verified through the integration of third-party products (such as LDAP server) (lazy authentication) authentication comes at a cost. For example, an authentication process may include multiple exchanges of information over the network. Therefore, lazy authentication is very useful. Lazy authentication enables users to perform the authentication process only when they access protected resources, rather than when they first initiate a request.

Code authorization J2EE products restrict the execution of specific J2SE classes and methods through the Java 2 security model to protect and ensure the security of the operating system. For detailed description, please refer to the J2SE specification document. Caller authorization security role: a security role is a logical group with the same security attributes. It is composed of the assembler of the application (application assembler) or application deployer. Security role reference: the security role reference is the identity used by the application provider to reference the security role. Application provider (application provider) can use security role references to assign resource access permissions to security roles. Security roles are also referenced in security related program codes. Users and groups: users and groups are a collection of users and users in the actual system environment. They correspond to real people and groups. Access control: access control can ensure that security roles can only access Ask the authorized object that has been granted security permission. Authorization objects include remote methods of EJBs Web resources (HTML web pages, JSP / servlets and multimedia or binary files), etc. in J2EE, access control is associated with security roles in the application description file. Mapping: the system administrator of the mapping application connects users and roles in the actual system environment with security roles, so that the actual users have appropriate authorization to access enterprise resources. It is transmitted In J2EE 1.3, propagated caller identities can be selected as the identity of web component and EJB component callers for authentication. In this way, the method getcallerprincipal of interface ejbcontext in the whole EJB component call chain returns the same principal name (principal name). If the first EJB in the call chain is called by JSP / servlet, the principal name returned by the method getcallerprincipal of interface ejbcontext should be the same as the return value of the method getuserprincipal of interface HttpServletRequest. It should be noted that the user ID is passed in the call chain, not the credential (credentials), which is very important because users may use different security attributes on each node of the call chain. Run as identificationsjee 1.3 provides a method that allows component developers and deployment to specify the identity of the component. Products conforming to j2ee1.3 specification will provide a method to set the component to run as identities. If run as identity When the instances mode is selected, the caller of the component set to run as identities in the run is no longer the caller of the first node in the call chain, but the caller specified during deployment. The caller of the subsequent node in the call chain becomes the same as the caller of the component set to run as identities.

This part introduces the security concepts of J2EE, which is intended to enable readers to have a certain understanding of J2EE in security. Later, there will be specific examples of applying these concepts. J2EE provides us with security services for authentication and authorization. When developing applications based on J2EE, we should use these services provided by J2EE as much as possible. Because only by following J2EE standards can your application have good portability, scalability and maintainability. Only when the selected J2EE products can not meet the specific security requirements, we should consider using third-party security products or developing our own security services. Source: http://www.ibm.com/developerworks/cn/java/l-j2eeSecurity/ To sum up, the above is the J2EE security introduction collected and sorted out by the programming home for you -- turn all the contents. I hope the article can help you solve the program development problems encountered by the J2EE security introduction turn. If you think the content of the programming home website is good, you are welcome to recommend the programming home website to programmers and friends. This graphic content is collected and provided by netizens on the Internet as a learning reference. The copyright belongs to the original author. Like to share programming technology and work experience with others. Welcome to join the official exchange group of programming house! Programming House official 1 group programming House official 2 group programming House official 3 group programming House official 4 group 1: Java theory and practice: more flexible in JDK 5.0 next: JAAS authentication in Tomcat ex