One of the most significant sets of enhancements introduced in WebSphere Portal v4.1 can be found in portal administration. The improvements offer portal administrators a wider set of functional capability, improved usability, and a robust delegated administration facility.

Providing this wider functionality are new administrative portlets that have been added to what was previously available. Highlights include portlets for installing and adding other portlets to the portal's registry; portlets for managing users and user groups; an improved portlet for creating and managing access control lists; and portlets for clipping Web pages, publishing Web services, setting portal-wide settings, managing logs, and other common administrative tasks.

As in previous releases, the portal is administered through the portal itself - v4.1 introduces the Portal Administration page group. This page group organizes all the administrative portlets into one convenient access point for administrators. The various portlets are organized into the following categories: Portlets, Portal Settings, Users and Groups, Security, and Portal Content.

A Brief Overview of Administration Portlets
Figure 1 shows the WebSphere Portal v4.1 portal administration (showing the Portal Settings page with the Global Settings portlet active).

Portlets
Install Portlet
The Install Portlet allows you to install a local Web Archive (.war) file, register the new portlet with the current portal's portlet registry, and automatically activate the portlets, making them available for immediate use, all in one step. Use the Access Control portlet after installing new portlets to grant other users permission to use the new portlet resources.

Manage Portlet Applications
This portlet allows you to update, copy, rename, activate/deactivate, uninstall, view details, and configure the existing portlet applications.

Manage Portlets
This portlet provides the means to copy, activate/deactivate, rename, view details, delete, and configure existing portlets in the portal's portlet registry. You can view a list of all installed portlets or use the inline search functionality to search the portal's portlet registry and pinpoint the desired portlet.

Web Clipping
One of the most powerful new portlets is the Web Clipping portlet. This portlet is used to display sections of existing Web pages as portlets. You use the Web Clipping portlet to define a Web clipping. When you define a clipping, you can visually select portions of the page or clip all the text between specific tags. This way, you control precisely what markup is used to create your new portlet. The Web Clipping portlet can also rewrite the links inside the clipped page if you desire, so existing Web pages can be viewed without leaving the portal's own navigation structure. When you finish your Web clipping, a new portlet is created in the portal's registry. Whenever the new portlet is displayed on a portal page, it will retrieve the current version of the Web page and extract and display the specific portion you clipped.

Some sites you clip may require authentication to access the site content. The Web Clipping portlet provides options for no security, basic authentication, or form-based authentication. If the content to be clipped is under security, the administrator defining the clipped portlet must provide the appropriate credentials to access the content, then the appropriate authentication credentials must again be provided by the end user at runtime.

Web Services and Manage Web Services
WebSphere Portal provides extensive support for Web services. Portal administrators can publish and bind remote portlets as Web services, making them dynamically available in the portal's registry and seamlessly available to end users on demand.

Completing the publishing step places an entry for the portlet into the desired UDDI directory. The administrator of another portal can browse the UDDI directory to find previously published portlets and bind them into their local portal. This makes the remote portlet available as if it were locally installed; however, the portlet is actually running on the original portal server that published it.

Portal Settings
Global Settings
In the Global Settings portlet, you can change portlet settings such as the default language, the cache timeout values, and so on.

This version of WebSphere Portal also features settings that control how new user sessions are handled. Users logging in to the portal may wish to automatically return to the last page they viewed before logging off, so there's a setting to retain the state of the last visit. As the administrator, you can also decide what to display when a user tries to access a portlet without authorization. Unauthorized access can be ignored (the portlet is not displayed to the unauthorized user), or the portlet can be replaced by a configurable informative message so the user can take the actions necessary to correct the situation.

Themes and Skins
Themes provide the means for altering the visual aspects of the portal. WebSphere Portal Server uses a combination of JavaServer Page templates, cascading style sheets, and images to define the look and navigational structure of the portal pages. All these elements combine to form a theme. You can use themes to dramatically alter the appearance of the portal by adding your company logo, altering the color scheme, or changing the visual style. Themes are set at the page group level. Skins are basically the decorations rendered around the portlet when it's displayed on a page.

Using the Themes and Skins portlet, you can add, edit, delete, and choose a default theme for the portal. This portlet also provides the means to add, delete, and set a default skin for the portal. WebSphere Portal v4.1 allows any number of skins to be associated with a theme. When a user chooses a theme for a page group, you can control the list of available skins for use in conjunction with the theme.

Manage Clients and Manage Markups
The portal server supports several different markup languages so portlets can render themselves for a variety of desktop and mobile browsers.

Out-of-the-box, the page aggregation subsystem supports several markup languages and recognizes particular browsers and mobile-device user-agent signatures. The framework for supporting markup languages is open and extensible, so it's easy to support additional markups or new devices.

To support new browsers and devices, you add new markups and clients using the corresponding administration portlets. In the Markups portlet, the markup name indicates the folders used to store the page templates and the theme or skin files matching that markup language.

To add a markup, create a new entry specifying the MIME type and character set associated with that Markup. You also need to add all JSP templates associated with supporting a markup, such as new layouts, screens, skins, and stylesheets.

When the portal server receives an HTTP request, it matches the values in the user agent header against known patterns that identify common browsers for desktops, mobile phones, and other devices. Entries for these and other common clients are already set up, but you can add new ones using the Manage Clients portlet.

