Sun Java System Access Manager Policy Agent 2.2 Guide for Apache Tomcat 5.5 Servlet/JSP Container

Key Features and Tasks Performed With the J2EE AMAgent.properties Configuration File

The J2EE agent AMAgent.properties configuration file is a text file of configuration properties that you can modify to change J2EE agent behavior.


Caution – Caution –

The content of the J2EE agent AMAgent.properties configuration file is very sensitive. Changes made can result in changes in how the agent works. Errors made can cause the agent to malfunction.


This section describes the most important details of the J2EE agent AMAgent.properties configuration file, such as how specific properties can be modified to produce specific results. The topics described are typically those of greatest interest in real-world deployment scenarios. This section does not cover every property in the file. For a list and description of every property, see Appendix B, J2EE Agent AMAgent.properties Configuration File in Policy Agent 2.2.

The following is the location of the AMAgent.properties file;

PolicyAgent-base/AgentInstance-Dir/config

For more information about the Policy Agent 2.2 directory structure, see J2EE Agent Directory Structure in Policy Agent 2.2.

Hot-Swap Mechanism in J2EE Agents

Certain property keys in the J2EE agent AMAgent.properties configuration file are hot-swap enabled. The value for these keys, when altered, are dynamically loaded by the agent such that it is not necessary to restart the deployment container for these changes to take effect. However, in cases where the property is explicitly identified as not enabled for hot-swap or in cases when the hot-swap mechanism is disabled on the system, the deployment container must be restarted for the changes to take effect.

When the agent is deployed on a deployment container where Access Manager has been configured, the hot-swap mechanism is disabled by default and cannot be used.

The hot-swap mechanism is controlled by the following configuration property:

com.sun.am.policy.config.load.interval

The valid values for this property is any unsigned integer including 0, which indicates the amount of time in seconds after which the agent will check for changes to the configuration. A setting of 0 disables the mechanism. By default, this mechanism is set to 0 and is, therefore, disabled.

This mechanism is primarily provided to facilitate the development and testing of your application in a controlled development or test environment. It is strongly recommended that this feature be disabled for production systems to ensure optimal utilization of system resources. Also, in a production system by disabling this feature, any accidental changes to the agent configuration will not take effect until the deployment container has been restarted.

The property that controls the hot-swap mechanism itself is hot-swap enabled. This means that if the hot-swap mechanism is enabled and you change the value of this property, the new value will take effect after the last hot-swap load interval expires. This can be therefore used to dynamically disable the entire hot-swap system. For example consider the following situation:

When the value of the load interval is set to 0 during the startup of the deployment container, the hot-swap mechanism will be disabled and cannot be enabled without restarting the server and ensuring that this value is set to a value greater than 0.

List Constructs in the J2EE AMAgent.properties Configuration File

Certain property keys in the J2EE agent AMAgent.properties configuration file are specified as lists. A list construct has the following format:

<key>[<index>] = <value>
key

The configuration key (name of the configuration property)

index

A positive number starting from 0 that increments by 1 for every value specified in this list.

value

One of the values specified in this list


Note –

Properties that are specified in this manner must follow the preceding format, otherwise they will be treated as invalid or missing properties.

More than one property can be specified for this key by changing the value of <index>. This value must start from the number 0 and increment by 1 for each entry added to this list.

If certain indices are missing, those indices are ignored and the rest of the specified values are loaded at adjusted list positions.

Duplicate index values result in only one value being loaded in the indexed or adjusted indexed position.



Example 5–1 Example of List Constructs in J2EE AMAgent.properties File

com.sun.am.policy.example.list[0] = value0 
com.sun.am.policy.example.list[1] = value1
com.sun.am.policy.example.list[2] = value2

Map Constructs in the J2EE AMAgent.properties Configuration File

Certain property keys in the J2EE agent are specified as maps. A map construct has the following format:

<key>[<name>]=<value>
key

The configuration key (name of the configuration property)

name

A string that forms the lookup key as available in the map

value

The value associated with the name in the map


Note –

Properties that are specified in this manner must follow the preceding format, otherwise they will be treated as invalid or missing properties.

For a given <name>, there may only be one entry in the configuration for a given configuration key (<key>). If multiple entries with the same <name> for a given configuration key are present, only one of the values will be loaded in the system and the other values will be discarded.



Example 5–2 Example of Map Constructs in J2EE AMAgent.properties File

com.sun.am.policy.example.map[AL] = ALABAMA 
com.sun.am.policy.example.map [AK] = ALASKA
com.sun.am.policy.example.map [AZ] = ARIZONA

J2EE Property Configuration: Application Specific or Global

Certain property keys in the J2EE agent AMAgent.properties configuration file can be configured for specific applications. Therefore, the agent can use different values of the same property for different applications as defined in the configuration file. Properties that are not configured for specific applications apply to all the applications on that deployment container. Such properties are called global properties. An application specific property has the following format:

<key>[<appname>]=<value>
key

The configuration key (name of the configuration property)

