Installing an SSM for WebLogic Portal means configuring the appropriate Authorization and Role Mapping providers over the default WebLogic Portal providers. The exact steps can be found in our edocs, but the basic steps are as follows:
The first step is to configure the WebLogic Portal domain to use an ALES SSM instead of the security providers that come preinstalled in the domain. The first step is to install the ALES SSMs. We provide them for Web servers, WebLogic Server (both 9.x and 8.1), POJO applications, and even a standalone SSM that communicates over SOAP.
To use an SSM, you must create an instance of the kind you're interested in. For our purposes, we'll create a WebLogic 9.x SSM (on Windows, Start->Programs->BEA AquaLogic Enterprise Security->Security Service Module->WebLogic 9.x Security Service Module->Create New Instance), which creates a set of files (typically in the \instance directory) for our SSM. We then need to change the Portal domain's startWebLogic.cmd to refer to the security providers in the SSM directory (via some CLASSPATH adjustments) instead of the domain directory.
In Figure 3, we see the configuration of the SSM for our Portal domain (wlprealm) in the ALES Administration Console.
In this console, we configure an ASIAuthorization and ASIRoleMapping provider (these are the ALES-specific providers that come with the product) If we were running on WebLogic Server 8.1, we would be done with our configuration, but since we're on WebLogic Server 9.2, we'll need to put this same information into the WebLogic Server Administration Console (Figure 4).
For this example, we'll store our user identities inside the ALES Administration database itself. We will register an Identity Directory (called aldsp) to hold the users for both the WebLogic Portal realm and the ALDSP realm. As such, we need to make sure we configure the Authentication Provider to use the ALES Administration Database as its source of user identities.
It is also important that we enable support for Identity Attributes on our Identity Directory. This is done in the Authorization Provider MetaDirectory tab. Basically, all we need to do is make sure the MetaDirectory information matches the ALES Administration Database connection information. This way, we can be sure that the SSM knows how to retrieve Identity Attributes during policy evaluation. We will use Identity Attributes to hold information such as what state a financial advisor lives in (see policy #5 above) or the total holding amount for a customer (see policy #2 above).
In this example, we can simply hard code the attribute values themselves, but in a real-world environment, you would set up an attribute retriever to fetch the value from an enterprise source at runtime. Note that the policy doesn't care where the value comes from as long as it's stored in an Identity Attribute; this makes it easy to get policy working in a development environment and add the attribute retriever code later.
Setting up the resources for the portal is fairly straightforward. ALES ships with a set of boilerplate resources and policies that will get you started, and you will find that the majority of the resources concerned with entitlements are found under the node
PORTAL_EAR/wlp/PORTAL_WAR/com_bea_p13n. Figure 6 shows the expanded resource tree for the portal security realm "wlprealm."
Of course, if there are domain-specific resources that you wish to protect with ALES from within your portal, you can specify those as well anywhere in the tree that makes sense. We will see an example of this below when we look at the JSP tag library.
Since WebLogic Portal and ALDSP run in separate domains, it will be necessary to propagate the identity of the authenticated portal visitor to our data services. There are many ways to accomplish this, but the simplest way for PageFlow-based portlets is to use the ALDSP Data Service control, which takes care of it automatically (provided you have two trusted domains configured).
There are two ways to leverage AquaLogic Enterprise Security policies inside our WebLogic Portal application:
Let's look at each of these in turn.
If you are familiar with WebLogic Portal, you might be wondering how this configuration of the ALES SSM affects WebLogic Portal's embedded Entitlements engine. By configuring the SSM, you are effectively replacing the entitlements policy engine with the ALES policy engine. This means that we will be establishing our portal entitlement rules via ALES policy instead of the WebLogic Portal Administration Console. While this might be somewhat unsettling to long-time WebLogic Portal users, in reality not much has changed. WebLogic Portal delegates its entitlement decisions to the Authorization Provider implementation, and all we have done is simply change who makes the decision. Once we put ALES in as the decision maker, a much broader set of policy can be applied during a WebLogic Portal entitlements decision.
A way to better understand this is to consider role mapping. With WebLogic Portal Visitor Roles, it is possible to dynamically associate a portal user with a role. However, these WebLogic Portal Visitor Roles are not available outside the portal. Using ALES Role Mapping instead, you can have a single policy that puts a user into a role (for example, Fund Manager) based on complex logic and attributes. This role mapping policy can then be shared between the WebLogic Portal and ALDSP tiers so that a Fund Manager means the same thing in both runtimes. As you add tiers and runtimes to the application, you can see that there are considerable benefits to centralized policy management.
Let's take a look at the ALES policy for the portal shown above. This desktop is for a financial advisor and is showing the MyCustomers page. Here are the four relevant policies:
Each policy statement is of the form "Grant/Deny, privilege(s), resource(s), subject(s)," followed by some optional constraint expression. We can read the four "grant" policies above as:
Keep in mind that unlike WebLogic Portal entitlements, ALES provides a closed world model. A closed world model means that access to resources are denied by default; you must explicitly define grant policies before they can be accessed. WebLogic Portal, on the other hand, provides an open world model where you can see everything by default unless there is an entitlement policy expressed for it. It makes sense that as a security product, ALES would take a different approach, since the closed world model ensures that any resources you might have missed while defining policy aren't accidentally exposed.
One final word on entitlements with ALES: We are defining only Visitor Entitlements this way. Delegated Administration is still performed using the traditional process via the WebLogic Portal Administration Console.
In policy #4 above, we see that fund managers in the UK cannot have access to the Fund Operations functionality after 4:00 p.m. The way the portal was developed, these Fund Operations controls are actually embedded inside the Fund Management portlet. If they were a stand-alone portlet, we could simply use WebLogic Portal entitlements to restrict access, so we'll need a way to enforce policy inside the portlet itself. Since the Fund Operations controls are exposed as HTML markup, use the following in the portlet code:
<ales:isAccessAllowed resource="/fundoperations" action="view">
<!-- Fund Operations Controls Here -->
We're sorry, fund operations are not available after 4pm.<p/>
//role/UKFundManager ) if hour > 16
Inside our non-JSP portlets, we can make programmatic access to the SSM for authorization decisions via the ALES Java API. This API was designed to be used by existing authorization frameworks across various runtime containers beyond WebLogic Server and may appear somewhat verbose for a simple portlet. A common approach is to establish some utility classes that provide a layer of abstraction around the API if ALES calls will be done in multiple portlets. In a future ALES release we will be providing an Apache Beehive Control that will considerably reduce the amount of code needed to call the SSM inside a Java- or PageFlow-based portlet.
This tutorial has shown that AquaLogic Enterprise Security can establish a common security policy across different tiers in an application—in this case WebLogic Portal and AquaLogic Data Services Platform. When configured in a WebLogic Portal domain, the ALES SSM becomes the entitlements decision maker as well as a general-purpose policy decision point for portlet code. ALES extends the way WebLogic Portal performs entitlements and can be added after a portal application has been built. Making programmatic calls to the SSM from within a portlet can be greatly simplified by using the ALES JSP tag library and provides a way to achieve intra-portlet entitlements.
A second article will show how the AquaLogic Enterprise Security policy is applied to the AquaLogic Data Services Platform tier of our application to completely satisfy the security policies outlined above.
William Dettelback currently works on the AquaLogic Enterprise Security team. His focus is on customers implementing SOA Security, particularly Authorization and Entitlement solutions.