Manage Search Index
WebSphere Portal provides integrated text search capabilities, including a search portlet, a crawler, and a document indexer. The search service can search the portal's document repository as well as Internet content.

To prepare for searching, the search engine builds a full-text index to search documents stored in the local file system. The index can be compressed, and the size can be controlled for situations in which the index size needs to be limited. Use this portlet for creating, updating, and managing the search index.

Enable Tracing
Administrators can control the tracing and logging activity through the Enable Tracing portlet and also by modifying the configuration properties files of the logging subsystem.

The portal server records user activity in logs that can be processed by IBM Tivoli Web Site Analyzer. Overall usage statistics such as logins and logouts, enrollments, and error conditions are tracked. Portlet and page usage statistics, including portlet actions, number of views, modifications, etc., are also tracked.

Users and Groups
Manage Users
In v4.1 portlets have been added that allow you to manage user and group information without leaving the portal. The Manage Users portlet lets you add users to the portal, edit existing user profiles, delete users, and view user IDs. Search capability has been provided to enable administrators to quickly pinpoint specific users.

Manage User Groups
The Manage User Groups portlet allows you to add user groups, delete user groups, show user group IDs, and manage user group memberships. As with the Manage Users portlet, search capability is also provided.

Security
Access Control
The portal server enforces access control to portal resources, including pages, portlets, page groups, and user groups. After determining the user's identity, the portal server consults locally cached access control lists to determine which pages and portlets a user has permission to access. These access permissions are maintained using the Access Control administration portlet and are stored in the portal's administration database. Use this portlet to grant view, edit, and manage permissions to individual users or groups of users, so they may access specific portal resources such as portlets, pages, or page groups. Users may also delegate the permissions they hold to other users.

Credential Vault
Many portlets need to access remote applications that require some form of user authentication. For accessing applications outside the portal's realm, portal server provides a credential vault service that portlets can use to store user IDs and passwords (or other credentials) for a user login to a remote application. Portlets can use these on behalf of the user to access remote systems and achieve single sign-on authentication capability for portal users. The credential vault supports either local database storage or IBM Tivoli's Access Manager for secure storage and retrieval of credentials.

Portal Content
The portal server includes a Content Organizer portlet that enables portal users to contribute and share documents. The Content Organizer portlet provides a workspace for storing, navigation, viewing, and searching portal documents and other content. The organizer is pre-configured to work with files and Rich Site Summary (RSS) formats. Additional content types, formats, and back-end systems can be integrated easily.

Hints and Tips
Types of Permissions
There are two basic types of permissions that can be set in the Access Control portlet:

1.   Permission on a specific resource (i.e. weather portlet, Joe's Home Page, My Company page group, PortalSubAdmins user group, etc.)

2.   Permission on a resource type (i.e. portlet, page, page group, etc.): Used primarily to define which users and user groups can create new instances of a specific resource type. For example, to allow PortalSubAdmins to create page groups, the portal administrator would need to grant this user group CREATE permission on the resource type Page groups.

Figure 2 shows the CREATE permission granted to the user group PortalSubAdmins for the resource type Page groups.

Delegated Administration
As with any resource within the portal, access to administrative tasks can be controlled and fine-tuned by the portal administrator. The Access Control portlet (found on the Security page within the Portal Administration page group) provides the capability to grant any portal user or user group access to a specific administration portlet. Thus, administrators have the ability to delegate specific administrative tasks to other portal users or user groups in the same manner they give them access to view, edit, or manage more traditional portal resources, such as pages and content portlets.

It's important to note that to complete an administrative task, additional permissions are often required. For example, if a portal administrator wants to give a user group the ability to create users, he or she would need to grant the user group VIEW access to the Manage Users portlet, and to the page and the corresponding page group containing that portlet (such as the Users and Groups page in the Portal Administration page group), and CREATE permission on the Users resource type. VIEW access on the portlet, page, and page group ensures that the user group will see the portlet in their portal view and thus be able to interact with it. CREATE permission tells the portal that this particular user group has the ability to create new instances of the type Users. These permissions can be granted and controlled using the Access Control portlet.

Figure 3 shows the VIEW permission granted on the Manage Users portlet to the user group, PortalSubAdmins.

As a general rule, to modify a resource in the portal a user needs two distinct types of permission - an appropriate level of access to the specific resource and VIEW access to the "tool" or administration portlet to perform the modification. The administration portlets are the tools to manipulate various resources central to the portal's operation, such as users, user groups, content portlets, Web services, global settings, etc.

To fine-tune a user's ability to complete portal administrative tasks, the portal administrator can customize pages for various levels within the organization and reveal only appropriate tasks and portlets. Figure 4 shows an example of a custom page developed for a subadministrator of the portal.

User Groups
The portal server uses group membership information to determine what page groups, pages, and portlets a user is authorized to view and edit. Users can be members of one or more groups, and groups may be nested (contain other groups). Nested groups inherit the access permissions set of their parent(s). A user is allowed access to portal resources when a minimum of VIEW access is granted for that resource to any group the user belongs to. Access rights can also be granted to specific individuals, but most companies find that it's easier to manage the access rights of groups instead.