appname

The application name to which this configuration belongs. The application name is the context path of the application without the leading forward slash character. In case when the application has been deployed at the root-context of the server, the application name should be specified as DefaultWebApp.

value

The value used by the agent to protect the application identified by the given application name


Note –

When an application specific configuration is not present, the agent uses different mechanisms to identify a default value. Configurations are possible where the default value is used as the value specified for the same key without any application specific suffix [<appname>]. The following settings for a single property serve as an example:

com.sun.identity.agents.config.example[Portal] = value1
com.sun.identity.agents.config.example[DefaultWebApp] = value2
com.sun.identity.agents.config.example = value3

The preceding example illustrates that for applications other than the ones deployed on the root context and the context /Portal, the value of the property defaults to value3.


Application Specific configuration properties must follow the rules and syntax of the map construct of configuration entries.


Example 5–3 Example of Application Specific and Global Configuration

com.sun.identity.agents.config.example[Portal] = value1
com.sun.identity.agents.config.example[BankApp] = value2
com.sun.identity.agents.config.example[DefaultWebApp] = value3

J2EE Agent Filter Modes

The agent installation program and the J2EE agent AMAgent.properties configuration file allow you to set the agent filter in one of the five available modes of operation. Depending upon your security requirements, choose the mode that best suits your site's deployment. The following configuration property is used to control the mode of the agent filter:

com.sun.identity.agents.config.filter.mode

The value for this property can be one of the following:

Regardless of what mode the agent filter is operating in, the agent realm will continue to function, if configured. This can therefore lead to a situation where the agent realm component may malfunction or may result in the negative evaluation of J2EE security policies configured in the application's deployment descriptors or being used through the J2EE programmatic security API. To avoid this, you may disable the agent realm component, if necessary. The sections that follow describe the different agent filter modes and also tell you how to disable the agent realm.

J2EE Agent Filter Mode-NONE

This mode of operation effectively disables the agent filter. When operating in this mode, the agent filter allows all requests to pass through. However, if the logging is enabled, the agent filter will still log all the requests that it intercepts.


Note –

This mode is provided to facilitate development and testing efforts in a controlled development or test environment. Do not to use this mode of operation in a production environment at any time.


Although this mode disables the agent filter from taking any action on the incoming requests other than logging, it has no effect on the agent realm that may still be configured in your deployment container and may get invoked by the deployed application if the deployed application has J2EE security policies in its descriptors or uses programmatic security. With the agent filter disabled, these applications will fail to evaluate the J2EE security policies correctly and as a result the deployed application may malfunction. In order to fully disable the agent, you must therefore ensure that the agent realm is not active. Refer to the section Disabling the Agent Realm to find out how the agent realm can be disabled for your agent installation. Once you have disabled the agent realm and the filter mode is set to NONE, it is functionally equivalent to not having the agent in your system at all.


Note –

When the agent filter is operating in this mode, any declarative J2EE security policy or programmatic J2EE security API calls will return a negative result regardless of the user.


J2EE Agent Filter Mode - SSO_ONLY

This is the least restrictive mode of operation for the agent filter. In this mode, the agent simply ensures that all users who try to access protected web resources are authenticated using Access Manager Authentication Service. In this mode of operation the agent realm is not used and can be safely disabled. For information about disabling the agent realm, see Disabling the Agent Realm of Policy Agent 2.2 for Apache Tomcat Servlet/JSP Container.


Note –

When operating in this mode, any declarative J2EE security policy or programmatic J2EE security API calls evaluated for the application will result in negative evaluation.


J2EE Agent Filter Mode - J2EE_POLICY

In this mode, the agent filter and agent realm work together with variousAccess Manager services to ensure the correct evaluation of J2EE policies. These policies may be configured using the declarative security in the application's deployment descriptors, or may be implicit in the code of the application in the cases where it uses the J2EE programmatic security APIs. No URL policies defined in Access Manager take effect in this mode of filter operation. When the deployed application uses declarative security in the web-tier, you must configure the agent to enable this feature. See Enabling Web-Tier Declarative Security in J2EE Agents for more information on how to enable this feature. When running in the J2EE_POLICY mode, the agent ensures that the security principal is set in the system for every authorized user access. In the J2EE_POLICY mode, the agent will not enforce any applicable URL policies as defined in Access Manager.

J2EE Agent Filter Mode - URL_POLICY

In this mode, the agent filter is used to enforce various URL policies that may be defined in Access Manager. This mode does not require the agent realm to be functional and can therefore be safely disabled. For information about disabling the agent realm, see Disabling the Agent Realm of Policy Agent 2.2 for Apache Tomcat Servlet/JSP Container.


Note –

When the agent filter is in the URL_POLICY mode, the agent does not enforce any applicable J2EE declarative security policies. Such policies along with any calls to J2EE programmatic security API return negative results.


J2EE Agent Filter Mode - ALL

