Portal administration tools

 

+
Search Tips   |   Advanced Search

 

  1. Security considerations
  2. Administration portlets overview
  3. The XML configuration interface
  4. The Portal Scripting Interface

 

Security considerations

WebSphere Portal provides a delegation model for administering portal resources, which means that the 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 solutions that are based on WebSphere Portal.

The delegation model is implemented by Portal Access Control (PAC), 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.

 

Administration portlets overview

Portal administrative users can use the administration portlets for the following tasks:

  • Performing administrative tasks and actions on portal resources, depending on the access rights that the administrative user has on those resources. This includes:

    • Configuring individual portal resources.

    • Configuring individual portal resources, together with their dependent resources. For example, this can be pages and the pages derived from them.

  • Giving other users, for example subadministrators, limited access rights on selected portal resources. These subadministrators can then perform administrative tasks to the extent that their access rights allow. As the master administrator, we can widen or limit that extent by modifying the access rights for these users on the portal resources. This way, we can delegate administrative tasks as required.

  • Deploying your own custom developed artefacts, such as portlets, themes, or skins.

We cannot use the administration portlets to perform scripted or automated administration or configuration tasks.

For more information about the administration portlets that are supplied with WebSphere Portal refer to Portal administration portlets.

 

The XML configuration interface

The XML configuration interface works as follows:

  • The XML configuration interface provides a batch processing interface for portal configuration updates. It allows you to export an entire portal configuration or parts of a configuration, for example specific pages, to an XML file. We can then re-create the exported configuration from such a file on another portal.

  • You access the XML configuration interface using a command line tool. This command line client is a small separate program that connects to the server using a HTTP connection. We can therefore use it remotely.

  • Use the XML configuration interface to process portal resources, but not portal actions or tasks.

  • Use the XML configuration interface to process the configuration of portal resources that already exist, for example pages. In this context the XML configuration interface processes derived resources, but it does not automatically create them.

  • The XML configuration interface does not reflect the PAC authorization model with delegated administration. You only need the access permission to use the XML configuration interface. An administrator who works with the XML configuration interface does not need access permission for the portal resources processed by the XML request. (The reason for this is that Portal Access Control gives users access permissions on actions and not on resources.)

Use the XML configuration interface for the following tasks:

  • Exporting, importing, and updating complete or partial portal installations. This can be for the following purposes:

  • Copying parts of a configuration, such as specific pages, from one portal to another.

  • Transferring portal configurations from one installation to another. You do this by exporting and importing the portal configuration. This usage scenario includes the case where you try out a new portal configuration on a test portal for evaluation, and then transfer it to a production portal in a separate step using the portal configuration interface.

  • Creating a portal configuration file by XML export. You do this by an XML export.

  • Installing additional resources on a portal.

  • Performing recurring administration tasks in an automated and reproducible manner.

  • Performing these administrative tasks remotely, that is from another server through an HTTP connection.

The XML configuration interface is also used for release staging, that is for staging a portal from development through test to production.

 

Security:

A user who uses the XML configuration interface to perform administrative tasks only needs the access right on the virtual resource XML_ACCESS. The user does not need access rights on the portal resources that are updated by the XML configuration interface.

Use of the XML configuration interface for the following tasks is limited:

  • Delegating administrative tasks, that is having other administrative users with specific access permissions perform these tasks.

  • Limiting administrative tasks to a particular user or to particular portal resources.

 

The Portal Scripting Interface

The Portal Scripting Interface works as follows:

  • 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 Portal 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 of that resource in the same process, depending on the access rights.

Use the Portal Scripting Interface for the following tasks:

  • Making fine tuned changes to a portal configuration.

  • Transferring configuration updates in a safe and controlled manner, and without disturbing the production portal. For example, this can happen by the following steps:

    1. On a development system, a development team develops configuration updates for the portal, and the script for performing these updates.

    2. After the script has been completed, a test team tests both the script and the new configuration.

    3. After the script and the new configuration have been tested and approved, they can be applied to the production portal.

    4. 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 that are created and updated by the script. Therefore, 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:

  • In WebSphere Portal Version 6.0 we can use the Portal Scripting Interface for administering portal pages only. Portal Scripting Interface does not process any other portal resources.

 

Related information

 

Parent topic:

Administering