Before using the administrative console
to enable security on Windows NT, ensure the security user ID has the certain
permissions. See Giving an NT user administrative privileges
in the security task help for information.
If other tasks are required due to specific or rare operating system conditions, they will be documented on the product Web site as Release Notes or technical hints.
Follow these instructions to establish default security settings for applications. New applications you create will use the defaults. You can also specify authentication and user registry information that will apply to all applications.
Press the wizards button and select "Configure Global Security Settings." The first page of the wizard looks like this:
This page is where you enable WebSphere Application Server security. If the Enable Security check box is not selected, all security settings in this task and others will be disregarded.
Select the Enable Security check box:
Next, click the Application Defaults tab:
As its name indicates, this tab contains default settings for application security. In other words, when you configure an application, you can override or accept these default values for the individual application.
The rest of the settings in this task are global, meaning they are shared by all applications. They cannot be customized for particular applications.
The Application Defaults tab contains a realm setting. When a user tries to access the application, he or she will be prompted to log on to the realm. A realm is the domain over which Single Sign On (SSO) is applied. For more information, see "What are security realms."
On this tabbed page, you can specify how users will be challenged for security credentials. For example, they can be prompted for a user ID and password, or a digital certificate instead.
For the Account application, specify Basic authentication.
Click the Authentication Mechanism tab to specify how to authenticate the information presented by users trying to access an application or resources:
For the Account application, specify that users will be authenticated against the users defined in the user registry of the local operating system.
Now click the User Registry tab. Specify the security ID and password under which the WebSphere Application Server security server will run:
The User Registry tab content is dynamic, depending on whether you selected Local Operating System or LTPA as the Authentication Mechanism. To observe this, return to the Authentication Mechanism tab and click the LTPA option:
Now click the User Registry tab. You will see a different set of properties than before. With these LDAP properties you can configure authentication with an LDAP-enabled directory service product instead of with the local operating system:
Return to the Authentication Mechanism tab and reselect the Local Operating System button, and then click Finish to complete the global security settings task.
If you receive an error on Windows NT, ensure the security ID you specified for the application has certain privileges. It must be able to log on as a service" and act as part of the operating system.
This message confirms a successful security configuration and lets you know that you have to stop the administrative server and start it again:
For changes on the Authentication Mechanism, User Registry, and General tabbed pages of the Configure Global Security Settings task to take effect, including "Enable security," you must stop the administrative server and start it again.
On the Topology tab, right-click the node for the local machine and click Stop for restart.
A message will ask you to confirm this. Click Yes:
The administrative server will shut down after shutting down the administrative console.
Wait for the server to stop, then start it again. Start the administrative console again.
When you start the console, you will be prompted to log on:
Enter the security ID and password you specified during the product installation.
Now configure an individual application, the Account application. Press the wizards button and select "Configure Application Security."
On the first panel, expand Enterprise Applications and select to apply application security to the AccountApp you configured earlier:
Click Next to proceed. The next panel lets you override the default settings you specified in the Configure Global Security Settings task. Notice you do not have the option to change the truly global security settings you specified in the earlier task. They are shared by this application and all others:
You will then see the following panel where you may optionally specify a user ID and password for the enterprise beans used with this application. We won't use this, so simply click Finish to complete the task.
Perform this task to create custom method groups for protecting the HTTP and EJB methods of individual resources. You only need custom method groups if you need more than the default method groups.
For example, a method group cannot simultaneously limit access to HTTP methods in the group and allow everyone access to EJB methods in the group. All methods in a method group share the same permission -- if you want to give everyone access to one method in the group, you have to give everyone access to all methods in the group.
Therefore, it is not really possible for a method group to contain a mix of methods from protected HTML and JSP files and unprotected enterprise beans. If you want to "unprotect" an enterprise bean for the reasons discussed in "Default protection of resources" in the security help, you must use one or more custom method groups to isolate its methods from the HTTP methods. Then you can protect the HTTP methods with the default groups and allow everyone access to the beans in your custom groups, or a similar arrangement. "Unprotecting an enterprise bean" will be discussed further in the next tutorial section.
Go ahead and create a custom method group. Press the wizards button, select "Configure Security Method Groups." Select Add a new method group and press Next. Type MyCustomMethodGroup in the New Method Group field and click Finish:
In addition to applying security at the application level, configure security for the HTTP and EJB methods of each resource.
By default, enterprise beans are protected. Servlets, Web pages, and JSP files are not. This section of the tutorial will show you how to apply security to the unprotected items.
The article about unprotecting resources, located in the security sction discusses cases in which you might want to "unprotect" an enterprise bean. That procedure is not demonstrated here directly, but it is discussed. In fact, the concept was introduced in the last section, when you configured your custom method group. Unprotecting a bean is one use for custom method groups.
"Unprotecting" a bean might be demonstrated in subsequent tutorial versions -- watch the product Web site for updates.
Press the wizards button and select "Configure Resource Security." On the first panel, expand EnterpriseBeans and specify to apply resource security to the AccountBean:
Click Next to proceed. A prompt asks whether to use the default method groups. Specify Yes:
The next panel shows how WebSphere Application Server has grouped the methods of the Account Bean into method groups for protection:
Click the folders to see which method groups are associated with the methods. For example, the ejbCreate method of the Account Bean has been protected with the CreateMethods method group. Using the final security task, you will specify who is allowed to access the CreateMethods method group.
Suppose you also want your custom method group to protect the ejbCreate method. Select the method and click the Add button:
Specify MyCustomMethodGroup and click OK:
Now MyCustomMethodGroup is displayed below the ejbCreate method, indicating it is protecting that method of the Account Bean:
Enterprise beans are protected by default, when security is enabled. If you wanted to "unprotect" the enterprise bean, instead of following the above procedure, you would use only your custom method group to protect the enterprise bean. You would not apply the default method groups if you planned to use them to protect other resources.
Click Next to proceed to a page for further enterprise bean security settings:
You can use the panel to have the enterprise bean run as the system administrator, a client, or an identity you specify. This is known as delegation.
The top part of the page lets you set a default identity for the enterprise bean methods to use. If the deployment descriptor of the enterprise bean for which you are configuring resource security (in this case, Account Bean) specifies this kind of information, the information is displayed in the default area as a starting point. You can keep the deployment descriptor settings or override them.
The lower part of the page lets you customize the identities under which individual methods will run. If you do not specify an identity for an individual method, it will use the defaults you specified in the top half of the panel.
To specify an identity for a particular method, click the method in the Specified Methods list and use the lower right corner of the panel to specify the identity information.
Click Finish. Start the Configure Resource Security task over again, this time specifying to configure security for all JSP files in the AccountWebApp Web application.
The delegation settings just discussed are not applicable to JSP files, Web pages, and servlets. The task wizard does not display the delegation panel unless you are configuring enterprise bean security.
Proceed through the task, specifying the servlet directory of the Web application this time:
Use the default method groups to protect the servlet HTTP methods:
You are shown how the HTTP methods were categorized:
Click Cancel.
Finally, you can give users and groups permission to access the resources within your applications.
Press the wizards button and select "Configure Security Permissions" to display this screen, which allows you to choose the methods associated with either an application or a method group:
Select View by Application, select the AccountApp, and press Next. This panel will show you the permissions you can possibly grant to users and groups:
Before granting the Account Application permissions, try the following exercise.
Click the AccountApp-ReadMethods permission and press Next. This panel allows you to specify the users or groups to whom you want to grant permission to access this method group:
You can select to grant Everyone access to those methods. Instead, limit the access to the local operating system administrator. Click Selection to search for that identity. Specify to search for a user:
Type "Administrator" in the Search Filter field and click Search. The Administrator is displayed in the Search Results box. Click the Administrator, then click OK:
Searching for the Administrator is
likely to work only on Windows NT machines. If using UNIX, try searching for
the "Staff" group, or another user or group ID that you are sure exists on the
machine.
Now you see that the administrator has been granted permission to access read-only methods in the Account application:
Now specify the real permissions for the Account application. First, click the Administrator and click Remove. Then click all of the Account application method groups while holding down the Control button ("Ctrl" on your keyboard):
Click Next to display the Grant Permissions dialog. Specify All Authenticated Users:
Verify that All Authenticated Users have access to each of the Account action method groups:
Press the Finish button to complete this task.
Now verify that the application can be accessed successfully, given the security you applied.
First, make sure the application server containing the application is aware of the newest application and security settings.
If the server is already started, first stop it (using the stop button on the console toolbar), then start it again.
Tip: When configuring your own application, you would stop and start all application servers containing Web applications belonging to your application.
Next, use a browser to test the Web application. Based on the Web application configuration, here is how to assemble the URL for accessing the Web application:
The final part of the URL is the specific resource from which you enter the application. In this case, createjsp.html is the entry Web page.
The entire URL is then of the form:
http://Valid_default_host_Alias/webapp/AccountWebApp/createjsp.html
Try one or more of these URLs in a browser to ensure they work.
If you receive an error:
You can click resources in the Topology tree to view their properties and check these values.
If the Web path is missing, you can add it, then restart the servlet's application server for the change to take effect.
If the Web path is configured in the servlet's Web path list, but is not in the servlet's "Web paths in use" list, stop the server and start it again to put the Web path in use.
For example, here are the Web path settings for the CreateAccountJSP servlet. They are empty:
You would have to stop the application server and start it again to make this take effect. When the Web path is displayed in the "Servlet Web Paths in Use" list, it is currently a valid Web path for accessing the resource.
Note that if you tried to access CreateAccountJSP right now with the above settings, the request would likely fail. It needs one or more Web paths "in use."
When you configure a servlet, some Web paths are generated automatically based on its membership in a Web application. You usually do not have to worry about a servlet lacking any Web paths.