Arch2Arch > Articles

---

Measuring AquaLogic Enterprise Security Performance

by William Dettelback
03/12/2008

Abstract

An increasingly common scenario among BEA WebLogic Portal (WLP) customers is the use of BEA AquaLogic Enterprise Security (ALES) for personalization and fine-grained entitlements. One concern with substituting WebLogic Portal's built-in entitlements engine with AquaLogic Enterprise Security is performance. This article examines the effect on the performance of a WebLogic Portal application when AquaLogic Enterprise Security is applied to handle Visitor Entitlements.

Using AquaLogic Enterprise Security with WebLogic Portal

WebLogic Portal (WLP) provides a very good solution for managing and enforcing Visitor Entitlements. Visitor Entitlements dictate how the portal is rendered according to each visitor's identity and role assignments. These entitlements are managed as individual rules separate from the actual portal definition. This makes it simple to modify the entitlements as conditions change and new requirements arise. However, WebLogic Portal's built-in entitlements engine works only within the portal domain itself. When entitlements in general are required by other parts of the architecture, WebLogic Portal's implementation cannot be used.

For example, it may be necessary to apply entitlements to specific service endpoints, or selectively apply data redaction to database columns based on a user's identity. To satisfy this need, we need to turn to AquaLogic Enterprise Security (ALES). ALES extends the concept of entitlement policies beyond what is possible with WebLogic Portal alone. ALES can dictate how a WebLogic Portal Desktop should be rendered, and it can determine what should be shown inside a specific portlet (for example, a JSP or PageFlow portlet). ALES provides this ability through centralized management while preserving the ability to enforce these policies locally at the applications themselves. The centralized management is handled by the ALES Administration Server, and each application endpoint is provided with policy decisions via a Security Service Module (SSM). ALES ships with different flavors of SSMs depending on the runtime desired—for WebLogic Portal, we use the WLS-SSM.

Figure 1. WebLogic Portal application using WLS-SSM for Visitor Entitlements

So, how do WebLogic Portal and ALES integrate? At a conceptual level, when a WebLogic Portal application receives a request to view a desktop, WebLogic Portal starts to render the tree of portal resources and uses the Personalization framework to determine whether or not this visitor is allowed to see the resources in the tree. Beneath the Personalization framework is the WebLogic Security Framework, which has providers for Authorization and Role Mapping. By default, WebLogic Portal uses its own providers to do Authorization and Role Mapping; this is configured in the Portal Administration Console.

However, when the WebLogic Portal domain is configured to use the WLS-SSM, we are using the ALES Authorization and Role Mapping providers instead. From the portal application's point of view nothing has changed: All personalization requests are still satisfied by the Personalization framework. However, underneath this framework it is actually the ALES, not WebLogic Portal providers at work. For a single portal desktop request there may be hundreds of calls down to the providers—each one requiring a decision whether or not an object should be rendered. For large-scale portal environments, this can translate to thousands of entitlement decisions every second. It is critical that the latency introduced by ALES is as small as possible.

To help keep this latency small, ALES was designed so that entitlement calls from WebLogic Portal would happen entirely within the same process space. This allows ALES to provide significantly shorter latencies than an out-of-process call to a centralized decision point. Because ALES is configured at the WebLogic domain level, all servers in a single domain can take advantage of ALES in a uniform manner. Each server instance in the domain has in-memory access to the same entitlement policies, eliminating the need for a single centralized decision point for the architecture.

Testing Goals and Configuration

Even with an in-memory entitlement engine, it is important to understand the impact on performance; therefore, the ALES team took the opportunity to run some benchmarks. We chose a simple portal application that was typical of a customer's enterprise Web application. We tried to pick a scenario that was small enough to measure effectively while providing enough complexity to get meaningful results.

We set out to determine two things:

1. What is the additional latency and throughput impact on a WebLogic Portal application when ALES is used for entitlements?
2. What is the maximum achievable throughput and minimum achievable latency we can get with a combined WebLogic Portal/ALES solution?

The testing architecture is shown in Figure 2. ALES Administration Server (PAP) provided policies to two Policy Decision Points (PDPs)—the first being the embedded SSM inside the WLP domain, and the other being a standalone instance of the Web Service SSM (WS-SSM). The WebLogic Portal server ran the test portal application and delegated all portal rendering entitlement decisions to the embedded SSM. The Web Service SSM was used only to authorize the action, resulting in a button push inside a particular portlet. The WebLogic Portal domain was also configured to authenticate users against the shared user store managed by the ALES Administration Server's database instance.

Figure 2. Test environment physical architecture

LoadRunner was used to simulate the user population, and two physical instances were set up, each communicating to the WebLogic Portal server via HTTP.

Sample Application and Policies

