J2EE Security introduction-go

I. Introduction

Nowadays, more and more enterprise applications are built on the J2EE platform, thanks to the good framework and service support provided by J2EE for enterprise application development. j2EE provides enterprise applications with various services (such as security, transaction, and naming ). this document describes the security services provided by J2EE. the author first introduces the Security Concept in J2EE and the security architecture of J2EE. then, we will show you how to apply the security features provided by J2EE in your own program based on specific instances. The content described in this article is based on j2ee1.3.

Ii. Security Concepts in J2EE

Principal ):A principal is an entity verified by the Enterprise Security Service. The principal uses the subject name as its identifier and verifies it through the verification data related to the subject. Generally, the subject name is the user's login name, and the verification data is the login password. The J2EE specification does not specify the authentication method used by the J2EE product provider. Therefore, the content and format of the Subject name and verification data vary according to different authentication protocols.

Security policy domain ):Also known as security domain or realm, it is a logical range or region in which security service administrators define and implement common security policies. It is a region from the security policy perspective. For example, you can divide an enterprise application system into different security domains, such as employees, suppliers, and partners, and adopt different security policies for these security regions.

Security technology domain ):It is a region based on security technology. It uses the same security mechanism to implement security policies in a security technology domain. A security technology domain can contain multiple security policy domains.

Security attributes (security attributes ):Each principal has a series of related security attributes. Security attributes can be used to access protected resources, check user identities and complete other security-related purposes. The implementation of J2EE product providers or specific verification services determines how to associate security attributes with a subject. The J2EE specification does not specify what security attributes will be associated with the subject.

Credential ):The Credential contains or references the authentication information (Security Attribute) of a subject verified by the J2EE system ). If the verification succeeds, the subject will obtain a credential that includes security attributes. If allowed, one subject may also obtain the creden。 of the other. In this case, two subjects have the same security attributes in the same security domain.

Iii. J2EE Security Architecture 1. Container-based security

In a J2EE environment, component security is the responsibility of their respective containers. component developers can hardly or seldom add security-related code to components. This relatively independent architecture of security logic and business logic makes enterprise-level application systems more flexible and scalable. J2EE specifications require that J2EE products provide two forms of container-based security for application developers-descriptive security and programmable security.

A. descriptive Security

Descriptive Security describes the security structure to represent the security requirements of applications. security structures generally include security roles, access control, and verification requirements. Deploy descriptors on the J2EE platform as the main tool to demonstrate security. The deployment descriptor is a communication tool between component developers and application deployers or application assemblers. Application developers use it to express the security requirements of applications. Application deployers or application assemblers map security roles to users and groups in the deployment environment.

When the program is running, the container extracts the corresponding security policy from the deployment descriptor, and then the container performs security verification according to the security policy. To ensure security, developers do not need to write any security-related code. All is done by configuring the deployment descriptor.

B. programmable security

Programmable security is based on descriptive security, so that security-sensitive applications can make security decisions by calling the APIS provided by the container. This is useful when descriptive security is insufficient to meet the security model of an enterprise. J2EE provides two methods in EJB ejbconext interface and Servlet httpservletrequest interface:

isCallerInRole (EJBContext)getCallerPrincipal (EJBContext)isUserInRole (HttpServletRequest)getUserPrincipal (HttpServletRequest)

These methods allow components to make business judgments based on the security roles of callers or remote users. Later in this article, we will provide a detailed introduction and examples of these methods, so that readers can better understand the use of programmable security.

2. J2EE Verification Model

