Planning WebLogic Portal Security
Figure 2: Entitling Assets in the PAT is Simple
You even can delegate particular assets to be managed by particular roles. For example, if you have an application used by companies that want to manage the entitlements of users within their organizations, you can create an external administrator role that grants entitlements to other users.
You can code for more sophisticated entitlements, such as evaluating a user's profile to determine whether they will be dynamically added to a role. And, if you wish to entitle functionality at the sub-portlet level, you can call APIs that will test for a user's group or role membership to provide customized entitlement at that level using the OOTB framework.
Just because the tools are easy to use does not mean that entitlements based on roles and groups (and sometimes conditions) are easy to define. A balance must be struck between a maintainable collection of groups and roles versus how flexible or restrictive group and role membership needs to be to meet business needs.
WebLogic provides a Service Provider Interface (SPI) for entitlements. As with authentication, you can then create your own entitlements engine or use a vendor application that provides an SPI specific to the version of WLP you are working with. Or, you can build your own SPI to integrate with a vendor that doesn't provide one (or does not provide one that works the way you want it to).
With the exception of AquaLogic Entereprise Security (ALES), an external entitlement engine is generally going to perform slower than the OOTB entitlements engine. This is not meant to disparage alternative vendors. Your enterprise may be moving toward a federated entitlements architecture where having an external engine is the most expedient way to maintain federation. What is important to understand is that WLP has been refining its entitlement engine for many years and has achieved very good performance that is hard to beat by an application that has to do some translating in between. ALES is the exception because the product is owned by the same vendor, giving it a huge edge by over-writing proprietary libraries in a way that external vendors cannot without great integrity risks.
Besides using the entitlement SPI, another way of managing your entitlements in a custom manner is to have a custom authenticator that manages user group membership based on an external entitlements engine. This has much better performance than most SPI approaches. If you are using your own user store, you can achieve federation by having your entitlement engine update the user store rather than over-ride the WLP entitlement engine. Then, you get the best of both custom worlds with the most OOTB functionality leveraged for performance.
The key thing to remember when using the authentication SPI is that only group membership can be assigned programmatically. Because entitlements are role based, you will need to map groups to roles in the PAT or the WLS security console.
Figure 3: Assigning Groups to a Role
This topic is included as a reminder that, no matter how flexible and reliable the framework you are using is, you still need cover the basics. This also is the only topic where both the OOTB and custom approaches can and should be used together.
Out of the Box
There are default user accounts created at the time of installation for development and initial setup purposes. As soon as you have your application installed and functional, it is critical to create new user accounts with strong passwords with the same privileges for administration purposes, and then change the passwords and privileges of the default accounts to secure your portal application. It is also important to review the WebLogic Portal Security Guide that is contained in your installation for the numerous configurations that can expose your application more than you want it to be. The latest version is available at http://e-docs.bea.com/wlp/docs102/security/ at the time of this writing.
Page 2 of 3