Planning WebLogic Portal Security
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.
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.
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.