Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The key appeal to the enterprise of purchasing portal products is the standards-based frameworks they provide. The common frameworks across provided by (almost) all vendors include navigation, administration, events, and security. Anyone who has built custom applications without these frameworks knows that what initially seems simple (or at least straightforward) will be wrought with many unforeseen pitfalls that lead to missed milestone dates and/or production nightmares. Assembling all of these frameworks features from scratch almost always results in disaster. Still, some IT shops do build their own frameworks, and a few of those even survive production. For the majority, though, a vendor application makes more sense and has a lower total cost of ownership.
The WebLogic Portal (and many other portal products) provides both a full-featured security framework and the capability to plug in external security solutions. System security is one of the dark arts that transcend all network accessible applications. Here, you will look at the considerations that should be evaluated specific to the WebLogic Portal (WLP) world. Although at a high level, there is very little difference between using out of the box (OOTB) solutions versus plugging in an external solution, at the implementation and maintenance levels there are differences in planning that can easily tip the scales between success and failure.
Application-Level Security
The first level of security, from a user workflow perspective, is accessing the portal application itself. At a minimum, this requires authentication of the user. Whether authorization is necessary or not as a next step depends on your UI design and security architecture. From an implementation and maintenance perspective, it usually is a better choice to run authorization immediately after authentication if authorization is part of your security requirements.
Out of the Box
WLP authenticates users against an embedded LDAP, which is part of the WebLogic Server (WLS) that WLP runs on top of. Once the user is authenticated, application access can be configured or implemented based on your specific requirements. In addition to being a collection of frameworks, WLP is still a web application (embedded within an Enterprise Application) running on an application server. This provides some choices for application-level security approaches.
Figure 1: A portal application (highlighted) is deployed as a web application embedded in an Enterprise application
One approach is to use entitlements (covered in more detail later). Even though authentication will tell your system who the user is, entitlements will determine what that user has access to.
Another approach is the standard web application approach of configuring security in the standard web.xml configuration. If your login page does not need to use any of the portal navigation features and your team is already familiar with this approach, it will serve your security needs very nicely.
If you do need portal features as part of your authentication process, you can still use entitlements or you can use a backing file on a desktop to check that a user is logged in before permitting access.
If your enterprise uses a Single Sign On (SSO) solution, you can use either a backing file or a servlet filter to check header values or SSO cookies to determine whether your user should have access. SSO integration can require some custom development, depending on your security and entitlements model.
Custom
There are multiple levels of customization for authentication. One level is to simply replace the default user store with an existing LDAP. This is by far the easiest customization and one that many enterprises choose because it does not require synchronizing an existing user store with the portal application.
WLS also provides APIs for creating your own custom authentication. This approach is useful when you have multiple firewall levels and want very specific control over what components can reach across boundaries. You also may have requirements that require customization of the user principal object, where having your own authenticator is easier. One example where this was a useful approach was a system where the user id in the data layer was different than the user id used at login. By default, the user principal name value is the login name. With a custom authenticator, we were able to do a one time, secure mapping of the login id to the user id reference by the back-end services, a solution that provided both better security and performance.
Whether you build a custom authenticator from scratch or have purchased a commercial authenticator for some strategic purpose, you can configure the WebLogic Server to use alternate authenticators singly or in combination.
Authorization and Entitlements
I am not going to get into the long semantic debate of what the difference is between authorization and entitlement (or if there is a difference). Because the WebLogic documentation refers more frequently to entitlement than authorization, you will use the term entitlement to describe what a user can and cannot do or access once they have been authenticated.
Out of the Box
Entitlements OOTB are role based and allow you to entitle any portal asset with no coding required. The Portal Administration Tool (PAT) is a very easy to use and understand (if sometimes clunky) web application automatically bundled with any WLP application you create. Within the PAT, you can entitle desktops, books, pages, and portlets both at a library level (applying to all instances of the asset) or at an instance level. The process is simply a matter of selecting the asset you want to entitle at the level you want to entitle it and assigning roles and activities.
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.
Custom
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
Data Security
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.
Custom
Follow all of the standard secure development practices. Always validate submitted inputs both client and server side before passing the values to the back end. Make sure your databases are well secured. If a portlet is calling for sensitive data, it is a good idea to have your back end services check data entitlements as well. Although checking entitlements twice may be a performance hit, it is a worthwhile expense for securing sensitive data.
Conclusion
Security is part of every project plan where authentication is required. What isn’t often planned for is testing the implementation of security. Does it unnecessarily impact usability? Is there a way around it? Is it implemented everywhere it must be? Often these things are covered very thoroughly in a document describing what should be done, but rarely is it verified that it was done. Once you have planned what you need to secure and how you are going to secure it, be sure to also plan on how you will test that the security solutions are implemented properly and function as needed. Then look at it again and see if you missed something. Even the best planned solutions can be improved on once they have been implemented and reviewed.
About the Author
Scott Nelson is a Senior Principal Consultant with well over 10 years of experience designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non-profit organizations, and real estate agencies for use by employees, customers, vendors, franchisees, executive management, and others who use a browser. He also blogs all of the funny emails forwarded to him at Frequently Unasked Questions.