This is the most restrictive mode of the agent filter. In this mode, the filter enforces both J2EE policies and URL policies as defined in Access Manager. This mode of operation requires that the agent realm be configured in the deployment container. When running in the ALL mode, the agent ensures that the security principal is set in the system for every authorized access.

This mode of operation is, with very few exceptions, the preferred mode for deployed production systems.

Enabling Web-Tier Declarative Security in J2EE Agents

Certain applications might require the use of web-tier declarative security that enforces role-based access control over web resources such as Servlets, JSPs, HTML files and any other resource that can be represented as a URI. This type of security is enforced by adding security-constraint elements to the deployed application’s web.xml deployment descriptor.

Typically security-constraint elements are tied with auth-constraint elements that identify the role membership that will be enforced when a request for a protected resource is made by the client browser. The following example illustrates this idea:


<security-constraint>
   <web-resource-collection>
     <web-resource-name>Report Servlet</web-resource-name>
     <url-pattern>/ReportGenServlet</url-pattern>
   </web-resource-collection>
   <auth-constraint>
     <role-name>MANAGER</role-name>
   </auth-constraint>
</security-constraint>

   

This fragment of deployment descriptor can be used to ensure that access to the report generation servlet is allowed only to those users who are members of the role called Manager.

In order for such a construct to work, you must make the necessary modifications in the J2EE agent AMAgent.properties configuration file to ensure it can identify and handle such requests.

ProcedureTo Enable J2EE Agents to Handle Security Constraint Settings

  1. Ensure that a login-config element is specified for the web application that is being protected and that the login-config element has the auth-method set to FORM.

    The supporting form-login-config element is also required.

  2. The form-login-page element of form-login-config should be added as one of the values for the following property in the J2EE agent AMAgent.properties configuration file:

    com.sun.identity.agents.config.login.form

    As an example, consider the following login-config element of a protected application:


    <login-config>
       <auth-method>FORM</auth-method>
       <form-login-config>
          <form-login-page>/jsp/login.jsp</form-login-page>
          <form-error-page>/block.html</form-error-page>
       </form-login-config>
    </login-config>
    
                

    Notice how the form-login-page is specified for the supporting form-login-config element. This value must be set for the following property in the J2EE agent AMAgent.properties configuration file as shown:

    com.sun.identity.agents.config.login.form[0] = /Portal/jsp/login.jsp

    Notice that the value of the form-login-page as specified in the deployment descriptor is not the same as what is specified in the J2EE agent AMAgent.properties configuration file. The difference being that when you enter this value in the configuration file, you must prefix it with the context path for the application on which this form-login-page is going to be used. In this particular example, the context path of the application is “/Portal.”

    Similarly, if you have more than one application deployed that require web-tier declarative security, you must add their respective form-login-pages to the J2EE agent AMAgent.properties configuration file. For example, other entries could be:

    com.sun.identity.agents.config.login.error.uri[1] = /BankApp/SignOn

    com.sun.identity.agents.config.login.error.uri[2] = /ERP/LoginServlet

    Please ensure that each such element added to this list has a unique index entry. Having duplicate index entries can result in the loss of data and consequently result in the malfunction of the application.

    Once you have configured the web application’s deployment descriptor to use the form-login mechanism for web-tier declarative security and have added the full URI of the form-login-page for each such application in the J2EE agent AMAgent.properties configuration file, the web-tier declarative security is enabled for these applications.


    Note –
    • When a protected application is configured for web-tier declarative security handling by the agent, it must be redeployed with a form-login configuration as described in this section. This configuration requires that two application resources be specified in the application’s web.xml deployment descriptor: one for the form-login-page and the other for the form-error-page. Regardless of whether the resource corresponding to the form-login-page exists in the application or not (this depends on how the agent is configured to handle the form-login requests), the resource corresponding to the form-error-page must be present in the application. This resource is directly invoked by the deployment container to indicate authentication failures and, optionally, authorization failures. If the application does not contain a valid form-error-page matching the URI specified in this deployment descriptor, it could result in HTTP 404 errors when the container chooses to display this error page.

    • For applications that do not contain a form-login-page, you can specify any URI as long as that URI does not conflict with any application resource and the matching value has been added to the configuration property com.sun.identity.agents.config.login.form.

    • By default, the agent is configured to intercept all form-login requests and handle them without invoking the actual form-login-page resource as specified in the web.xml of the protected application. Thus, when using a default installation of the agent, the application is not required to have a resource corresponding to the form-login-page element specified in web.xml. This allows for the configuration of web-tier declarative security for applications that were not designed to use the form-login mechanism and instead relied on other login schemes available in J2EE specification. This behavior of the agent can be changed so that it allows the form-login requests to be handled by actual resources that exist within the application by changing the agent configuration properties as applicable. For details on how this can be done, please refer to the section Customizing Agent Response for Form Login.

    • If the agent filter is operating in the URL_POLICY mode, any necessary URL policies to allow access to the form-error-page resource must be created for all users.

    To further customize the behavior of the application when using web-tier declarative security, see Web-Tier Security Details.


