You must perform specific procedures to protect the WebSphere Application Server 6.1 Administration Console and the web applications protected by the agent. This agent achieves the goal of protecting both the Administration Console web application and other web applications with the same agent binaries and configuration.
The tasks of setting the Custom Registry, adding the Access Manager Trust Association Interceptors, and enabling global security, which are all described subsequently in this section, are to be performed once per WebSphere Application Server 6.1 node regardless of how many WebSphere Application Server 6.1 instances exist within that node.
Start the WebSphere Application Server 6.1 instance.
For example, the following command starts a WebSphere Application Server 6.1 instance named host1:
startServer.bat host1
Log in to the WebSphere Application Server 6.1 Administration Console.
Navigate to the Custom user registry page.
Set the provider of the custom registry.
In the Custom Registry class name field, replace the existing value with the following value:
com.sun.identity.agents.websphere.AmAgentUserRegistry
In the “Primary administrative user name” field, enter the administrative user name, which was previously created in Access Manager. For example: wasadmin
For the Server user identity option:
In environments that contain only version 6.1 or later nodes, select “Automatically generated server identity”.
In environments whose cell contains version 5.x or 6.0.x nodes, select “Server identity that is stored in the repository”. Enter the agent profile user name (such as agentprofileuser) in the “Server user ID or administrative user on a Version 6.0.x node” field, and enter the agent profile user password in the “Password” field.
Click OK. The page returns to “Secure administration, applications, and infrastructure”.
Click the “Save directly to the master configuration” link.
This task allows the agent to establish single sign-on (SSO) with the protected WebSphere Application Server 6.1 instance.
In the WebSphere Application Server 6.1 Administration Console, navigate to the Interceptors page.
Click New. A new page opens.
In the “Interceptor class name” field, enter:
com.sun.identity.agents.websphere.AmTrustAssociationInterceptor
Click OK. The browser returns to the Interceptor page.
Click “Save directly to the master configuration”.
Navigate again to the Interceptors page by clicking the “Trust association” link at the top of the page.
Check the “Enable trust association” checkbox.
Click OK. The page returns to “Secure administration, applications, and infrastructure”.
Click “Save directly to the master configuration”.
In the WebSphere Application Server 6.1 Administration Console, navigate to Global security page.
Check the “Enable administrative security” checkbox.
Make sure that “Enable application security” is also checked.
Optionally, enable “Java 2 security” on the same page.
Click Apply.
Click “Save directly to the master configuration”.
From the WebSphere Administrator console, expand the Users and Groups node.
Click “Administrative Group Roles”. A new page opens.
Click the Add button. A new page opens.
Click “Save directly to the master configuration”.
After the agent installation, edit the following property in the AMAgent.properties file:
From:
com.sun.identity.agents.config.logout.uri[ibm/console] = /ibm/console/logoff.do
To:
com.sun.identity.agents.config.logout.uri[ibm/console] = /ibm/console/logout.do
If you have not deployed the agent application, deploy the agentapp.war file as described in Deploying the Agent Application for Version 2.2 J2EE Agents. This application will trap notifications and perform other housekeeping tasks.
The procedures that you have performed up to this point enable the Trust Association Interceptor to protect the Administration Console while users log in and establish the correct principal. However, the Trust Association Interceptor cannot trap logout events, enforce URL policies, and such. The agent filter allows the enforcement of coarse grained URL policies defined within Access Manager to further control the access to protected resources on the WebSphere Application Server 6.1 Administration Console.
Therefore, the agent filter must be inserted into the web.xml file as explained in the following steps to protect the Administration Console. Without the filter element, you can log in to the Administration Console and perform normal operations, but the logout button will not function.
The agent filter should be the last filter executed in sequence. Therefore, ensure that you insert the agent filter after all other filters in the web.xml file.
Change to the following directory:
DeployContainer-base/profiles/profile name/config/cells/cell name/applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/
where DeployContainer-base represents the directory within which the WebSphere Application Server 6.1 instance was installed.
Create a back up of the web.xml file.
Insert the agent filter into the file.
Ensure that the agent filter that you add is the last filter to be executed in sequence. The example shows an excerpt of the web.xml file before the agent filter is added:
<filter> <filter-name>WSCUrlFilter</filter-name> <filter-class>com.ibm.ws.console.core.servlet.WSCUrlFilter</filter-class> </filter> <filter-mapping> <filter-name>WSCUrlFilter</filter-name> <servlet-name>action</servlet-name> </filter-mapping> <filter-mapping> <filter-name>WSCUrlFilter</filter-name> <url-pattern>/federatedlogoff</url-pattern> </filter-mapping>
The example shows the agent filter in bold text:
<filter> <filter-name>WSCUrlFilter</filter-name> <filter-class>com.ibm.ws.console.core.servlet.WSCUrlFilter</filter-class> </filter> <filter> <filter-name>Agent</filter-name> <filter-class>com.sun.identity.agents.filter.AmAgentFilter</filter-class> </filter> <filter-mapping> <filter-name>WSCUrlFilter</filter-name> <servlet-name>action</servlet-name> </filter-mapping> <filter-mapping> <filter-name>WSCUrlFilter</filter-name> <url-pattern>/federatedlogoff</url-pattern> </filter-mapping> <filter-mapping> <filter-name>Agent</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> |
This task involves creating the corresponding URL policies in the Access Manager Console so that a specific user, group, or role has access to the WebSphere Application Server 6.1 Administration Console.
Create URL policies that will provide the appropriate subjects with access to the Administration Console.
Ensure that you give access to both HTTP and HTTPS based administration URLs.
For example, you might allow the wasadminrole role access to the WebSphere Application Server 6.1 Administration Console by setting the following URL patterns:
http://host1.subexample.example.com:9060/* https://host1.subexample.example:9043/*
In this example, the WebSphere Application Server 6.1 Administration Console is running with the HTTP protocol set at port 9060 and the HTTPS protocol set at 9043. All other changes to the agent configuration to trap logout events have already been configured by the agent installer in the AMAgent.properties file. Note that the agent is configured in the most restrictive mode ALL at this point.
This task involves verifying that the previous tasks were performed properly and that the subjects assigned access to the WebSphere Application Server 6.1 Administration Console can access the console.
Start the WebSphere Application Server 6.1 instance that you just configured.
Run the WebSphere Application Server 6.1 agent in message mode.
Log in to the WebSphere Application Server 6.1 Administration Console as a user who belongs to the WebSphere administrative role. For example: wasadminrole
If the user is properly redirected to Access Manager, enter the user name and password for any user assigned the wasadminrole role in Access Manager.
If you are allowed access, you should be redirected to the WebSphere Application Server 6.1 Administration Console.
Perform normal operations in the WebSphere Application Server 6.1 Administration Console.
Click logout.
You should be redirected to the Access Manager Console.