Sun Java System Access Manager FAQ: Performance and Sizing, Policy, Session Failover

Sun Java System Access Manager and Sun Java System Federation Manager FAQ: Performance and Sizing, Policy, Session Failover and Deployment, and Agents

Performance and Sizing
Policy
Session Failover and Deployment
Agents

Performance and Sizing

Q: Must I precompile every time I restart the Web server?

No. Compile JavaServer Pages (JSP) pages once only unless you have edited them.

Q: Could you elaborate on the size and purging operations for amsessiondb?

The com.iplanet.am.session.maxSessions property in the AMConfig.properties file specifies the maximum number of sessions per instance. The disk requirement for 100,000 sessions is 1 Gbyte. Tune the size setting of your broker in the Java virtual machine accordingly.

Restart the amsessiondb instances in a rolling fashion and ensure that all the Access Manager instances are up and running. Allow the maximum session time between restarts.

For more details, see "Performance Tests With the amsessiondb Client" in the Access Manager Deploying Planning Guide.

Q: When should I recompile: before or after starting the Web server?

After. Each time a Web container receives a request, it recompiles the JSP page if it has not been compiled and runs the servlet generated by the compilation. If you recompile the JSP page after starting the Web server, the Web server skips the first step. For large JSP pages, recompilation by the Web server might take awhile.

For more details, see "Precompiling the Console JSP" in the Access Manager Developer's Guide.

Policy

Q: How do I resolve an authorization failure that results from the clocks of the Access Manager and Policy Agent machines being out of sync?

By configuring the com.sun.identity.policy.client.clockSKew property in the AMConfig.properties file, you can set the allowable time difference between the Access Manager and the 2.2 Policy Agent machines. You should still run the time-syncing service, such as the Network Time Protocol (NTP), and closely synchronize the times. Set clockSkew to handle the minor time difference even if you run NTP.

Here is what the related content in the AMConfig.properties file looks like:

#Property to adjust for time difference between
#policy client machine and policy server:
#In the absence of this property and where agent time differs
#from server time, you would occasionally see incorrect policy decision.
#You would still need to run a time syncing service to keep the time
#on policy server and policy client as close as possible.
#Use this property to adjust for the small time difference
#in spite of running time syncing service:
#clock skew in seconds = agentTime - serverTime
#Leave it commented out on policy server.
#Uncomment the line and set appropriate value on policy client machine
#or the machine running policy agent.
#agent-server clock skew in seconds
#com.sun.identity.policy.client.clockSkew=10

Q: In case of user attribute changes, does Access Manager maintain the caches and notify the Policy Agent?

Because of the persistent searches in Sun Java System Directory Server by Access Manager, irrespective of what plug-ins you configure for the user data store (Access Manager SDK or LDAPv3), Access Manager caches are in sync.

User-profile attributes sent to the Policy Agent, except those sent by the policy's Response Provider plug-in, are not cached by the policy engine. Those sent by the plug-in are cached on the policy server up to the SubjectsResultTtl duration defined in the policy configuration service. Consequently, dynamic response attributes that are sent in a policy response to the client could be out of sync with the user attributes in the directory server—up to the duration specified in the SubjectsResultTtl parameter.

Q: How do I configure the header attributes sent to the application by the Policy Agents on a per-policy basis?

While defining a policy, you can configure Response Providers in the same user interface in which you configure the rules and subjects. If the policy is triggered in the decision-making process, that is, if the subject, rule, and conditions match, the policy includes its response values in the response to the Policy Agent, which then sets the attributes accordingly.

On the side of the Policy Agent, you must enable the setting of response attributes and direct them to the header instead of to the cookie.

Q: How do I protect a resource with a policy that contains two authentication schemes?

Set multiple values in AuthSchemeCondition. Afterwards, the policy applies only if the user has authenticated for all the selected authentication schemes.

Q: How do I obtain the names of all the policies for a particular user?

Use the class com.sun.identity.policy.PolicyEvaluator, which contains the method getProtectedResourcesIgnoreConditions, available only on the Access Manager server. Each ProtectedResource instance encapsulates a resource name and the policies that protect the resource.

For more details, see the documentation on getProtectedResourcesIgnoreConditions.

You can use a similar API, getPolicyDecisionIgnoreSubjects, in the class com.sun.identity.policy.ProxyPolicyEvaluator to locate the policies that apply to another user without looking up that user's SSO Token. Again, this API is available only on the Access Manager server.

For more details, see the documentation on getPolicyDecisionIgnoreSubjects.

Q: In the case of many Web hosts with the same URL, should I make the host name a wild card or create a separate policy for each of the hosts?

Make the host name a wild card.

Q: What is the best practice for managing a large number of production policies, such as when an application changes its URL for redployment? Do I have to update each policy manually?