Web-Tier Security Details

When the deployment container gets a request for a resource that is protected by the web-tier declarative security-constraint, it must evaluate the credentials of the user against the agent realm to ensure that only authorized requests go through. In order to process such a request, the deployment container requires the user to sign on using the specified form login page as mentioned in the form-login-config element of the web.xml descriptor. Based on the specification of the FORM authentication mechanism, it is required that the user submits a valid user name as j_username and a valid password as j_password to the special URI j_security_check using the HTTP POST method of form submission.

The agent, once configured to support web-tier declarative security for the given application can isolate the request for accessing form-login-page and instead can stream out some data to the client browser. This data contains the user’s login name and temporary encrypted password, which in turn uses Javascript to do automatic form submission as required. This gives the user a seamless single sign-on experience since the user does not have to re-login in order to access the protected resources for a deployed application that uses web-tier declarative security.

By default, the content that the agent sends to the client browser on intercepting a request for the form login page is read from the file called FormLoginContent.txt located in the locale directory of the agent installation. This file contains the following HTML code:


<html>
   <head>
      <title>Security Check</title>
   </head>
   <body onLoad="document.security_check_form.submit()">
      <form name="security_check_form" action="j_security_check" method="POST">
         <input type="hidden" value="am.filter.j_username" name="j_username">
         <input type="hidden" value="am.filter.j_password" name="j_password">
      </form>
   </body>
</html>

      

Before the agent streams out the contents of this file, it replaces all occurrences of the string am.filter.j_username by the appropriate user name. Similarly, all occurrences of the string am.filter.j_password are replaced by a temporary encrypted string that acts as a one-time password for the user.

Customizing Agent Response for Form Login

The J2EE agent AMAgent.properties configuration file allows you to completely control the content that is sent out to the user when the deployment container requires a form login from the user.


Note –

The ability to customize the agent response form login is not a feature whose purpose is to change the form login page nor is the purpose of this feature to bypass the default Access Manager login page.


Using the J2EE agent AMAgent.properties configuration file, you can customize the agent response in the following ways:

ProcedureTo Customize the Agent Response to Form Login

  1. Modify the content of the FormLoginContent.txt file to suit your UI requirements as necessary.

    Ensure that regardless of the modifications you make, the final file submits the j_username and j_password to the action j_security_check via HTTP POST method.

  2. (Conditional) You can specify the name of a different file using the property com.sun.identity.agents.config.login.content.file in the J2EE agent AMAgent.properties configuration file.

    If you specify the file name, you must ensure that it exists within the locale directory of the agent installation.

    If you wish that this file be used from another directory, you can simply specify the full path to this new file.

    Ensure that regardless of the modifications you make, the final file submits the j_username and j_password to the action j_security_check via HTTP POST method.

  3. (Conditional) If you have more than one application and would like to have an application-specific response to the form login requests, instruct the agent to allow the form login request to proceed to the actual form login page.

    This can be done by setting the value of the configuration property as follows:com.sun.identity.agents.config.login.use.internal as false.

    In this situation, you must ensure that the resource that receives this request extracts the am.filter.j_username and am.filter.j_password from the HttpServletRequest as attributes and uses that to ensure that eventually a submit of these values as j_username and j_password is done to the action j_security_check via HTTP POST method.

    The following JSP fragment demonstrates how this can be done:


    <form action="j_security_check" method="POST">
    <%
       String user = (String) request.getAttribute("am.filter.j_username");
       String password = (String) request.getAttribute("am.filter.j_password");
    %>
       <ul>
          <li>Your username for login is: <b><%=user%></b></li>
          <li>Your password for login is: <b><%=password%></b></li>
       </ul>
       <input type=hidden name="j_username" value="<%=user%>">
       <input type=hidden name="j_password" value="<%=password%>">
       <input type="submit" name="submit" value="CONTINUE">
    </form>
    
                   

    This mechanism would therefore allow you to have an application-specific form-login handling mechanism.

Enabling Failover in J2EE Agents

The agent allows basic failover capabilities. This helps you ensure that if the primary Access Manager instance for which the agent has been configured becomes unavailable, the agent will switch to the next Access Manager instance as specified in the J2EE agent AMAgent.properties configuration file. This setup can be achieved by implementing the following steps.

