The tasks in this section enable the WebSphere Application Server/Portal Server agent to protect both web applications and the WebSphere Application Server 6.1/7.0 Administration Console.
You perform the following tasks only once for each WebSphere Application Server 6.1/7.0 node, regardless of the number of WebSphere Application Server 6.1/7.0 instances that exist within the node.
Setting the WebSphere Application Server 6.1/7.0 Custom Registry
Adding an OpenSSO Enterprise Trust Association Interceptor to WebSphere Application Server 6.1/7.0
Enabling Global Security for WebSphere Application Server 6.1/7.0
Granting Access to the WebSphere Application Server 6.1/7.0 Administration Console
Installing the Agent Filter for the WebSphere Application Server 6.1/7.0 Administration Console
Allowing Access to the WebSphere Application Server 6.1/7.0 Administration Console
Verifying Access to the WebSphere Application Server 6.1/7.0 Administration Console
If needed, start the WebSphere Application Server 6.1/7.0 instance.
For example, for an instance named host1: ./startServer host1
Log in to the WebSphere Application Server 6.1/7.0 Administration Console.
Navigate to the Custom user registry page.
Expand the Security node.
Click “Secure administration, applications, and infrastructure”. A new page opens.
For WebSphere Application Server 7.0, click “Global Security”.
Under the Available realm definitions field, select Standalone custom registry.
Click the Set as current button.
Click the Configure button. A new page opens.
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 OpenSSO Enterprise. For example: wasadmin
For the Server user identity option, select “Automatically generated server identity”.
Click OK. The page returns to “Secure administration, applications, and infrastructure”.
For WebSphere Application Server 7.0, it's “Global Security”.
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/7.0 instance.
Log in to the WebSphere Application Server 6.1/7.0 Administration Console.
Navigate to the Interceptors page:
Expand the Security node.
Click “Secure administration, applications, and infrastructure”. A new page opens.
For WebSphere Application Server 7.0, click “Global Security”.
Under the “Authentication” option, expand “Web security”.
For WebSphere Application Server 7.0, expand “Web and SIP Security”.
Click “Trust association”. The “Trust association” page opens.
Click the Interceptors link. The Interceptors page opens.
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”.
For WebSphere Application Server 7.0, it's “Global Security”.
Click “Save directly to the master configuration”.
Perform this task only once per WebSphere Application Server 6.1/7.0 node, regardless of the number of WebSphere Application Server 6.1/7.0 instances that exist within the node.
Log in to the WebSphere Application Server 6.1/7.0 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”.
Log in to the WebSphere Application Server 6.1/7.0 Administration Console.
Expand the Users and Groups node.
Click “Administrative Group Roles”. A new page opens.
Click the Add button. A new page opens.
In the “Group name” field, enter wasadmingroup, which was defined earlier.
For WebSphere Application Server 7.0:
Select “Map Groups As Specified Below”.
In the “Search string” field, enter wasadmingroup, and then click Search.
In the “Available” field, find and select “id=wasadmingroup,ou=group,ROOT_SUFFIX@AmRealm”.
Click the right arrow button to add the results into the “Mapped to role” field.
In the “Role(s)” field, select “Administrator”.
Click OK and return to the “Administrative Group Roles” page.
Click “Save directly to the master configuration”.
Log in to the OpenSSO Enterprise Administration Console.
Click Access Control and then the name of the realm.
Click Agents, J2EE, and then the name of the agent profile.
Click Application.
Under Application Logout URI, enter the following values:
Map Key: ibm/console
Corresponding Map Value: /ibm/console/logout.do
Click Add and then Save.
The corresponding property is: .
com.sun.identity.agents.config.logout.uri[ibm/console] = /ibm/console/logout.do
This property is hot-swappable, so you do not need to restart the OpenSSO Enterprise web container instance.
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 or enforce URL policies. The agent filter allows the enforcement of coarse grained URL policies defined within OpenSSO Enterprise to further control the access to protected resources on the WebSphere Application Server 6.1/7.0 Administration Console.
Therefore, you must add the agent filter to the web.xml file, as described 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.
Locate the web.xml file for the WebSphere Application Server 6.1/7.0 instance.
For example:
DeployContainer-base/profiles/profile name/config/cells/cell name/applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/
where DeployContainer-base represents the directory where the WebSphere Application Server 6.1/7.0 instance was installed.
Back up the web.xml file.
Add the agent filter to the web.xml file.
Ensure that the agent filter 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> |
Restart the WebSphere Application Server 6.1/7.0 web container instance.
This task involves creating the corresponding URL policies in the OpenSSO Enterprise Console so that a specific user or group has access to the WebSphere Application Server 6.1/7.0 Administration Console.
Log in to the OpenSSO Enterprise Administration Console.
Create URL policies that provide the appropriate subjects with access to the WebSphere Application Server 6.1/7.0 Administration Console.
Ensure that you give access to both HTTP and HTTPS based administration URLs. For example, you might allow the wasadmingroup access to the WebSphere Application Server 6.1/7.0 Administration Console by setting the following URL patterns:
http://host1.subexample.example.com:9060/*
https://host1.subexample.example.com:9043/*
http://host1.subexample.example.com:9060/*?*
https://host1.subexample.example:9043/*?*
In this example, the WebSphere Application Server 6.1/7.0 Administration Console is running with the HTTP protocol on port 9060 and the HTTPS protocol on port 9043. All other changes to the agent configuration to trap logout events have already been configured by the agent installer. 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/7.0 Administration Console can access the console.
Start the WebSphere Application Server 6.1/7.0 instance that you just configured.
Run the WebSphere Application Server 6.1/7.0 agent in message mode.
Log in to the WebSphere Application Server 6.1/7.0 Administration Console as a user who belongs to the WebSphere administrative group. For example: wasadmin
If the user is properly redirected to OpenSSO Enterprise, enter the user name and password for any user assigned to the wasadmingroup in OpenSSO Enterprise.
If you are allowed access, you should be redirected to the WebSphere Application Server 6.1/7.0 Administration Console.
Perform normal operations in the WebSphere Application Server 6.1/7.0 Administration Console.
Click logout.
You should be redirected to the OpenSSO Enterprise Console.