Security mechanisms for Web applications

The security mechanism for Web applications is the task that designers and programmers of Web applications must face. In Java EE, the Web container supports the security mechanisms built into the application.

There are two types of security mechanisms for WEB applications: Authentication and authorization. The Web container based on the Java EE provides three types of authentication mechanisms: Basic authentication, form-based authentication, mutual authentication. Because of the ability to customize the authentication user interface, most Web applications use forms-based authentication. The Web container authorizes access to the application's Web resources using the security roles defined in the deployment descriptor of the Web application.

In the use of forms-based authentication mechanisms, application designers and developers encounter 3 types of problems:

1. How forms-based authentication works in conjunction with security mechanisms in other areas such as databases and LDAP. (This is necessary because many organizations have implemented authentication mechanisms in databases and LDAP forms.) ）

2, how to add or remove the function module (the original "junta", do not know what meaning) in the Web application Deployment Descriptor (XML) authorization role.

3. The Web container is authorized at the Web resource level, and the application needs to perform the authorization on the functional level in a single web resource. Although there are many documents and examples related to forms-based authentication, none of them can clarify this issue. As a result, most applications express security mechanisms in their own way.

This article explains how forms-based authentication works in conjunction with other security mechanisms, especially security mechanisms in the database. It also explains how Web windows use security roles to perform authorization and how applications extend these security roles to protect functionality in Web resources.

Forms-based authentication

Forms-based authentication enables developers to customize the user interface for authentication. The Login-config section of Web. XML defines the type of authentication mechanism, the URI of the login, and the error page.

FORM /login.jsp /fail_login.html

The login form must contain fields that enter the user's name and password, which must be named J_username and J_password, and the form will send the two values to the J_security_check logical name. Here is an example of how this form can be implemented in HTML pages:

Action= "J_security_check" >

Unless all connections are implemented on SSL, the form is able to reveal the user name and password. When a protected web resource is accessed, the Web container activates the authentication mechanism configured for that resource.

To make the Web application secure, the Web container performs the following steps:

1. When a protected web resource is accessed, determine whether the user is authenticated.

2. If the user is not certified, the user is required to provide a security trust by redirecting to the registration page defined in the deployment descriptor.

3, according to the security field configured for the container, confirm that the user's trust is valid.

4. Determine whether the authenticated user is authorized to access the Web resource defined in the deployment descriptor (XML).

As is the case with basic security authentication mechanisms, forms-based authentication does not specify a security zone in the deployment descriptor of a Web application. In other words, it does not explicitly define the type of security zone used to authenticate the user, which can cause confusion in what security zone it uses to authenticate users.

To authenticate the user, the web window needs to complete the following steps:

1. Determine the safe area of the container configuration.

2. Use this security zone for certification.

Because databases and LDAP provide greater flexibility in maintaining information, most organizations will want to continue to use them to maintain secure authentication and authorization information.

Many web Windows support different types of security zones: Databases, LDAP, and custom regions. For example, in the Tomcat Web container, Server.xml configures the database as its security zone.

Classname= "Org.apache. debug= "99" Drivername= "Oracle.jdbc. Driver. Oracledriver " Connectionurl= "Jdbc:oracle:thin: @{ipaddress}:{port}:{servicename} " Connectionname= "{DB Username}" Connectionpassword= "{Password}" usercredcol= "Password" />

Tomcat's Server.xml flag defines the type of security area that the window uses to identify a user. Note that the container uses the zone for the Web application, and the authentication mechanism for the application is based on the form.

Authorized

Once the user is identified, the container is given the security role of the authenticating user to see if the user belongs to one of the security roles defined in the flag in the deployment descriptor. If the user does not belong to any one of the security roles, the container returns an error.

The flag for the deployment descriptor (Web. xml) defines the protected Web resources and the list of security roles that can access those resources.

AdminPages accessible by Authorised Users /admin/* GET these is the roles Who has access Manager

The web window performs authentication on the Web page level. However, commercial applications may also want to certify functionality within a Web page, which requires that some new additional application-related security roles be defined in the application. To control access to functionality, the application needs to understand the concept of permissions for the role. The Web container standard does not resolve permissions issues.

Because authorization roles are dynamic, developers often find it confusing whether these security roles need to be added to the deployment descriptor. For the application to take full advantage of security support, the Web container only needs a role defined in the deployment descriptor. Therefore, an application can define a high-level role and then assign all users to that role. This will enable all users in the role to have access to the Web resource.

In addition, applications can define additional roles that perform authorization for lower-level functionality in a Web resource. Because the application is already configured with a high-level security role that includes all users in the application, these low levels of security roles do not need to be defined in the deployment descriptor. This allows the Web application to take advantage of the container's authorization support to implement the authorization associated with the specified application.

We can define a high-level administrator role for all users in the deployment descriptor, protecting the management class Web resources, which enables all users in the Administrator role to access the Administration Web page. To control other features in the Administration Web page, we can create new roles such as sysadmin or appadmin in the application.

Applications can extend these security roles so that they have certain permissions. The application can then use these permissions to control access to its functionality.

Although the security roles associated with a particular application are not defined in the deployment descriptor, these roles can still be used in the IsUserInRole method to determine whether the user is in these security roles.

Advantages

• Web applications need not implement authentication mechanisms to simplify the configuration of Web applications.

• Web applications can use the Getremoteuser, IsUserInRole, and Getuserprincipal methods to achieve planned security. The

• Web application is able to propagate authentication information to the EJB container.