ProcedureTo Enable Failover in J2EE Agents

  1. Provide a list of Access Manager authentication services URLs that may be used by the agent to authenticate users who do not have sufficient credentials to access the protected resources.

    Configure the following property to create the list:

    com.sun.identity.agents.config.login.url

    You may specify more than one login URL as follows:

    com.sun.identity.agents.config.login.url[0] = primary-AM-server

    com.sun.identity.agents.config.login.url[1] = failover-AM-server1

    com.sun.identity.agents.config.login.url[2] = failover-AM-server2

    primary-AM-server

    Represents the URL of the primary Access Manager instance to which users are redirected for authentication.

    failover-AM-server1

    Represents the URL of the Access Manager instance to which users are redirected for authentication if the primary Access Manager instance fails.

    failover-AM-server2

    Represents the URL of the Access Manager instance to which users are redirected for authentication if the primary Access Manager instance fails and the first failover Access Manager instance fails.

    If a URL list is provided to this property, com.sun.identity.agents.config.login.url, the agent first tries to establish a connection to the first server (primary-AM-server) specified in the URL list. If the agent is successful in establishing this connection, it redirects the user to the Access Manager instance for authentication.

  2. (Optional) Turn prioritization on for the failover lists by setting the following property to true:

    com.sun.identity.agents.config.login.url.prioritized

    Note –

    Setting this property to true turns prioritization on for the login URL list and the CDSSO URL list. The two cases shown in this step specifically mention the login URL list. However, this explanation of prioritization is exactly the same for the CDSSO URL list. The final step in this procedure describes how to create the CDSSO URL list in case such a scenario applies to your site's deployment.


    The following cases describe the behavior of the agent in different situations: when you turn on prioritization and when you do not turn on prioritization for the login URL list.

    Case 1: com.sun.identity.agents.config.login.url.prioritized = true

    A value of true means that priority is established for the login URL list described in Step 1. The list was created by configuring the following property:

    com.sun.identity.agents.config.login.url

    Therefore, the first URL on the list, which is abbreviated here as .url[0], has a higher priority than .url[1] and .url[1] has higher priority than.url[2] and so on. If the server (primary-AM-server) specified in this example as the value for .url[0] is running, the agent sends all requests to this server only. However, if primary-AM-server fails, from that point on, subsequent requests are sent to the server (failover-AM-server1) associated with .url[1]. Furthermore, if at some point primary-AM-server comes back, then the subsequent requests from that point on are sent to primary-AM-server, since it takes priority over failover-AM-server1. This mechanism always fails back to the highest priority Access Manager instance among the Access Manager instances that are running at the point in time the agent must redirect requests to an Access Manager instance.

    Case 2: com.sun.identity.agents.config.login.url.prioritized = false

    In this case, no server takes priority over another. Failover occurs in a round-robin fashion. If all the servers are running, the agent sends requests to the server (primary-AM-server) associated with .url[0]. If primary-AM-server goes down then all subsequent requests are sent to the server (failover-AM-server1) associated with .url[1]. The agent keeps sending the requests to failover-AM-server1 unless that server goes down. If failover-AM-server1 does go down then the agent routes all the subsequent requests to the server (failover-AM-server2) associated with .url[2] until it goes down. If it goes down, the agent tries to connect to primary-AM-server once again. Assuming that by then the primary-AM-server is running, all the subsequent requests from then on are sent to primary-AM-server. This is a simple round-robin mechanism without any priority involved.

  3. Provide a list of Access Manager Naming Service URLs that may be used by the agent to get access to the various other service URLs that may be needed to serve the logged on user.

    This can be done by using the following property:

    com.iplanet.am.naming.url

    More than one naming service URL may be specified as a space delimited list of URLs. The following example illustrates this idea:

    com.iplanet.am.naming.url = primary-AM-server failover-AM-server1

  4. (Conditional) If the deployment consists of an agent instance that is on a different domain than multiple Access Manager instances for which you want to enable failover, provide a URL list of the remote Access Manager instances.

    Configure the following property to create the list:

    com.sun.identity.agents.config.cdsso.cdcservlet.url[]

    Specify more than one CDSSO URL in the following manner:

    com.sun.identity.agents.config.cdsso.cdcservlet.url[0] = primary-remoteAM-server

    com.sun.identity.agents.config.cdsso.cdcservlet.url[1] = failover-remoteAM-server1

    com.sun.identity.agents.config.cdsso.cdcservlet.url[2] = failover-remoteAM-server2

Login Attempt Limit in J2EE Agents

When a user tries to access a protected resource without having authenticated with Access Manager Authentication Services, the request is treated as a request with insufficient credentials. The default action taken by the agent when it encounters such a request is to redirect the user to the next available Login URL as configured in the J2EE agent AMAgent.properties configuration file.

Despite the repeated redirects performed by the agent, the user could still be unable to furnish the necessary credentials. In such a case, the agent can be directed to block such a request. This is configured using the Login Attempt Limit configuration property. The configuration property that controls this behavior is as follows:

com.sun.identity.agents.config.login.attempt.limit

If a non-zero positive value is specified for this property in the J2EE agent AMAgent.properties configuration file, the agent will only allow that many attempts before it blocks the access request without the necessary credentials. When set to a value of zero, this feature is disabled.

To guard against potential denial-of-service attacks on your system, enable this feature.

Redirect Attempt Limit in J2EE Agents

The processing of requests by the agent can result in redirects for the client browser. Such redirects can happen when the user has not authenticated with Access Manager Authentication Service, lacks the sufficient credentials necessary to access a protected resource, and a variety of other reasons.

