http://www-900.ibm.com/developerWorks/cn/wsdd/techjournal/0303_barcia/barcia.shtml
Introduction
More and more business applications are now on the J2EE platform, which is benefited from J2EE to provide a good framework and service support for the development of enterprise applications. J2EE provides a number of services for enterprise applications (Security, Transaction, Naming, etc.). This article will introduce the security services provided by J2EE. The author first introduces the security concepts in J2EE and J2EE security architecture, then combines the specific case to show the reader how to apply J2EE to the security feature provided in its own program. The content described in this article is based on the J2EE1.3 version.
Second. Safety concept in J2EE
Principal: Principal is an entity that is verified in a corporate security service. Principal uses the body name as its identification data, via verification data related to the subject. Usually the main name is the user's login name, verifying data is the login password. The J2EE specification does not limit what kind of authentication method for J2EE product providers, so the content and format of the main name and verification data are different from different authentication protocols. Security Principles Domain: Along the security domain (Security Domain) or Realm, it is a logical range or field, the administrator of the security service in this range or field defines and implements the general security principles. It is a field that is divided from the perspective of security principles. For example, enterprise application systems can be divided into different security domains such as business employees, suppliers, partners, etc., which use different security principles for these security fields. Security Technology Domain: It is a field from the perspective of security technology, using the same security mechanism in a secure technology domain to perform security principles. A security technology domain can include multiple security principles domains. Security Attributes: All the subjects have a series of security properties associated therewith. Security properties can be used to access protected resources, check the user's identity and complete other security-related purposes. J2EE product provider or specific verification service is actually determined how to connect security properties with a body. The J2EE specification does not limit what kind of security attribute will be connected to the body. Credential: The credentials include or refer to the J2EE system to verify the authentication message (security attribute). If successful passes through verification, the subject will get a credential that includes a security property. If allowable, a subject may also get a credential for another body. In this case two main body have the same security attributes in the same security domain.
Three. J2EE safety architecture
1. Container-based security
In the J2EE environment, the security of the components is responsible for their respective containers. The developers of components can hardly use or rarely add relevant security code. Such safety logic and business logic are relatively independent architectures that make the enterprise-level application system have better flexibility and expandability. J2EE Specification Requirements J2EE Products must provide applications developers with two forms of container-based security - illustrative security and programmable security. A. Illustrative security illustrative security represents the security requirements of the application through safety structure, and the security structure generally includes security roles, access control, and verification requirements. The main tool for deploying subsequent security in the J2EE platform. The deployment description is an exchange tool between component developers and application departments or application assembers. The developer of the application uses it to indicate the security requirements in the app, the application departments or application assemblers map the security role to the users and groups in the deployment environment. When the program execution, the container extracts the corresponding security principle from the deployment descriptor, and then the container performs security verification according to the security principle. The security of the description does not require the staff to write any security-related program code, everything is done through the set deployment descriptor. B. Programmed security can be programmed on the basis of illustrative security, making security-sensitive applications can make a decision on security through the API provided by the container. This is very useful in the case of illustrative safety is not sufficient to meet the security model of the company. J2EE provides two methods in EJB EJBCONEXT INTERFACE and Servlet HttpservletRequest Interface: InterlallerinRole (EJBCONTEXT)
getCallerPrincipal (EJBCONTEXT)
iSuserinrole (httpservletRequest)
GetUserPrincipal (httpservletRequest)
These methods allow components to make business judgments based on the caller or remote user's security role. In the back section of the article, there will be a detailed introduction and example of these methods so that the reader can better understand the use of programmed security.
2. J2EE verification model
Authentication is the process of prove its identity to the system to the system. The user submits a verification message to the system through some way (usually the user name and password or the user's digital signature), the system is provided to verify the identity of the user using the user's authentication message and system security principles. Figure 1 initial verification process
Figure 2 Verify URL Figure 3 Verify EJB Method Call User's Verification User Verification Different from its client type Different: Web client authentication and Application client authentication a. Web client verification web client usually The HTTP protocol requests resources from the web server, which typically includes HTML web, JSP (Java Server Page), Java Servlet, and some other binary or multimedia files. In a corporate environment, some resources of companies often require only certain people to access, some resources are even confidential or sensitive. Therefore, it is necessary to access control over enterprises. In order to meet the needs of different safety levels and customization in the enterprise, J2EE provides three web client-based authentication methods: HTTP Basic Authentication HTTP Basic Authentication is the validation mechanism supported by the HTTP protocol. This verification mechanism uses the user's user name and password as a verification message. The web client gets the user name and password from the user, and then passes them to the web server, the web server verifies the user in the specified field (Realm). However, it should be noted that this verification method is not safe enough. Because this verification method does not encrypt the user password, it is only the basic base64 encoding of the password. And the target web server is also non-verified by the user. The web server that cannot guarantee that the user's access is the user wants to access. Some security measures can be used to overcome this weakness. For example, SSL is applied on the transport layer or use IPSec or VPN technology on the network layer. Form-based Authentication Based on Form-based Authentication Enables system developers to order user login pages and error pages (ERROR PAGES). The only difference between this verification method and the basic HTTP authentication method is that it can develop login and error pages based on the user's requirements. Form-based verification methods also have an unsafe weakness similar to basic HTTP verification. The user fills in the user name and password in the form, and the post password is passed in the network in the form of a text. If the verification request is intercepted in a node in the network, it is easy to obtain the user's password. Therefore, when using basic HTTP verification methods and form-based authentication methods, it is determined that the weakness of these two ways is acceptable to your application. Client-certificate Authentication is more secure than the above two methods based on client certificates. It guarantees authentication security through HTTPS (HTTP Over SSL). SSL provides security assurance for data encryption, server-side authentication, and message authenticity, etc. for the verification process. In this verification method, the client must provide a public key certificate, you can see this public key certificate as your digital passport. The public key certificate is also known as a bit sign, which is known as a certificate authority (CA) - a trusted organization. This digital signature must comply with the standard of the X509 public key architecture (PKI). If you specify this verification method, the web server will use the client's digital signature to verify the user's identity. b. Application Client User Authentication Java client program is a Java program executing on the User's local Java virtual machine, which has a main method, usually by using Java.exe or Javaw.exe Directly start execution.
The J2EE application client is similar to the Java client program, and also has a main method, but they have a certain difference in execution. The J2EE application client is executed in its own container as other J2EE components. The user performs the J2EE application client through the container. Such J2EE application client containers have the opportunity to complete the authentication of the user's identity before the J2EE application client is executed. J2EE provides a custom-made manner to get the user's verification message. You can choose to use the preset of the use of the container to obtain the user's verification message for the J2EE application client program, or you can choose to obtain the user's verification message. When you choose a custom-made approach, the application developer must provide a category that implements Javax.Security.Auth.Callback.CallbackHandler InterfCE, and adds to the elements in the J2EE deployment describe the element Callback-handler in Application-Client.xml. This category name is named. In this way, when the system needs to verify the user identity, the client program's container passes the Callback Module (Verification Module) of the CallbackHandler's Category in the deployment to the system, and the login module will be sampled. This work is . This category case is responsible for collecting the user to verify the message and pass the collected user verification message to the login module, and login into the module with these verification messages to verify the user. This actual category can be a user interface, or through the request user input to collect the user verification message, or by the instruction line to obtain the user verification message, it may also be read by reading local or Online user certificate library acquires the user's electronic certificate. Select which way depends on the way of verify the message. Some J2EE product vendors integrate the verification service of the container and the authentication service of the local system or other verification services for other application system products, thereby implementing a single login capacity within a certain application system. Single sign-on-on single logo From the user's point of view, it means that the user can only be logically available in different application systems in this logical security field in a specific logical security field. The authorized resources are only required to log in again as the edge of the security field. This capability is more valuable to companies coexisting in a variety of IT applications. As the level of information, the company's message is continuously improved, the application system in the enterprise has more and more. In traditional application systems, each system respectively maintain its own security principles, which typically include organizational structural definition, security role definition, user authentication, resource access control, and so on. Since each system is independent of each other, a user must log in according to the corresponding system before using each application system. This must remember the user's name and password for the user, bringing a lot of trouble to the user. For this situation, the concept of a single way forward is generated, and it is constantly applied to the integration of the company's application system. J2EE 1.3 is also in specifications that J2EE products should provide a single login capability for the application system. However, J2EE 1.3 specification does not specify what standards should follow J2EE products, so different manufacturers of products are different in single login. Some J2EE products have implemented a single login within the environment of this product, and some have a single login between a particular system environment (such as IBM WebSphere Application 4.0 AE, which is the WebSphere Application Server, WebSphere Application Single login capabilities between Server and Lotus Domino Server). Single login in J2EE is to pass through the credential (Credential).
When the user performs system login, the client container (including the web client and application client) builds a security content for the user according to the user's credential (CREDENTIAL), security content including the security content including for verification Users' safety information, system use this security content and security principles to determine if the user has access to system resources. Unfortunately, the J2EE specification does not specify the format of security content, so security content cannot be passed between the J2EE products of different vendors. So far, there are very few security content between different J2EE products, so you can only integrate through third-party products such as LDAP Server, etc. between different J2EE products. Lazy Authentication Authentication is at the price. For example, a verification process may include multiple times through a network message exchange. Therefore, inert verification is very useful. Inert verification is to execute the verification process when the user has protected resources, rather than performing the verification process when the user first initiates the request. 3. J2EE authorization model
Program Authorization J2EE Product Limits the execution of a specific J2SE to protect and ensure the security of the operating system through the Java 2 security model. For details, see "J2SE Specification Files". Caller Authorization Security Role: Security role is a logical group with the same security attribute. It is assigned by the Application Business (Application Deployer) assigned by the application's assembly. Safety Role Reference Security Role Reference is the application provider (Application Provider) to refer to the identification data of the security role. Application Provider (Application Provider) can use security roles to refer to the security role to assign resource access rights. Also refer to the security role in the security-related program code. Users and group users and groups are a collection of users and users in the actual system environment. The person and group access control access control in the actual realities can ensure that the security role can only access the authorization object that has been granted to security privileges. Authorized objects include remote methods of EJB, web resources (HTML web pages, JSP / servlets, and multimedia or binary files). Control is connected to the security role in the application description file in J2EE. Mapping The system administrator in the image application connects the user and roles of the actual system environment with the security role to enable the actual user with appropriate authorization to enterprise resource access. Propagated Caller Identities (Propagated Caller Identities) can select the propagation caller identification data as the Identification data of the web component and the EJB component caller in J2EE 1.3 for verification. In this manner, the method of Interface EJBCONText in the call chain of the entire EJB component is passed back to the same subject name (Principal Name). If the first EJB in the call chain is by the JSP / Servlet call, the principal name (Principal Name) transmitted by the interface EJBCONTEXT is the same as the transmitted value of the interface httpservletRequest's method GetUserPrIncipal. It should be noted that the user's identification data is passed in the call chain, not the credentials, which is very important because users may use different security properties on each node of the call chain. The Run As Identities J2EE 1.3 provides the method of allowing component developers and deployments to specify what identity of components. Products that meet the J2EE 1.3 specification will provide a method of setting a component into a Run As Identities method. If the Run As Identities method is selected, the caller of the component set to Run as Identities in execution is no longer the caller of the first node in the call chain, but the caller specified at the time of deployment. The caller of the subsequent node in the call chain is also the same as the caller of the components set to RUN AS Identities. Figure four user identification data transfer This section describes the security concept of J2EE, which is intended to make readers have a certain understanding of J2EE in terms of security, and there will be specific examples of application of these concepts. in conclusion