Iterate the policies, inspect the resource names, programmatically modify the policies, and then save the changes with the com.sun.identity.policy.PolicyManager API. You can use that API on the server or with the server-side SDK.

Q: What is the procedure for migrating an Access Manager server from preproduction to production? In particular, I'd like to migrate the policies.

See the section "Exporting Policies to Other Access Manager instances" in Chapter 1 of the Sun Java System Access Manager 7.1 Administration Guide.

Q: Why are the searches for available subject values not returning any value in the suborganizations?

Most likely, this error occurs because the LDAP Bind Password field in the policy's Configuration Service template in the suborganization is empty. While creating that template, be sure to specify the password and save the template afterwards.

SessionFailover and Deployment

Q: Does the session framework require sticky load-balancing from the Load Balancer in the configuration for session failover?

Sticky load-balancing is not required for the session framework to function. Even if the session request is sent to the wrong server, the built-in routing logic in the framework would ensure that the request arrives at the correct server—a process that's completely transparent to the clients. Note, however, that lack of sticky load-balancing results in extra forwarding and impacts performance.

Q: How does session failover occur for a request?

After authentication, an internal algorithm determines the Access Manager servers (primary, secondary, tertiary, and so forth) for a user session. The Access Manager server on which the user session was created is one of those servers.

If the primary Access Manager server goes down, the server at which the session request landed determines which other server services the request and forwards the request there. Note that if the session request lands on the secondary server, no forwarding occurs. The secondary server then retrieves the user session from sessiondb and services the request. The original server at which the request landed serves as a proxy for the request.

The above process occurs even if the load-balancing cookie is set and the Load Balancer has forwarded the request to the Access Manager server according to the cookie's value.

When the primary Access Manager server is up and running again, it continues to service the requests for the sessions it originated. Concurrently, the secondary server purges the master session, which it retrieved when the primary server was down, through either user- or system-initiated cleanup actions.

Q: How many Java Message Queue broker instances must I install for each Access Manager server and where?

You need not set up a separate Java Message Queue broker instance for each Access Manager instance. Rather, install the broker on the sessiondb server instead of the Access Manager server. Feel free to set up multiple Access Manager instances that talk to the same Java Message Queue broker.

Multiple brokers are required only for high availability among brokers so that when one broker fails, another one can take over. Access Manager randomly selects the Java Message Queue broker with which to communicate in the cluster.

Q: How do I run the amsessiondb client with nohup?

Here is the syntax:

nohup /opt/SUNWam/bin/amsessiondb -a Arguments

For example:

nohup /opt/SUNWam/bin/amsessiondb -a host1:port,host2:port -b /tmp/sessiondb

Q: In the case of multiple Access Manager servers with session failover enabled, what happens if the session validation request lands in a server that does not hold the session?

If multiple Access Manager instances reside behind the Load Balancer, the session always exists on one server instance only. However, session validation can occur from any server instance. If the request hits an instance that does not hold the session, Access Manager forwards the request to the server in which the session was first created.

Q: In a multiserver deployment, can I deploy all Access Manager instances behind a Load Balancer or firewall?

The answers depends on two factors:

What the remote client is
Which version of Policy Agents you are running

Here are the scenarios:

If the client is the Web agent, the hot patches for the agent support this deployment.

You must configure the Web agent and Access Manager appropriately. For Web agents, set the com.sun.am.loadBalancer_enable property to true.
If the client is the J2EE Policy Agent, no support is available.

Q: Can I view the events during session failover?

Yes. First, stop the Access Manager server that originated the session. You can then see the sessions being transferred in the Access Manager Administration Console.

Alternatively, enable the statsinterval and verbose options for amsessiondb in the /bin/amsfo script. Afterwards, Access Manager writes logs to LOG_DIR, as specified in the /lib/amsfo.conf file. For details on the options, see "amsessiondb Script" in the Access Manager Deployment Planning Guide.

In addition, to see the messages in the amSession debug logs, enable debug logs on the Access Manager server.

Q: What are the Java Message Queue store configurations?

Access Manager does not use any persistence mechanism of Java Message Queue, so no store configurations are required.

Q: What are the recommended virtual-machine settings for the Java Message Queue broker?

Set the following:

-vmargs "-Xms256m -Xmx1024m"

For more information on the configurations, see the Sun Java System Message Queue Administration Guide.

Q: What are the tuning options for the amsessiondb client?

We recommend that you leave the default virtual machine settings as is. The default cache size is 8 Mbytes. To optimize performance, change the size to 28 Mbytes, for example:

amsessiondb -a host1:port,host2:port -c 28

Q: What is the difference between deployment of session failover and deployment of multiple Access Manager servers?