Identity Authentication is a process in which a user or component caller proves his/her identity to the system. The user submits authentication information (usually the user name and password or the user's digital certificate) to the system in a certain 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 1 Initial verification process

Figure 1 Initial verification process

Figure 2 verify URL

Figure 3 verify EJB method call

User verification

User authentication can be divided into two types based on different client types: Web Client Authentication and application client authentication.

A. Web Client Verification

Web clients usually use HTTP to request resources on the Web server. These web resources generally include HTML webpages, JSP (Java Server Page) files, Java Servlets, and other binary or multimedia files. In an enterprise environment, certain resources of an enterprise often require only some people to access, and some resources are even confidential or secure and sensitive. Therefore, it is necessary to control access to various web resources in an enterprise. To meet different security levels and custom requirements of enterprises, J2EE provides three verification methods based on web clients:

HTTP Basic Authentication)
HTTP basic authentication is supported by HTTP. This authentication mechanism uses the user name and password as the authentication information. The Web Client obtains the user name and password from the user and passes them to the Web server. The web server verifies the user in the specified region (realm. However, it should be noted that this verification method is not safe enough. This verification method does not encrypt the user password, but only performs base64 encoding on the password. In addition, the target Web server is not verified by users. There is no guarantee that the Web server accessed by the user is what the user wants to access. Some security measures can be taken to overcome this weakness. For example, apply SSL on the transport layer or use IPsec or VPN technology on the network layer.

Form-based authentication)
Form-based verification allows system developers to customize User Login pages and error pages. The only difference between this verification method and the basic HTTP verification method is that it can set login and error pages according to user requirements. Form-based verification methods also have security vulnerabilities similar to basic HTTP verification. The user enters the user name and password in the form, and the password is transmitted in plain text on the network. If a node on the network intercepts the authentication request, after Anti-encoding, you can easily obtain the user's password. Therefore, when using basic HTTP verification methods and form-based verification methods, you must determine that the weaknesses of these two methods are acceptable to your application.

Client-certificate-based authentication)
The client certificate-based authentication method is safer than the preceding two methods. It ensures the security of authentication through HTTPS (HTTP over SSL. The Secure Sockets Layer (Secure Sockets Layer) guarantees data encryption, server authentication, and information authenticity during the verification process. In this authentication method, the client must provide a public key certificate. You can regard this Public Key Certificate as your digital passport. A Public Key Certificate, also known as a digital certificate, is issued by a trusted organization called a Certificate Authority (CA. This digital certificate must comply with the X509 public key architecture (PKI) standard. If you specify this authentication method, the web server uses the digital certificate provided by the client to authenticate the user's identity.

B. Application client User Authentication)
The Java client program is a Java program that runs on the user's external Java virtual machine. The client has mainframes. Generally, the user can directly start the execution through java.exeor javaw.exe. The J2EE application client is similar to the Java client and also has the main method, but they have some differences during runtime. The J2EE application client runs in its own container like other J2EE components. You can use a container to execute the J2EE application client. In this way, the J2EE application client container has the opportunity to complete user identity authentication before the J2EE application client is executed. J2EE provides a customizable method for obtaining user authentication information. You can use the default method provided by the container to obtain user authentication information of the J2EE application client, or you can choose a custom method to obtain user authentication information. When selecting a custom method, the application developer must provide an implementation of javax. security. auth. callback. callbackhandler interfce class, and add the class name of this class to the element callback-handler in the J2EE deployment description file application-client.xml. In this way, when the system needs to verify the user's identity, the client program's container will pass the callbackhandler implementation class name in the deployment description file to the system's login module (verification module ), the login module then instantiates this implementation class. Instances of this type are responsible for collecting user authentication information and passing the collected user authentication information to the login module. The login module uses the authentication information to verify the user. This implementation class can have a user interface, or require user input to collect user authentication information, or obtain user authentication information through the command line, you may also obtain your e-certificate by reading local or online user certificates. The method you choose depends on the Storage Method of the authentication information.

Some J2EE product vendors integrate the container verification service with the verification service of the local system or the verification service of other application system products, thus, the single-point login capability can be achieved within a certain range of application systems.

Single Sign-on)
From the user's perspective, spof allows users to access authorized resources in different application systems in the logical security zone with only one login, re-login is required only when the security region edge is exceeded. This capability is especially valuable for enterprises with multiple IT application systems. With the continuous improvement of Enterprise Informatization construction, more and more application systems are applied in enterprises. In traditional application systems, each system maintains its own security policies. These security policies include organization structure definition, security role definition, user identity verification, and resource access control. Because each system is independent of each other, a user must log on to the system according to the corresponding system identity before using each application system. This requires you to remember the user name and password of each system, which brings a lot of trouble to the user. In this case, the concept of single point of login is introduced and applied to the integration of enterprise application systems. J2ee1.3 also recommends that the J2EE product provide single-point login capability for the application system. However, the j2ee1.3 specification does not specify the standards that J2EE products should follow. Therefore, the single-point login Implementation and Application of products of different vendors are different. Some J2EE products implement Single-point login within the product environment, some implement Single-point login between specific system environments (for example, IBM WebSphere Application 4.0 AE implements WebSphere Application Server and WebSphere Application Server, WebSphere Application Server and Lotus Domino Server, WebSphere Application Server and Lotus single-point login between Domino servers ). In J2EE, single-point login is implemented by passing credential. when a user logs on to the system, the client container (including the Web Client and application client) establishes a security context for the user based on the user's credential ), 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 security context format. Therefore, the security context cannot be transmitted between J2EE products of different vendors. So far, security context is rarely shared among different J2EE products. Therefore, single-point login between different J2EE products can only be integrated through third-party products (such as LDAP Server.

Lazy Authentication)
Authentication is costly. For example, a verification process may include multiple network information exchanges. Therefore, the inertia verification is very useful. Inertia verification allows the user to perform the verification process only when accessing protected resources, rather than when the user initiates the first request.

