Содержащиеся вНайти другие документыРесурсы поддержки | Загрузить это руководство в формате PDF (1491 КБ)
Chapter 4 Post-Installation Tasks of Policy Agent 2.2 for BEA WebLogic Server/Portal 9.2This chapter describes configuration and other post-installation considerations and tasks. After completing the applicable tasks described in this chapter, perform the tasks to configure the agent to your site's specific requirements as described in Chapter 6, Managing Policy Agent 2.2 for BEA WebLogic Server/Portal 9.2. Common Post-Installation Steps for All J2EE Agents in Policy Agent 2.2The tasks described in this section apply to all J2EE agent installations. Updating the Agent Profile for J2EE Agents in Policy Agent 2.2The agent profile is created and updated in Access Manager Console. The agent profile should originally be created prior to installing an agent. However, after you install a J2EE agent, you can update the agent profile at anytime. After you update the agent profile in Access Manager Console, you must configure the J2EE agent accordingly as described in this section.
|
. domain-directory/setAgentEnv_${SERVER_NAME}.sh
|
For this scenario, the following is a conceivable line if the domain directory is named mydomain:
. /usr/local/bea/user_projects/domains/mydomain/setAgentEnv_${SERVER_NAME}.sh
|
Therefore, in this scenario, the start up script would then, amongst other lines, contain these two lines as shown:
. ${DOMAIN_HOME}/bin/setDomainEnv.sh $*
. /usr/local/bea/user_projects/domains/mydomain/setAgentEnv_${SERVER_NAME}.sh
|
Windows Platforms
call "domain-directory\setAgentEnv_%SERVER_NAME%.cmd" |
For this scenario, the following is a conceivable line if the domain directory is named mydomain:
call "C:\bea\user_projects\domains\mydomain\setAgentEnv_%SERVER_NAME%.cmd" |
Therefore, in this scenario, the start up script would then contain, amongst other lines, these two lines as shown:
call "%DOMAIN_HOME%\bin\setDomainEnv.cmd" %* call "C:\bea\user_projects\domains\mydomain\setAgentEnv_%SERVER_NAME%.cmd"
a variable for the BEA WebLogic Server/Portal 9.2 instance that is dynamically replaced. Do not replace or modify this variable. Therefore, ensure that the variable is entered and remains character for character as ${SERVER_NAME} for UNIX platforms and %SERVER_NAME% for Windows platforms.
Restart the BEA WebLogic Server/Portal 9.2 instance.
Restarting the BEA WebLogic Server/Portal 9.2 instance at this point is necessary. Otherwise, upcoming tasks will fail.
If you are configuring BEA WebLogic Server 9.2 (not BEA WebLogic Portal 9.2), deploy the Agent Application at this point in the configuration process by following the steps in Deploying the Agent Application of Agent for BEA WebLogic Server/Portal 9.2.
This section is specific to BEA WebLogic Server 9.2. For instructions specific to BEA WebLogic Portal 9.2, see To Configure the Agent Authentication Provider Specifically for BEA WebLogic Portal 9.2.
Using security service provider API exposed by BEA WebLogic Server/Portal 9.2, the agent plugs its custom security Authenticator into the container. Once the Agent Authenticator is configured, all requests call it. You only need to set the Agent Authenticator once per WebLogic domain. For more information on security service provider architecture visit http://e-docs.bea.com/wls/docs92/dvspisec/intro.html.
The authentication provider can be added by using the BEA WebLogic Server/Portal 9.2 Administration Console. The information provided in this section serves to facilitate the configuration of the Agent Authentication Provider and is in no means a substitute for the information provided in WebLogic Server/Portal documentation. For a detailed discussion on WebLogic Authentication providers, search for the proper WebLogic documentation at http://www.bea.com.
This task description is specific to BEA WebLogic Server 9.2 (not BEA WebLogic Portal 9.2). For the task description specific to BEA WebLogic Portal 9.2, start with Portal: Configuring the Agent Authentication Provider on Agent for BEA WebLogic Server/Portal 9.2.
Log in to the BEA WebLogic Server 9.2 Administration Console.
In the left pane, under Domain Structure and under the host name of the server you are configuring, click “Security realm.”
In the right pane, click the name of the realm you are configuring.
Click the Providers tab.
Click the Authentication tab.
In the left pane, click Lock & Edit.
In the right pane, click New.
Specify Type as AgentAuthenticator.
Specify Name with a name of your choice.
Click OK.
Click the newly created policy agent authentication provider.
Change the control flag value to OPTIONAL.
Click Save.
Click the Providers tab.
The Authentication Providers Table appears.
Click Default Authenticator.
Change the control flag to OPTIONAL.
Click Save.
In the left pane, click Activate changes.
If you choose to create a new security realm instead of using the default security realm to configure the agent, ensure that the control flag value for the Agent Authenticator and any additional authentication providers are set to OPTIONAL.
This section is applicable to both BEA WebLogic Server 9.2 and BEA WebLogic Portal 9.2.
The task description that follows involves editing the J2EE agent AMAgent.properties configuration file in order to add the user ID of the WebLogic administrative user to the list of bypassed principals. This administrative user may then bypass the authentication process involving Access Manager realm.
Using the text editor of your choice, access the J2EE agent AMAgent.properties configuration file.
Add the user ID of the WebLogic administrative user to the bypass principal list.
For example, to add the administrative user whose user ID is weblogic to the bypass principal list, set the following property as shown:
com.sun.identity.agents.config.bypass.principal[0] = weblogic
(Conditional) If you are finished editing the J2EE agent AMAgent.properties configuration file, save and close the file.
Much of the task described subsequently applies to both BEA WebLogic Server 9.2 and BEA WebLogic Portal 9.2. However, the most critical information required for performing this task is also provided separately inPortal: Deploying the Agent Application. If you would prefer to follow the simplified instructions, see that section.
The agent filter can be installed by modifying the deployment descriptor of the application that needs to be protected.
The following steps explain how to install the agent filter for the application you want the agent to protect:
(Conditional) If the application is currently deployed on BEA WebLogic Server/Portal 9.2, remove it before proceeding any further.
Create the necessary backups before proceeding to modify these descriptors.
Since you will modify the deployment descriptor in the next step, creating backup files at this point is important.
Edit the application’s web.xml descriptor.
The filters were introduced in Servlet Specification 2.3. For more information about this specification, see http://jcp.org/aboutJava/communityprocess/first/jsr053/index.html.
The <DOCTYPE> element of the web.xml descriptor must be changed to reflect that the deployment descriptor is, at minimum, a Servlet 2.3 compliant deployment descriptor. To reflect this compliance perform the following substeps.
Set the <DOCTYPE> element as follows:
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
|
Add the <filter> elements in the deployment descriptor by specifying the <filter> and the <filter-mapping> elements immediately following the description element of the <web-app> element in the descriptor web.xml.
The following is a sample web.xml descriptor with the <filter> and the <filter-mapping> elements added:
<web-app>
<filter>
<filter-name>Agent</filter-name>
<filter-class>com.sun.identity.agents.filter.AmAgentFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Agent</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>
|
Ensure that the agent filter element precedes all the other <filter> elements. Similarly, the filter mapping element should be before all the other <filter-mapping> elements. In practice, the agent filter should first intercept the request to properly enforce policies on the whole application.
Once the web.xml deployment descriptor is modified to reflect the new <DOCTYPE> and <filter> elements, the agent filter is added to the application. You can now redeploy your application on BEA WebLogic Server/Portal 9.2.
The rest of this section focuses on BEA WebLogic Server 9.2, not on BEA WebLogic Portal 9.2. For information specific to the web.xml deployment descriptor regarding BEA WebLogic Portal 9.2, see Portal: Installing the Agent Filter for the Deployed Application on Agent for BEA WebLogic Server/Portal 9.2.
If you want to protect your application with J2EE declarative security or with any other filter modes, such as ALL or URL_POLICY, refer to the PolicyAgent-base/sampleapp directory to learn how to build and deploy an application. The sampleapp directory is by no means a full fledged J2EE application. Rather it is a simple application that provides you with a quick reference to application specific deployment descriptors and various deployment modes of a J2EE agent. Once you successfully deploy sampleapp and test all of its features, you can use it as a reference to other applications that will be protected by the J2EE agent.
If you run this agent in J2EE_POLICY mode, map Access Manager roles to the principal names for the deployed application. The principal names are available in the weblogic.xml file and the weblogic-ejb-jar.xml file. Either or both of these files might exist.
You can retrieve Access Manager roles by issuing the agentadmin --getUuid command. For more information on this command, see agentadmin --getUuid. You can also retrieve the universal ID for the user (UUID) using the Access Manager 7 Console to browse the user profile.
Mapping that converts Access Manager roles to principal names is performed by configuring the following property:
com.sun.identity.agents.config.privileged.attribute.mapping[]
For more information on setting this property, see the following:
Mapping-related attributes in Privileged Attribute Processing Properties
Steps described in this section might be required, depending on your site's specific deployment.
This section is not applicable for BEA WebLogic Portal 9.2. The manner in which the settings for the agent filter mode are applied to BEA WebLogic Server 9.2 differs from BEA WebLogic Portal 9.2. For BEA WebLogic Portal 9.2, creating a policy to protect a resource requires you to set the filter mode to ALL as described in To Configure Agent Filter Modes Applicable to BEA WebLogic Portal 9.2.
If the agent is installed and configured to operate in the URL_POLICY mode or ALL mode, the appropriate URL policies must be created. For instance, if BEA WebLogic Server 9.2 is available on port 7001 using HTTP protocol, at least a policy must be created to allow access to the following resource:
http://myhost.mydomain.com:7001/sampleApp/ |
where sampleApp is the context URI for the sample application.
If no policies are defined and the agent is configured to operate in the URL_POLICY mode or ALL mode, then no user is allowed access to BEA WebLogic Server/Portal 9.2 resources. See Sun Java System Access Manager 7 2005Q4 Administration Guide to learn how to create these policies using the Access Manager Console or command-line utilities.
This section is not applicable for BEA WebLogic Portal 9.2.
If you are using this agent for BEA WebLogic Server 9.2 (not BEA WebLogic Portal 9.2) and the agent is set to the J2EE_POLICY filter mode, map Access Manager roles to the principal names in the respective application's deployment descriptor file (or files):
weblogic.xml
weblogic-ejb-jar.xml
Access Manager roles are represented in UUIDs. For more information on UUIDs, see the following:
The Note in To Install the Agent Filter for the Deployed Application on Agent for BEA WebLogic Server/Portal 9.2
A UUID for an Access Manager role is mapped to the respective principal name in the weblogic.xml file or the weblogic-ejb-jar.xml file. Specifically, the principal name is located within the <principal-name> element.
Mapping is established by setting the property com.sun.identity.agents.config.privileged.attribute.mapping[] in the J2EE agent AMAgent.properties configuration file.
Ensure that the keys in the mapping are UUIDs corresponding to your site's Access Manager installation. The values are the principal names in the weblogic.xml file or the weblogic-ejb-jar.xml file.
In previous releases of BEA WebLogic, this mapping is not required. The UUIDs representing Access Manager roles are used directly in the weblogic.xml file or the weblogic-ejb-jar.xml file as principal names.
However, starting with BEA WebLogic 9.0, a principal name within the weblogic.xml file or the weblogic-ejb-jar.xml file must be of the NMTOKEN format. This format is mandated by the corresponding schema files.
Access Manager UUIDs include the following characters (equal sign, comma, and ampersand):
=
,
&
These characters are not in NMTOKEN character sets. Therefore, the UUIDs representing Access Manager roles cannot be used directly as principal names. Instead, they must be mapped to characters in the NMTOKEN character set, which includes letters and digits as well as the following characters (period, hyphen, underscore, and colon):
.
-
_
:
The following examples, which use “\” as an escape character before the special character “=,” illustrate how this property can be set:
com.sun.identity.agents.config.privileged.attribute.mapping[id\=manager,ou\=role, dc\=iplanet,dc\=com] = am_manager_role
com.sun.identity.agents.config.privileged.attribute.mapping[id\=manager,ou\=role, dc\=iplanet,dc\=com] = am_employee_role
For more information on this property, see the mapping-related attributes in Privileged Attribute Processing Properties.