The testing application is a fictional financial portal where users perform research, monitor trade blotters, and perform trade transactions. It was intended to serve a wide range of users and therefore required fairly complex entitlement rules across a large population of portal artifacts. The test application was composed of the following structure:

• 1 desktop
• 3 books
• 15 pages (5 per book)
• 150 portlet instances (10 per page, taken from 3 portlet definitions)
• 100 buttons (3 per portlet on specific instances)

One of the portlets also made an out-of-process call to the Web Service SSM to simulate a "Buy" event. The user population was set up as follows:

• 100,000 users, each having 1 attribute (GOLD, SILVER, BRONZE)
• 3 groups, APAC (25,000 users), EMEA (25,000 users), U.S. (50,000 users)
• 50 roles

The ALES policies were established as follows:

• 10 dynamic role assignments based upon user attributes
• 40 static role assignments based upon group membership
• 200 authorization policies spread across the 50 roles (evenly segmenting portal resources according to role)

Test Case

The test case follows a simple scenario of a user working with the portal:

1. User logs in and is authenticated by WebLogic Portal
2. User visits 8 pages
3. On the Trading page, user clicks "Buy" button (causing 3 remote authorization decisions)
4. User logs out

The test case was run in two scenarios: once with ALES enabled for entitlements and once with no entitlements enabled. The number of virtual users was gradually increased from 10 to 70 in increments of 10 every ten minutes. Page response time was measured for each interaction. Each page visit was equivalent to approximately 100 authorization decisions. This broke down as follows:

• EJBs (2)
• .css, JavaScript, images (18)
• Buttons (27)
• Portlet Actions (40)
• Pages (8)
• Books (3)

Notice that we have separate authorization decisions being made for multiple types of Portlet actions ("view," "delete," "minimize," and "maximize"). We have one more authorization happening with each page render. Pressing the "Buy" button made a remote call to the Web Service SSM (WS-SSM) to determine if the user could purchase the security. Note that remote calls to the WS-SSM are broken into two phases; the first is to establish the user context and the second phase is to actually perform the three authorizations. Splitting out the user context into its own call means that we don't have to resend user information (such as attributes) along with each authorization call.

Test Results

The Load Runner graph in Figure 3 shows the overall number of Virtual Users (VUsers) compared to the number of Load Runner "Transactions" as a function of time. As you can see in the graph, the portal application becomes saturated at about 35 VUsers; this is the point at which the transactions per second are no longer climbing.

Figure 3: Load Runner tests showing virtual users compared to transactions as a function of time

The response times also correspond to this saturation point; we can see that after about 30 VUsers, the average latency per page starts to climb quickly:

	Login Page (ms)			General Page (ms)			Trade Auth Page (ms)
# VUsers	No ALES	With ALES	Change	No ALES	With ALES	Change	No ALES	With ALES	Change
10	70	100	30	120	140	20	103	135	33
20	125	160	35	220	240	20	220	245	25
30	145	236	91	265	360	95	265	358	93
40	160	300	140	300	420	120	305	395	90
50	190	372	182	340	520	180	350	500	150
60	210	510	300	370	720	350	378	700	323
70	260	580	320	420	800	380	405	790	385

Comparing the page response times for WebLogic Portal pages with and without ALES, it can be deduced that we have added between 20 to 90 milliseconds of additional latency for the 100 authorization calls per page (or approximately 0.2 to 0.9 ms per authorization call). The timings beyond 30 VUsers are less meaningful since they are mostly measuring the server's inability to keep up with the increasing load.

Each Load Runner "transaction" equated to nine pages. With saturation at slightly over 4 transactions per second we can surmise that we are handling about 38 pages per second. At 100 authorizations per second this gives us a rate of about 3800 authorizations per second at saturation.

Summary

What can we conclude from this study? Because the WLS-SSM operates in the same process space as the portal application, the incremental overhead of so many authorizations means milliseconds of additional latency. We did not have specific saturation data for the Non-ALES use cases, so it isn't clear what the precise overhead of doing entitlements would be compared to simply returning back more HTML markup with each page. What is clear is that keeping 99 percent of the authorization requests in-process meant that, prior to server saturation, ALES was not substantially contributing to the overall portal response time. Even the single out-of-process call to the WS-SSM added only a few tens of milliseconds per page.

Of course, these numbers should be taken only as a suggestion of actual performance. Each application's response times and throughput maximums depend on many factors, notably the actual entitlement policies themselves. But it is instructive to examine even a simple use case such as this to understand how fine-grained entitlements can affect overall user response time and system throughput.

References

• AquaLogic Enterprise Security product documentation
• AquaLogic Enterprise Security product center on Dev2Dev, with articles, blogs, and more
• AquaLogic Enterprise Security page on the BEA corporate site

William Dettelback currently works on the AquaLogic Enterprise Security team. His focus is on customers implementing SOA Security, particularly Authorization and Entitlement solutions.

---