3. J2EE Authorization Model

Code Authorization)
J2EE uses the Java 2 Security Model to restrict the execution of specific j2se classes and methods to protect and ensure the security of the operating system. For detailed descriptions, see j2se specification document.

Caller authorization)
Security role: a security role is a logical group with the same security attributes. It is assigned by the application assembler or application deployer of the application.

Security role reference:A security role reference is the identifier used by the application provider to reference a security role. Application providers can use security role references to assign resource access permissions to security roles. The security role is also referenced in security-related program code.

Users and groups:Users and groups are a collection of users and users in the actual system environment. They correspond to people and groups in the real world.

Access control:Ram ensures that a security role can only access authorized objects that have been granted security permissions. Authorization objects include remote EJB methods and web resources (HTML webpages, JSP/Servlet and multimedia or binary files. In J2EE, access control is associated with security roles in the application description file.

Ing:The system administrator maps the application to associate users and roles in the actual system environment with security roles. Instead, the actual users have the appropriate authorization to access enterprise resources.

Propagated caller identities)
In J2EE 1.3, you can use the propagation caller ID as the Web component and EJB component caller ID for verification. In this way, the same principal name (principal name) is returned for the getcallerprincipal method of interface ejbcontext in the call chain of the entire EJB component ). If the first EJB in the call chain is called by JSP/servlet, the principal name returned by the interface ejbcontext method getcallerprincipal (principal name) should be the same as the return value of the interface httpservletrequest method getuserprincipal. It is important to note that the user ID is passed in the call chain, rather than the credentials, because users may use different security attributes on each node of the call chain.

Run as identities
J2EE 1.3 allows component developers and deployment to specify the identity of a component to run. Products that comply with j2ee1.3 specifications provide methods to set components to run as identities. If the run as identities method is selected, the caller of the component set as run as identities in the running is no longer the caller of the first node in the call chain, it is the specified caller during deployment. The callers of subsequent nodes in the call chain become the same as those of the component set as run as identities.

Figure 4 User ID Transfer

This section introduces the security concept of J2EE, which is intended to enable readers to have a certain understanding of the security of J2EE. Examples of these concepts will be provided later.

Summary

J2EE provides us with security services for verification and authorization. We should try our best to use the services provided by J2EE when developing J2EE-based applications. Only by following the J2EE standard can your application be highly portable, scalable, and maintainable. Third-party security products or self-developed security services should be considered only when the selected J2EE product cannot meet specific security requirements.

Source: http://www.ibm.com/developerworks/cn/java/l-j2eeSecurity/