Combined with was, analysis of login authentication and non-standard cancellation in J2EE specifications and addition of custom processing process through Filter

In simple applications, you will have a separate set of user storage and management systems, however, maintaining a single set of such systems for each application in enterprise-level applications will cause heavy maintenance work and difficulty of application expansion. Due to its standard LDAP protocol, the corresponding LDAP server can be used as a user storage and management platform for enterprise applications. In this way, the user information required by any system is in the LDAP service, and the application itself can manually obtain the user information for authentication. However, the J2EE specification specifies the authentication and authorization modules that must be implemented by web containers. That is to say, in previous applications, whether a user has the permission to log on to the system to access related resources must be completed by the application itself. Under the J2EE specification, the content can be handed over to the container. J2EE provides multiple authentication methods to demonstrate the form-based authentication process.

The above authentication process is form-based authentication. It can be seen that it has a core class j_security_check, which is a servlet stipulated by J2EE, all Web containers implement this servlet. When we use a container for authentication and send a protected resource request to the server, the Web container checks whether the request has the relevant permissions. If the request has no permissions, the Web Container will send the configured logon page back to confirm the login information, and then go through j_security_check
Servlet performs authentication. If the authentication succeeds, the related resources are returned. If the authentication fails, the configured error page is returned. (This process only shows the general idea, which far cannot describe the J2EE authentication specification and single sign-on content)

Follow these steps to use form-based authentication:

1) configure the Web container to work with a security realm for login verification (this part of most enterprise applications has been configured)

2) create a logon page

3) create an authentication failure page

4) configure the application as the Web Container authentication and authentication page and authentication failure page

There are no requirements for the page mentioned in the third point, but some requirements on the logon page must be met. The form action must be specified on j_security_check. The username tag ID is j_username, And the password tag ID is j_password. The core code of the logon page is as follows:

<Form action = "j_security_check" method = "Post"> <div> <input type = "hidden" id = "hide"/> <input type = "text" id =" j_username "name =" j_username "class =" nameclass "/> <input type =" password "id =" j_password "name =" j_password "class =" passwordclass "/> <Input type = "Submit" value = "login" class = "btn2"/> <input type = "reset" value = "reset" onclick = "resetbtn_click () "Class =" btn1 "/> </div> </form>

After Authentication fails, the Web Container returns an error page without any restrictions on the compilation of the error page. Generally, the logon form content is still available, but there are more prompts for failed authentication. The login pages and authentication failure pages of different applications on was are different. The protected and unprotected resources of each application are also different. The information is configured on Web. XML, as shown below:

