Portal administration tools
Overview
Administration tools...
The portal provides several administration tools for limited purposes. These are documented in the context where they can be used. An example is the SLCheckerTool, which we can use to delete orphaned data.
Administration portlets
Portal administrative users can use the administration portlets for the following tasks:
- Perform administrative tasks and actions on portal resources,
- Give other users access rights on selected portal resources.
- Deploy custom artifacts, such as portlets, themes, or skins.
xmlaccess.sh
xmlaccess.sh is a batch processing interface for exporting exporting and importing the portal configuration.
xmlaccess.sh connects to the server using a HTTP connection, so we can use it remote, over a network. xmlaccess.sh can process portal resources, but cannot execute portal actions or tasks. We can use xmlaccess.sh to process the configuration of portal resources that already exist, for example pages. In this context xmlaccess.sh processes derived resources, but it does not automatically create them. xmlaccess.sh does not reflect the access control authorization model with delegated administration. You only need the access permission to use xmlaccess.sh. An administrator who works with xmlaccess.sh does not need access permission for the portal resources processed by the XML request. (The reason for this is that access control gives users access permissions on actions and not on resources.)
We can use xmlaccess.sh to...
- Transfer or migrate between machines
- Backup portal configurations
- Clone of a portal using the object ID generation mode
A user who uses xmlaccess.sh to perform administrative tasks only needs the access permission on the virtual resource XML_ACCESS. The user does not need access rights on the portal resources that are updated by xmlaccess.sh.
The ReleaseBuilder tool utilizes the portal xmlaccess.sh for staging purposes. For example we can use the ReleaseBuilder to move a portal configuration from a test system to a production system.
Portal Scripting Interface
The Portal Scripting Interface is a command line tool.
The Portal Scripting Interface behaves just like the portal administration portlets. It provides delegated administration in the same manner as the portal administration portlets and access control. To work with Portal Scripting Interface, a user needs access permission on the WebSphere Portal and on the portal resources that the user administers.
It allows implicit derivation during administrative work. This means that when you modify a portal resource, the Portal Scripting Interface creates the derivations on that resource in the same process, depending on the access rights.
We can use the Portal Scripting Interface for the following tasks:
- Making fine tuned changes to a portal configuration.
- Transfer configuration updates in a safe and controlled manner, and without disturbing the production portal.
For example, this can happen by the following steps:
- On a development system, a development team develops configuration updates for the portal, and the script for performing these updates.
- After the script has been completed, a test team tests both the script and the new configuration.
- After the script and the new configuration have been tested and approved, they can be applied to the production portal.
- An operator team processes the scripts that update the production portal.
The Portal Scripting Interface has the following advantages:
- Security: The user IDs and access roles of the involved teams provide separation between the responsibilities for the subtasks:
- The development and test team do not have access rights on the production portal.
- The operator who executes the script needs to have access rights on the resources created and updated by the script. If you limit the access rights for that user as required, the script cannot affect other resources unintentionally.
- Safety and availability of the production portal:
- The scripts can be tested and verified before being put into production.
- Once the scripts are tested and verified, they perform the update in a reliable way. Human errors that might happen when working with the administration portlets are not possible.
- The production portal does not even require an Administration page for performing the update.
- The update can be performed over night without disturbing production.
Use of the Portal Scripting Interface is limited in the following way:
- The Portal Scripting Interface offers only a subset of the functionality of the portal administration portlets. For details refer to the Portal Scripting Interface command reference.
Security considerations
IBM WebSphere Portal provides a flexible delegation model for administering portal resources. This means that a master administrator can delegate administration and configuration work to subadministrators or other users as required in a highly detailed manner.
For example, the master administrator can delegate the responsibility and rights for different administrative tasks to different departments in the same business. These can be departments for developing, deploying, and operating software solutione that are based on WebSphere Portal.
The delegation model is implemented by access control, which works by access control decisions which guard the execution of administrative tasks that manipulate portal resources. Users can only perform a task if they have the access permissions required for that task. Access permissions are implemented as user rights on actions related to portal resources, not on the resources themselves.
The extent to which the portal delegation model and access control is tied in varies between the portal administration tools. Security might therefore influence which tool we use for a given purpose.
Parent: Administering
Related: ReleaseBuilder
Configuration Wizard
Updates using ReleaseBuilder
Command reference for Portal Scripting Interface
Technotes for administration tools