While the agent ensures that only the authenticated and authorized users get access to the protected resources, there is a remote possibility that due to misconfiguration of the system, the client browser may be put into an infinite redirection loop.

The Redirect Attempt Limit configuration property allows you to guard against such potential situations by ensuring that after a given number of consecutive requests from a particular user that result in the same exact redirect, the agent blocks the user request. This blocking of the request is only temporary and is removed the moment the user makes a request that does not result in the same redirect or results in access being granted to the protected resource. The configuration property that controls this feature is:

com.sun.identity.agents.config.redirect.attempt.limit

If a non-zero positive integer is specified as the value of this property, the agent will break the redirection loop after the specified number of requests result in the same redirects. When its value is set to zero, this feature is disabled.

To protect the system from such situations, enable this feature. Furthermore, enabling this feature can help in breaking potential denial of service attacks.

Not-Enforced URI List in J2EE Agents

The J2EE agent AMAgent.properties configuration file allows you to specify a list of URIs that are treated as not-enforced. Access to these resources is always granted by the agent. The configuration property that controls this list is as follows:

com.sun.identity.agents.config.notenforced.uri

It is recommended that if your deployed application has pages that use a bulk of graphics that do not need the agent protection, such content be added to the agent’s not-enforced list to ensure the optimal utilization of the system resources. Following is an example of the entries that you may specify in the not-enforced list:

com.sun.identity.agents.config.notenforced.uri[0] = /images/*

com.sun.identity.agents.config.notenforced.uri[1] = /public/*.html

com.sun.identity.agents.config.notenforced.uri[2] = /registration/*

This enables the agent to focus on enforcing access control only over requests that do not match these given URI patterns. The use of a wildcard (*) is allowed to indicate the presence of one or more characters in the URI pattern being specified.

Inverting the Not-Enforced URI List

In situations where only a small portion of the deployed application needs protection, you can configure the agent to do just that by inverting the not-enforced list. This results in the agent enforcing access control over the entries that are specified in the not-enforced list and allowing access to all other resources on the system. This feature is controlled by the following property:

com.sun.identity.agents.config.notenforced.uri.invert

When you set the value to true for this property, it makes the entries specified in the not-enforced list as enforced entries and the rest of the application resources are treated as not-enforced.


Caution – Caution –

When the not-enforced list is inverted, the number of resources for which the agent will not enforce access control is potentially very large. The use of this feature should therefore be used with extreme caution and only after extensive evaluation of the security requirements of the deployed applications.



Note –

Fetching Attributes in J2EE Agents

Certain applications rely on the presence of user-specific profile information in some form in order to process the user requests appropriately. J2EE agents provide the functionality that can help such applications by making these attributes from the user's profile available in various forms. Policy Agent 2.2 allows the following attribute types to be fetched using the corresponding property from the J2EE agent AMAgent.properties configuration file:

Profile Attributes

com.sun.identity.agents.config.profile.attribute.fetch.mode

Session Attributes

com.sun.identity.agents.config.session.attribute.fetch.mode

Policy Response Attributes

com.sun.identity.agents.config.response.attribute.fetch.mode

The following values are possible for these three properties:

The default value for these properties is NONE, which specifies that that particular attribute type (profile attribute, session attribute, or policy response attribute) is not fetched. The other possible values (HEADER, REQUEST_ATTRIBUTE, or COOKIE) that can be used with these properties specify which method will be used to fetch a given attribute type. For more information, see Methods for Fetching Attributes in J2EE Agents.

Depending upon how these values are set, the agent retrieves the necessary attributes available for the logged on user and makes them available to the application.

The final subsection in this section describes other properties in the J2EE agent AMAgent.properties configuration file that can influence the attribute fetching process, see Common Attribute Fetch Processing Related Properties.

The following subsections provide information about how to set the type of attribute that is fetched.

Fetching Profile Attributes in J2EE Agents

To obtain user-specific information by fetching profile attributes, assign a mode to the profile attribute property and map the profile attributes to be populated under specific names for the currently authenticated user. The following example first demonstrates how to assign the REQUEST_ATTRIBUTE mode for fetching profile attributes and then demonstrates a way to map those attributes:

Assigning a Mode to Profile Attributes

com.sun.identity.agents.config.profile.attribute.fetch.mode = 
REQUEST_ATTRIBUTE

The key is the profile attribute name and the value is the name under which that attribute will be made available.

Mapping Profile Attributes

com.sun.identity.agents.config.profile.attribute.mapping[cn]=CUSTOM-
Common-Name
com.sun.identity.agents.config.profile.attribute.mapping[mail]=CUSTOM-
Email

com.sun.identity.agents.config.profile.attribute.fetch.mode = 
REQUEST_ATTRIBUTE
com.sun.identity.agents.config.profile.attribute.mapping[] =

Fetching Session Attributes in J2EE Agents

To obtain user-specific information by fetching profile attributes, assign a mode to the session attribute property and map the session attributes to be populated under specific names for the currently authenticated user. The following example first demonstrates how to assign the REQUEST_ATTRIBUTE mode for fetching session attributes and then demonstrates a way to map those attributes:

Assigning a Mode to Session Attributes

com.sun.identity.agents.config.session.attribute.fetch.mode = 
REQUEST_ATTRIBUTE

The key is the session attribute name and the value is the name under which that attribute will be made available.

Mapping Session Attributes

com.sun.identity.agents.config.session.attribute.mapping[UserToken]=
CUSTOM-userid

com.sun.identity.agents.config.session.attribute.fetch.mode = 
REQUEST_ATTRIBUTE
com.sun.identity.agents.config.session.attribute.mapping[] =

Fetching Policy Response Attributes in J2EE Agents

To obtain user-specific information by fetching policy response attributes, assign a mode to the policy response attribute property and map the policy response attributes to be populated under specific names for the currently authenticated user. The following example first demonstrates how to assign the REQUEST_ATTRIBUTE mode for fetching policy response attributes and then demonstrates a way to map those attributes:

Assigning a Mode to Policy Response Attributes

com.sun.identity.agents.config.response.attribute.fetch.mode = 
REQUEST_ATTRIBUTE

The key is the policy response attribute name and the value is the name under which that attribute will be made available.

Mapping Policy Response Attributes

com.sun.identity.agents.config.response.attribute.mapping

com.sun.identity.agents.config.response.attribute.fetch.mode = 
REQUEST_ATTRIBUTE
com.sun.identity.agents.config.response.attribute.mapping[] =

Using this property for mapping policy response attributes, you can specify any number of attributes that are required by the protected application. For example, if the application requires the attributes cn and mail, and it expects these attributes to be available under the names COMMON_NAME and EMAIL_ADDR, then your configuration setting would be as follows:

com.sun.identity.agents.config.response.attribute.mapping[cn] = COMMON_NAME

com.sun.identity.agents.config.response.attribute.mapping[mail] = EMAIL_ADDR

Methods for Fetching Attributes in J2EE Agents

The attribute types can be fetched by different methods as follows:

Fetching Attributes as HTTP Headers

When the agent is configured to provide the LDAP attributes as HTTP headers, these attributes can be retrieved using the following methods on the javax.servlet.http.HttpServletRequest interface:

long getDateHeader(java.lang.String name)

java.lang.String getHeader(java.lang.String name)

java.util.Enumeration getHeaderNames()

java.util.Enumeration getHeaders(java.lang.String name)

int getIntHeader(java.lang.String name)

The property that controls the parsing of a date value from an appropriate string as set in the LDAP attribute is the following:

com.sun.identity.agents.config.attribute.date.format

This property defaults to the value EEE, d MMM yyyy hh:mm:ss z and should be changed as necessary.

Multi-valued attributes can be retrieved as an instance of java.util.Enumeration from the following method:

java.util.Enumeration getHeaders(java.lang.String name)

Fetching Attributes as Request Attributes

When the agent is configured to provide the LDAP attributes as request attributes, the agent populates these attribute values into the HttpServletRequest as attributes that can later be used by the application as necessary. These attributes are populated as java.util.Set objects, which must be cast to this type before they can be successfully used.

Fetching Attributes as Cookies

When the agent is configured to provide the LDAP attributes as cookies, the necessary values are set as server specific cookies by the agent with the path specified as “/.”

Multi-valued attributes are set as a single cookie value in a manner that all values of the attribute are concatenated into a single string using a separator character that can be specified by the following configuration entry:

com.sun.identity.agents.config.attribute.cookie.separator

One of the tasks of the application is to parse this value back into the individual values to ensure the correct interpretation of the multi-valued LDAP attributes for the logged on user.

When you are fetching attributes as cookies, also use the cookie reset functionality to ensure that these cookies get cleaned up from the client browser when the client browser’s session expires. For more information, see Using Cookie Reset Functionality in J2EE Agents.

Common Attribute Fetch Processing Related Properties

This section lists the most common configuration properties that are used to influence attribute fetching.

com.sun.identity.agents.config.attribute.cookie.separator

This property allows you to assign a character to be used to separate multiple values of the same attribute when it is being set as a cookie. This property is set in the following manner:


com.sun.identity.agents.config.attribute.cookie.separator = |
com.sun.identity.agents.config.attribute.cookie.encode

This property is a flag that indicates if the value of the attribute should be URL encoded before being set as a cookie. This property is set in the following manner:


com.sun.identity.agents.config.attribute.cookie.encode = true
com.sun.identity.agents.config.attribute.date.format

This property allows you to set the format of date attribute values to be used when the attribute is set to HTTP header. This format is based on the definition as provided in java.text.SimpleDateFormat. This property is set in the following manner:


com.sun.identity.agents.config.attribute.date.format = EEE, d MMM yyyy hh:mm:ss z

Configuring FQDN Handling in J2EE Agents

To ensure appropriate user experience, the use of valid URLs by users to access resources protected by the agent must be enforced. This functionality is controlled by three separate properties:

com.sun.identity.agents.config.fqdn.check.enable

Enables FQDN

com.sun.identity.agents.config.fqdn.default

Stores the default FQDN value

com.sun.identity.agents.config.fqdn.mapping[]

Sets FQDN mapping

The configuration property for the default FQDN provides the necessary information needed by the agent to identify if the user is using a valid URL to access the protected resource. If the agent determines that the incoming request does not have a valid hostname in the URL, it redirects the user to the corresponding URL with a valid hostname. The difference between the redirect URL and the URL originally used by the user is only the hostname, which is now changed by the agent to a fully qualified domain name (FQDN) as per the value specified in this property.

The property FQDN Map provides another way by which the agent can resolve malformed access URLs used by the users and take corrective action. The agent gives precedence to entries defined in this property over the value defined in the default FQDN property. If none of the entries in this property matches the hostname specified in the user request, the agent uses the value specified for default FQDN property to take the necessary corrective action.

The FQDN Map property can be used for creating a mapping for more than one hostname. This can be done when the deployment container protected by this agent can be accessed using more than one hostname. As an example, consider a protected deployment container that can be accessed using the following host names:

In this case, assuming that www.externalhostname.com is the default FQDN, then the FQDN Map can be configured as follows to allow access to the application for users who will use the hostname internalhostname.interndomain.com or the raw IP address, say 192.101.98.45:


com.sun.identity.agents.config.fqdn.mapping [internalhostname.interndomain.com] = 
internalhostname.interndomain.com

com.sun.identity.agents.config.fqdn.mapping [192.101.98.45] = 192.101.98.45

Using Cookie Reset Functionality in J2EE Agents

The agent allows you to reset certain cookies that may be present in the user’s browser session if the user’s Access Manager session has expired. This feature is controlled by the following configuration properties:

com.sun.identity.agents.config.cookie.reset.enable = false
com.sun.identity.agents.config.cookie.reset.name[0] =
com.sun.identity.agents.config.cookie.reset.domain[] =
com.sun.identity.agents.config.cookie.reset.path[] =

The preceding four properties can be used to specify the exact details of the cookie that should be reset by the agent when a protected resource is accessed without a valid session.

The com.sun.identity.agents.config.cookie.reset.name property specifies a list of cookie names that will be reset by the agent when necessary. Each entry in this list can correspond to a maximum of one entry in the com.sun.identity.agents.config.cookie.reset.domain property and the com.sun.identity.agents.config.cookie.reset.path property, both of which are used to define the cookie attributes - the domain on which a particular cookie should be set and the path on which it will be set.

When using this feature, ensure that the correct values of the domain and path are specified for every cookie entry in the cookie list. If these values are inappropriate, the result might be that the cookie is not reset in the client browser.

When a cookie entry does not have an associated domain specified in the domain map, it is handled as a server cookie. Similarly, when a cookie entry does not have a corresponding path entry specified, the anticipated cookie path is “/.”

Enabling Port Check Functionality in J2EE Agents

In situations when Access Manager and the deployment container are installed on the same system but on different ports, certain browsers may not send the HOST header correctly to the agent in situations where there are redirects involved between Access Manager Authentication Service and the agent. In such situations, the agent, relying on the availability of the port number from the deployment container, might misread the port number that the user is trying to access.

When this scenario occurs, it can have a severe impact on the system since the agent now detects a resource access that in reality did not occur and consequently the subsequent redirects as well as any policy evaluations may fail thereby making the protected application inaccessible to the end user.

This situation can be controlled by enabling port check functionality on the agent. This is controlled by the following configuration property:

com.sun.identity.agents.config.port.check.enable

When this property is set to true, the agent verifies the correctness of the port number read from the request against its configuration. The configuration that provides the reference for this checking is set by the following property:

com.sun.identity.agents.config.port.check.setting

This property allows the agent to store a map of various ports and their corresponding protocols. When the agent is installed, this map is populated by the preferred port and protocol of the agent server as specified during the installation. However, if the same agent is protecting more than one HTTP listeners, you must add that information to the map accordingly.

When the agent discovers an invalid port in the request, it takes corrective action by sending some HTML data to break the redirection chain so that the browser can reset its HOST header on the subsequent request. This content is read from the file that resides in the locale directory of agent installation. The name of the file is controlled by the following property:

com.sun.identity.agents.config.port.check.file

This property can also be used to specify the complete path to the file that may be used to achieve this functionality. This file contains special HTML that uses a META-EQUIV REFRESH tag in order to allow the browser to continue automatically when the redirect chain is broken. Along with this HTML, this file must contain the string am.filter.request.url, which is dynamically replaced by the actual request URL by the agent.

You can modify the contents of this file or specify a different file to be used, if necessary, so long as it contains the am.filter.request.url string that the agent can substitute in order to construct the true request URL with the correct port. The contents of this file should be such that it should either allow the user to automatically be sent to this corrected location or let the user click on a link or a button to achieve the same result.