Session failover in Access Manager retains the authenticated session state in case of a hardware or software failure of a single server. Failover provides both infrastructure redundancy (no single point of failure) and state redundancy (no information loss in the existing sessions after failure).

Unlike session failover, deployment of multiple Access Manager servers ensures only the continuation of service availability for new sessions.

Q: In the configuration for session failover, what's the relationship among the policy agents, the Load Balancer, and the Access Manager servers behind Load Balancers?

The configuration for Access Manager session failover is actually a Load Balancer with multiple Access Manager servers behind the Load Balancer. From the view of the client, for example, the Policy Agent, the Load Balancer is the sole entry point to the Access Manager server farm. All the failover activities among those servers are transparent to the client.

Q: What does Access Manager support in session failover?

Access Manager 7.x supports the following in session failover:

A common Web container-neutral session failover framework with Java Message Queue (JMQ) and Sleepycat's Berkeley database (BDB) as the default transport and session repository
A command-line script called amsfo for starting and stopping the JMQ broker and BDB client components, as applicable
A script called amsfoconfig for configuring the environment for session failover

Q: Where is the documentation on session failover?

"Implementing Access Manager Session Failover" in the Access Manager Deployment Planning Guide.

Q: Why does Access Manager have its own session failover implementation?

Access Manager 7.x is Web container-neutral, independent of any specific failover capabilities provided by the Web containers. This implementation stemmed from the following factors:

Demand for session failover support for Sun Java System Web Server, one of Access Manager's key deployment platforms that does not support session failover out of the box.
Demand for support for session administration interfaces, that is, the ability for an administrator in the appropriate role to view or terminate active sessions. No application servers offer the interfaces for querying the session repository.
Authentication and session constraints, which enable policy-based creation of sessions. Again, no application servers offer the necessary hooks for querying active sessions and for applying policy rules to them, for example, a maximum of one concurrent session per user.
Resource costs, from the standpoint of support for multiple OS platforms and for future Web containers
Distributed architecture, where the agents and applications developed with Access Manager APIs must proxy for the user's active session when the user accesses the agent or application from a browser and does not interact directly with the application server that hosts the Access Manager server. Typically, an application server's failover relies on the browser being at the other end for such tasks as forwarding the appropriate proprietary cookie to retrieve the session.
Limitations in the Web server or application server's HTTP session, whereby HTTP session objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie that establishes the session, can be the same for different contexts, but the referenced object and the attributes in that object must never be shared between contexts (Web applications) by the application server.

Q: Why did you change the session-failover architecture from High Availability Database (HADB) to Java Message Queue/Berkeley Database (BDB)?

Java Message Queue/BDB offers the following advantages over HADB:

Fewer hardware requirements
Better performance
Fewer configurations
Simpler maintenance

Agents

Q: Can the Policy Agent control a session's idle timeout parameter?

No. In a typical deployment, only Access Manager can change a session's idle timeout parameter.

Q: Can I limit the number of sessions on the Policy Agent?

Yes, you can specify on the Access Manager server a limit on the number of sessions being created. Note that no limit applies for the number of sessions on the Policy Agent, which terminates sessions only when they expire.

Q: When I set the do_sso_only flag to true, the Policy Agent still looks for policies on Access Manager. Can I configure SSO without authorization?

No. Note, however, that the Policy Agent makes a call only if LDAP or response attributes are to be fetched.

Q: If the protected resources reside only on the managed server, must I install the Policy Agent on the BEA WebLogic administration server?

Yes. That's because you must set security parameters on the administration server, from which the managed servers obtain the configurations.

Q: Does Policy Agent 2.2 support nonroot installations?

Yes.

Q: After I've installed the Policy Agent on BEA WebLogic 8.1 SP4, my test application fails. Any suggestions for a resolution?

First, verify that debug is set to message in the AMAgent.properties file, then check the amRealm debug logs to verify that Access Manager is writing to them. If those logs are empty, that means the agent authenticator is not functioning. Without the agent authenticator being called and with the Access Manager realm not being initialized, authentication fails.

As a resolution, verify that the following are set on the Policy Agent container:

Any other authenticator in the security tab is set to be optional.
The agent authenticator is set to be optional for the domain.

Also check that the amauthprovider.jar file exists in the /server/lib/mbeantypes directory. If that file is absent there, reinstall the Policy Agent.

To quickly isolate a test case, reinstall BEA WebLogic 8.1 SP4, the Policy Agent, and the sample application. Follow the instructions in the sample application to create users, roles, and policies. If that application works, you have a baseline in which to isolate the problem.

Q: If Access Manager is in legacy mode, is any Policy Agent 2.2 capability lost?

No. The main difference between legacy mode and realm mode is how configuration data is stored. In legacy mode, it's stored with each of the organizations, which makes for an intrusive setup. In realm mode, the data is centrally stored under ou=services.