<security-constraint><display-name>SecurityConstraint</display-name><web-resource-collection><web-resource-name>SecurityConstraint</web-resource-name><url-pattern>/</url-pattern><url-pattern>/*</url-pattern></web-resource-collection><auth-constraint><role-name>All Authenticated</role-name></auth-constraint><user-data-constraint><transport-guarantee>NONE</transport-guarantee></user-data-constraint></security-constraint><security-constraint><display-name>unSecurityConstraint</display-name><web-resource-collection><web-resource-name>unSecurityConstraint</web-resource-name><url-pattern>/index.jsp</url-pattern><url-pattern>/login.jsp</url-pattern><url-pattern>/WorkplaceFx.html</url-pattern><url-pattern>/lotusforms/*</url-pattern><url-pattern>/assets/*</url-pattern><url-pattern>/css/*</url-pattern><url-pattern>/com/*</url-pattern><url-pattern>/cache/*</url-pattern><url-pattern>/history/*</url-pattern></web-resource-collection><auth-constraint><role-name>Everyone</role-name></auth-constraint><user-data-constraint><transport-guarantee>NONE</transport-guarantee></user-data-constraint></security-constraint><login-config><auth-method>FORM</auth-method><form-login-config><form-login-page>/index.jsp</form-login-page><form-error-page>/error.jsp</form-error-page></form-login-config></login-config><security-role><role-name>All Authenticated</role-name></security-role><security-role><role-name>Everyone</role-name></security-role>

The two security-constraint labels in the preceding Code define protected and non-protected resources respectively, the login-config label defines the authentication method adopted by the application, the login page for authentication, and the authentication failure page.

As mentioned above, it takes four steps to use form-based authentication, the previous section briefly describes the login page, error page, and related configurations (protected resources, unprotected resources, login pages, error pages, authentication methods, etc, then how can the application server know where to authenticate. Assume that the application server uses WebSphere and the user storage and management platform uses the LDAP server. The following describes how to configure the was Authentication database and startup process by adding an LDAP repository to was6.1 and later versions. The following operations are performed on the was console.

1) Security> Security Management, applications and infrastructure> joint repository> Manage repository, and click "add" to add a new external repository.

2) enter the following data on the "new" Page:

Database ID: select an easy description, which can be a server host name or an English description.

Directory type: Select IBM Tivoli Directory Server 6 or domino or Microsoft Active Directory.

Main Host Name: Host Name of the main directory server.

Failover Host Name: when the main directory server fails out of service, was v6.1 will automatically switch to the Backup Directory Server.

Logon attribute: The default value is uid. If you want to allow users to log on with another LDAP attribute, for example, you can log on with UID, CN, or email, then you can enter UID and CN; email.

Other LDAP servers can point to information: data on the LDAP server can be directed to other LDAP Servers through referral.

SSL communication required: to configure the communication between the was and LDAP server, use SSL.

Certificate ing: If a J2EE Web application enables SSL Certificate login, was extracts the subject from the SSL certificate provided by the client browser by default, in the LDAP server, compare the DN attributes of the inetorgperson class object. If the attributes are the same, the certificate authentication of this person is successful, the user's identity is the user whose personal object DN attributes are the same as the SSL certificate subject.

3) after the LDAP external repository is created, the repository is not actually referenced by the "federated repository". You still need to make a simple reference management configuration. Choose Security> Security Management, application and infrastructure> federated repository, and click "add basic entry to domain ".

4) after the "joint repository" is configured, you also need to "Enable management security" and "enable application security" respectively ".

After all configurations are complete, multiple user information repositories may have been configured in the federated repository. After was is stopped and restarted, When you access a J2EE Web application, was will search for user information in all the repositories including the configured repository for authentication.

The above content can be said to be in the J2EE specification, but there are some differences in the specific implementation of different containers. For a user, there will be a cancellation process when there is a login process. The "logout" is not specified in the J2EE specification. We can use other methods to log out.

In J2EE, j_security_check servlet is specified for login authentication. Although no servlet is specified for cancellation, this servlet is defined in was, that is, ibm_security_logout, the usage process is similar to the use of j_security_check described earlier. The Code is as follows:

<Form method = "Post" Action = "ibm_security_logout" name = "logout"> <input type = "Submit" name = "logout" value = "logout"> <! -Logoutexitpage indicates the page on which the application will turn after cancellation --> <input type = "hidden" name = "logoutexitpage" value = "/login. jsp"> </form>

Most application servers do not implement such Servlets, but we can manually simulate the was logout process. The principle is to first obtain httpsession and then invalidate the session. The general code is as follows:

HttpSession session = request.getSession (); Session.invalidate (); 

In this way, our logon is generally qualified, but before and after authentication, we may do some other things, such as logging. Due to the authentication process in the J2EE specification, the principle is to submit the user information to a servlet -- j_security_check -- implemented by the Web container for verification (however, the servlet address cannot be used manually, it can only be used in the form action like the previous Code), so we can add a filter when accessing the Java class as usual.

Filter code:

Package COM. chwd; import Java. io. ioexception; import javax. servlet. filter; import javax. servlet. filterchain; import javax. servlet. filterconfig; import javax. servlet. servletexception; import javax. servlet. servletrequest; import javax. servlet. servletresponse; public class loginfilter implements filter {private string initparameter = ""; Public void Init (filterconfig) throws servletexception {// get the initialization parameter // this parameter is obtained through the Web. init-Param in the filter label in XML for configuration // This parameter may be used before and after was authentication. initparameter = filterconfig. getinitparameter ("initparameter");} public void dofilter (servletrequest request, servletresponse response, filterchain) throws ioexception, servletexception {// The processing to be done before was authentication can be done in this place //...... // perform the j_security_check authentication filterchain implemented by was in the J2EE specification. dofilter (request, response); // After was authentication, the processing can be performed in this location //......} public void destroy (){}}

The code above shows that the filterconfig class has the ability to obtain initialization parameters. parameters are stored on the web. configure in XML. In the filter configuration code, observe that its url-pattern is/j_security_check, that is, the servlet that handles the verification process, although this address cannot be manually used (one of the explanations is that you cannot manually pass the user name and password to this servlet, you can only submit the address using a form ), however, we can use the filter introduction to add our own processing.
The configuration code is as follows:

<Filter> <filter-Name> loginfilter </filter-Name> <filter-class> COM. chwd. loginfilter </filter-class> <init-param> <param-Name> initparameter </param-Name> <param-value> parameters required for processing before and after was authentication </param-Value> </init-param> </filter> <filter-mapping> <filter-Name> loginfilter </filter-Name> <URL-pattern>/j_security_check </url-Pattern> </filter-mapping>

This article briefly describes the form-based authentication mechanism of the J2EE Security system, and describes the steps required to complete form Authentication through the instance code, in addition, this article also describes how to configure was to use LDAP as its user repository and how to use the logout processing and login filter used in combination with the login authentication items. This is only one of the mechanisms of the J2EE Security system. The implementation and operation details of different application servers are also different. However, this article leads the development towards J2EE.