| J2EE specifies a component programming model for security that supports both APIs (programmatic security) and declared properties (declarative security). In the declarative security model, deployment descriptors are the primary vehicle for specifying security constraints for Web and EJB applications in a form that's external to the application and enforced by J2EE containers. WebLogic Server is fully compliant to support the declarative security model for J2EE Web and EJB applications, allowing security constraints specified in deployment descriptors ( web.xml , weblogic.xml , ejb-jar.xml , and weblogic-ejb-jar.xml ) to be integrated into its security service. However, this approach does require you to redeploy an application if security changes are made to the deployment descriptors so that they can be reintegrated into the WebLogic Security Service. To support a unified security management environment for a WebLogic administrator, the new WebLogic Security Service enables you to deploy a J2EE application and ignore any defined security constraints, so you can define the application's roles and polices visually in the Administration Console. You can ignore security constraints defined in deployment descriptors for applications within the context of a specific security realm by following these steps: -
Click the name of the security realm you are setting this option forfor example, myrealm. -
In the General tab, select the Ignore Security Data in Deployment Descriptors check box, as shown in Figure 26.7. Figure 26.27. Enable the Ignore Security Data in Deployment Descriptors option for a security realm.  -
Click the Apply button to save your changes. These roles and policies are then stored in the security database assigned to the active security realm. Alternatively, you can initially load the security constraints for a J2EE application upon deployment into the WebLogic Security Service, and then switch over to managing security roles and policies solely via the Administration Console by enabling the Ignore Security Data in Deployment Descriptors option. Note Regardless of the method you choose for managing WebLogic application security, it should be consistent across all your deployed applications.
The following section demonstrates how to implement WebLogic security for a simple Web application by using the Administration Console. Securing a Web Application Through the Administration Console The following sections describe how you can apply security to a simple Web application by using the WebLogic Security Service and leverage the knowledge on WebLogic users, groups, roles, and security policies you have gained earlier in this chapter. Use the steps in these following sections to create, deploy, and apply security constraints to a Web application through WebLogic Server. - Step 1. Creating the Sample Web Application
The Web application you need to create and deploy to WebLogic Server consists of the following components :
-
welcome.jsp : Configured as the welcome page for the Web application. The code for this JSP is provided in Listing 26.2. Listing 26.2 The welcome.jsp Component <html> <head> <title>Security Web Application Example</title> </head> <blockquote> <h1> Security Login Example </h1> <% // declare Remote User variable String rmuser = request.getRemoteUser(); %> <% // Display the name of the user if (rmuser != null) { out.println("Welcome " + rmuser); %> <p> Click here to <a href="admin/myWebPage.jsp">Enter</a> the application. <% } else { out.println("You are entering this Web Application for the first time"); %> <p> Click here to <a href="login.jsp">login</a> <% } %> </blockquote> </body> </html> -
admin\myWebPage.jsp : This page is used to indicate a successful authentication into the Web application, so it is configured with a security constraint. The code for this JSP is provided in Listing 26.3. Listing 26.3 The admin\myWebPage.jsp Component <html> <blockquote> <h1> Security Login Example </h1> <% // declare Remote User variable String rmuser = request.getRemoteUser(); %> <% // Display the name of the user if (rmuser != null) { out.println("You are successfully authenticated " + rmuser); %> <p> Click here to <a href="logout.jsp">Logout</a> <% } %> </blockquote> </body> </html> -
login.jsp: This page is configured in web.xml to be displayed whenever an unauthorized user attempts to access a Web page protected by a security constraint. The code for this JSP is provided in Listing 26.4. Listing 26.4 The login.jsp Component <html> <head> <title>Security Example Login Page</title> </head> <blockquote> <h2>Please enter your Username and Password:</h2> <p> <form method="POST" action="j_security_check"> <table border=1> <tr> <td>Username:</td> <td><input type="text" name="j_username"></td> </tr> <tr> <td>Password:</td> <td><input type="password" name="j_password"></td> </tr> <tr> <td colspan=2 align=right><input type=submit value="Submit"></td> </tr> </table> </form> </blockquote> </body> </html> -
admin/logout.jsp: This page is displayed when the user logs out of the Web application. The code for this JSP is provided in Listing 26.5. Listing 26.5 The logout.jsp Component <html> <head> <title>Security logout page</title> </head> <blockquote> <h1> Goodbye <%= request.getRemoteUser() %>! </h1> <% weblogic.servlet.security.ServletAuthentication.logout(request); %> <p> You are now logged out. <p> Click here to <a href=<%= "\""+request.getContextPath()+"\""%>> revisit the site</a>. </blockquote> </body> </html> -
fail_login.html : The error page that is configured in web.xml to be displayed after a failed login attempt. The code for this page is provided in Listing 26.6. Listing 26.6 The fail_login.html Page <html> <head> <title>Login failed</title> </head> <body bgcolor =#ffffff> <blockquote> <h2>Your username and password could not be authenticated by WebLogic Server.</h2> <p><b> <a href="/security/welcome.jsp">Return to Login Page</a> </b> </blockquote> </body> </html> -
WEB-INF/web.xml : The deployment descriptor that configures access to the admin directory of the Web application. The code for this deployment descriptor is provided in Listing 26.7. Listing 26.7 The web.xml Deployment Descriptor [View full width] <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3 //EN" "http:/  /java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <welcome-file-list> <welcome-file>welcome.jsp</welcome-file> </welcome-file-list> <security-constraint> <web-resource-collection> <web-resource-name>AdminPages</web-resource-name> <description>These pages are only accessible by authorized administrators.</description> <url-pattern>/admin/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>These are the roles who have access</description> <role-name>WebApp</role-name> </auth-constraint> <user-data-constraint> <description>This is how the user data must be transmitted</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/fail_login.html</form-error-page> </form-login-config> </login-config> <security-role> <description>Web App Role</description> <role-name>WebApp</role-name> </security-role> </web-app> Create each Web application component, using the code in the preceding listings.
- Step 2. Configure Security Options for Your WebLogic Server and Security Realm
You can control how WebLogic Server performs security on Web and EJB applications by using the fullyDelegatedAuthorization command argument when your WebLogic Server is started:
-
If the value of fullyDelegatedAuthorization is set to false , the WebLogic Security Service performs security checks only on Web and EJB applications that have security specified in their associated deployment descriptors. This is the default setting: set JAVA_OPTIONS=... -Dweblogic.security.fullyDelegatedAuthorization=false -
If the value of fullyDelegatedAuthorization is set to true , the WebLogic Security Service performs security checks on all Web and EJB applications, even if security settings do not exist in the deployment descriptors. set JAVA_OPTIONS=... -Dweblogic.security.fullyDelegatedAuthorization=true Note The fullyDelegatedAuthorization argument affects only the WebLogic Server instances in which it is set. In a distributed WebLogic Server environment, you should ensure that the fullyDelegatedAuthorization flag is set the same way for all your WebLogic servers. If you decide the WebLogic Security Service should always perform security checks on all Web and EJB applications by setting the fullyDelegatedAuthorization flag to true , you also need to specify what the WebLogic Security Service should do when the Web or EJB application is redeployed through the Ignore Security Data in Deployment Descriptors security realm option.
For this example, set the fullyDelegatedAuthorization to true , and enable the Ignore Security Data in Deployment Descriptors option so that you can control security for the Web application in the Administration Console.
- Step 3. Deploy the Web Application to Your WebLogic Server
To deploy this Web application, you can use one of the following options:
-
Create a directory under your domain /applications ( domain is your WebLogic domain directory) directory, and copy the files to their respective target directory locations. Your WebLogic Server, if it is started in development mode, automatically deploys your Web application. This type of deployment is referred to as an exploded directory deployment. -
Create the appropriate directory structure for this Web application, copy the files into their respective target directory locations, and then archive the application into a WAR file by using the jar Java utility. Finally, deploy the WAR to WebLogic Server via the Administration Console, using the name "security" to identify the Web application. Note You can also use WebLogic Builder to create an archive file and deploy the Web application to WebLogic Server.  For an example of how to deploy a simple Web application, see "Deploying Your First Web Application Using the WebLogic Builder," p. 371 , in Chapter 11,"Working with the WebLogic Server Tools."
- Step 4. Testing the Web Application with No Security
To ensure that you see the effects of applying security constraints to the deployed Web application, testing the Web application's operation without any security constraints applied is a good idea. By default, all authenticated users accessing this deployed Web application will be members of the Everyone group , which grants them access to all aspects (URLs) of the application.
To test the default operation of the sample Web application, use these steps:
-
Start your Web browser and enter the following URL: http:// hostname:port /security In this URL, substitute the following information: For example, http://localhost:7001/security displays the welcome page shown in Figure 26.28. Figure 26.28. The welcome page of the Web application.  -
Click the login link to display the Login page, as shown in Figure 26.29, where you enter the username and password associated with a WebLogic user account, such as the Sean user you created earlier. Figure 26.29. The Login page of the Web application.  -
If the login is successful, the welcome page appears, as shown in Figure 26.30, and displays the name of the authenticated user. Figure 26.30. A successful authentication to WebLogic Server.  -
Click the Enter link to enter the aspect of the Web application ( myWebPage.jsp ) that you will secure later in this section, as shown in Figure 26.31. Figure 26.31. An example of a successful entry to a secured aspect of the Web application.  -
If the authentication fails, the failed login page is displayed, as shown in Figure 26.32. Figure 26.32. An example of a failed login to the Web application.  - Step 4. Applying Security Constraints to the Web Application
The security constraint placed on the Web application is as follows :
-
Only the URL resources of the Web application in the /admin directory are secured. -
All users accessing the secured /admin URL resources need to be a member of the WebApp group. -
Access to the secured URL resources is allowed only between 9:00 a.m. and 5:00 p.m. To implement these security constraints, follow these steps:
-
Create a group named WebApp. -
Create users and assign them to the WebApp group. -
Create a global role named EndUserAccess and include the WebApp and time constraints as expressions to the role statement. Note The WebApp group and EndUserAccess role were created earlier in this chapter. -
Define a security policy for the Web application: -
Right-click the Web application named security in the Administration Console, and select the Define Policy option. -
In the displayed General tab, enter /admin/* as the URL pattern. -
Click Define Policy. -
In the displayed Security Policy editor window, create a policy statement specifying that the caller is granted the EndUserAccess role, as shown in Figure 26.33. Figure 26.33. Define a security policy for the Web application based on the EndUserAccess role.  -
Click Apply to save your changes. - Step 5. Testing Your Secured Web Application
Now test the operation of your secured Web application, using the following scenarios:
-
WebLogic users who are members of the WebApp group. -
WebLogic users who are not members of the WebApp groups. -
Users who are not configured as WebLogic users. -
WebLogic users who are members of the WebApp group, but are accessing the Web application outside the time constraint defined in the EndUserAccess role. Notice that only users who meet the security policy are allowed access to myWebPage.jsp .
 |
