Sunil's Notes

Copying Portlet and Portlet Application

One of the common business requirement is ability to copy a Portlet or Portlet application. Ex. Lets say you have a RSS Portlet you want two different instances of that portlet so that user can add either WebSphere RSS Portlet or CNN News Portlet to page, first one pointing to IBM Developerworks WebSphere Section feed and second one pointing to CNN news feed.

The administrator of portal can achieve this by first installing IBM RSS Portlet then go to Manage Portlet or Manage Application portlet and click on Copy. When you copy a Portlet application all portlets in that application gets copied. When you click on Copy portlet you will get a screen like this, here you can set different title for the copied portlet

When you copy a portlet or portlet application the portlet data also gets copied. But after copying the portlet the administrator can change preferences of copy without affecting the original portlet.

One of the common cases for copying portlet is that you want say Virtual Portal specific settings. Ex. Lets say you have company news portlet by default it displays latest news for USA. You want to change it so that in case of Europe the Company News Portlet displays news for Europe. If thats the case make copy of Company News Portlet change preferences to display Europe news and make changes in ACL so that only users from Europe has access to it and also European users do not have access to main Company News Portlet.

About XMLAccess Interface

The XML configuration interface provides a batch processing interface for portal configuration updates. It allows you to export an entire portal confiugration or parts of configuration to XML file. Then you can import this XML file in someother portal server to recreate configuration.

You access the XML configuration interface using a command line tool. This command line client is a small separate program that connects to the portal server using HTTP/HTTPS connection. You can use it for configuring portal remotely.

To be able to use the XML Configuration interface you need to have the manager role on the virtual resource XML_ACCESS and the security administrator role on the virtual resource PORTAL. This implies that you must be a super administrator of the portal who can perform any action. Therefore there is no further access control.

Following types of requests that can be sent to the XML Configuration interface

Export Request: An export request triggers the export of complete or partial portal configuration into XML. It does not modify the configuration of the portal. it results in a response file


<request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
    type="export"
    export-users="false">
</request>

Update request: An update request modifies the configuration of portal according to values found in the XML script.


<request build="wp6014_010_01" type="update" version="6.0.1.4" xsi:noNamespaceSchemaLocation="PortalConfig_6.0.1_2.xsd">
// Configuration that you want to import
</request>

Export orphaned data request: It exports the complete portal configuration into XML including orphaned data.


<request build="wp6014_010_01" type="Export-orphaned-data" version="6.0.1.4" xsi:noNamespaceSchemaLocation="PortalConfig_6.0.1_2.xsd">
</request>

Requets to and response from XML configuration interface use the same XML format. An export request generates an XML response that contains all the configuration data required to re-create the exported configuration part. This means that you can export a portal configuration, save the XML output file and, without modification, send it to another portal to re-create the same configuration there.

Administer the page security

One of the common uses of portal scripting interface is to use it for controlling access control. The Portal Scripting interface provides two different beans that allows you to manipulate the access control.
Lets say you want to modify the access control for "Test Page" page(Unique name for page is testpage). If thats the case then you should follow this procedure

Load the access control object for this page using
```
set acl [$Access getacl Content [$Content find page uniquename testpage]]
```
This will load all the access control information for this is acl object.

Once the access information for a resource is loaded in acl bean then you can decide if you want to either only view the information or edit the information. In our case since we want to edit the page information call
```
$PacList edit $acl
```

In the next step we can actual grant or revoke of the user role.
Ex.
```
$PacList grant User special Authenticated
```
This will assign All authenticated users User role on the page
```
$PacList revoke PrivilegedUser special Authenticated
```
This will remove Privileged Usre role for all authenticated users on this page.
```
$PacList grant Editor name "johndoe"
```
This will assign Editor role to John Doe on this page

Once your done manipulating the access control information then you can commit your changes by calling
```
$PacList done
```
This command would write back your changes in Portal Access Control

Load the access control object for this page using
```
set acl [$Access getacl Content [$Content find page uniquename testpage]]
```
This will load all the access control information for this is acl object.

Once the access information for a resource is loaded in acl bean then you can decide if you want to either only view the information or edit the information. In our case since we want to edit the page information call
```
$PacList edit $acl
```

In the next step we can actual grant or revoke of the user role.
Ex.
```
$PacList grant User special Authenticated
```
This will assign All authenticated users User role on the page
```
$PacList revoke PrivilegedUser special Authenticated
```
This will remove Privileged Usre role for all authenticated users on this page.
```
$PacList grant Editor name "johndoe"
```
This will assign Editor role to John Doe on this page

Once your done manipulating the access control information then you can commit your changes by calling
```
$PacList done
```
This command would write back your changes in Portal Access Control

Portal Scripting Interface Beans

The portal scripting component introduces so-called script beans into the JACL language. These are objects with methods that work on portal data. There is no JACL object that represent particular page or portlet. Rather, there is a fixed number of script beans that provide access to a specific areas of the portal data.

The available beans are

Portal: The Portal bean is used for performing portal level operations such as login and logout. As well as setting the virtual portal for the current session($Portal setvp )

Content: The Content bean allows you to interact with portal content hierarchy(Pages, labels, URLs).It allows you to create,update delete, move pages, labels, urls

Layout: The Layout bean allows you to work with component hierarchy on a page. Component hierarchy contains horizontal and vertical containers, controls

Portlet: The Portlet bean allows you to work with portlet repository which consist of portlets, portlet applications and web modules

Look: The Look bean provides access to the portal theme and skin objects

Access:The Access bean is for reading, writing of the access control objects

PacList: The PacList bean provides operations to view and edit access control objects.

Run scripting command in a profile

A profile is a script that runs before the main script, or before entering interactive mode. Profiles can be used to set up environment specific behavior or user specific data. Profiles are specified when invoking wpscript, using the -profile parameter. For example, the login command can be placed in a profile. The following example of a profile, which can be named mylogin.jacl, would look like this:


set user wpsadmin                                                           
set pwd  wpsadmin                                                              
$Portal login $user $pwd

Then you can execute your jacl script using this command
wpscript.sh -port port_number -profile mylogin.jacl -username wasadmin -password wasadmin -f testme.jacl
As you can see your passing name of your mylogin.jacl as value for -profile command line parameter. So the mylogin.jacl script will get executed before testme.jacl and as a result you dont have to include login command in each of your JACL scripts

Introduction to Portal Scripting Interface

WPS provides a scripting interface that you can use for administering portal from the command line.The portal scripting interface is extension of the WAS Admin Scripting interface.
When you use portal scripting interface unlike the XMLAccess tool, WebSphere Portal is accessed with user identity, not as a "super administrator".

You can use the Portal Scripting interface in two different modes

Interaction mode: Use the interactive mode if you want to interact directly and dynamically with the portal to perform simple administrative tasks that should only be executed once. For example, the administrator wants to modify the permissions of a page for a certain principal, or the administrator wants to add a portlet to a page. Use the interactive mode if you do not intend to repeat the operation. Use these steps to use portal scripting in interactive modes
1. Execute wpscript.sh -port port_number -user admin_userid -password admin_password command. This should open a wsadmin command console
2. Login into portal using $Portal login wpsadmin wpsadmin command
3. Execute whatevery wpsadmin commands you want to execute
4. After you have completed all tasks by the portal scripting interface, close and exit the script processor. All changes that you committed are applied to the portal configuration.

Scripting mode: Use the script mode to apply predefined changes to the configuration of a portal. The wpscript tool executes a JACL script that contains the administrative operations. The scripting client inherits the JACL processor from wsadmin, so an administrator can exploit the JACL scripting language, in order to write re-usable, extendable administration scripts. This mode is typically preferred if reproducible administration tasks are created: For example, the administrator can write a JACL script that produces a complete page subtree, and adds individual page layouts and portlets on each page. Follow these steps to use scripting mode
1. Create a JACL script file containing the administrative commands for the changes that you would like to make
2. Execute this command wpscript.sh -port port_number -f script_file_name.jacl
3. Check the output from the script processor to ensure that no errors occurred during the execution of the script.

Delegated administrative policy

An administrator is a user who is authorized to modify the access control configuration by changing role assignments and creating or deleting role blocks. When you install portal or create new VP, you set an administrator user, who becomes the domain administrator and can admister all the resources in that domain.

WebSphere Portal also supports delegated administration, what that means is Portal Admin can give certain access rights to other user and that user can pass some of his user rights to other administrator. Take a look at this diagram. The wpsadmin is portal administrator, so he can assign say Editor or Privleged User role to Sunil for particular page in Asia Marketing team. He can also delegate administrative rights for Marketing team to Mark and then mark would be able to assign rights to Sunil for particular page or he can pass the Admin rights for pages under Asia Marketing to James and James would be able to assign the appropriate user Rights to Sunil.

WebSphere Portal has delegated administration policy that determines how users are permitted to delegate their privileges to other users or groups. The general policy for creating or deleting role assignment is as follows. A user Mark/marketingadmin can assign a Editor role to Sunil only in one of the following cases are met

Mark has the Administrator@Portal or Security Administrator@Portal role. That means he is the super admin for portal.

Since Mark is not super admin, he can assign Editor Role to sunil on one of the Marketing Portal pages only if all of the following conditions are met
- Mark has the Security Administrator@Markeing Page or Administrator@Marketing Page role
- Mark has atleast Editor@Marketing Page role.
- Mark has the Delegator@Sunil, Security Administrator@Sunil or Administrator@Sunil role. Its better to create asiamarketingusers/marketinguser group and assign admin rights to Mark on that group

So if Mark wants to assign Editor role to Sunil on Asia Marketing Page then he must have Delegator@Sunil + Security_Administrator@Asia Marketing Page + Editor@Asia Marketing Page.

Initial Access Control Settings

When you install portal server, the installation program will ask you for administrative user name. That user will become administrator of the portal. In addition to that the installation program will also create administrative group usually wpsadmins that group will get Administrative role on the portal.

This is set of permissions that portal installation program will assign

Administrative User: Gets unlimited access on all resources

Administrative Group(wpsadmins): Same as that of administrative user

All Authenticated Portal User: Gets User or Privileged User rights on preinstalled portlets and some of the pages that get created as part of install process

Anonymous Portal User: Gets User rights on public pages such as login, selfcare, sitemap,..

Take a look at Initial Access Control Settings for further information on what all rights are assigned to various user/groups during portal install

Virtual Users and Groups

The portal supports predefined virtual users and groups that allow for access control configuration that applies to abstract sets of users. These virtual users and groups are not stored in the user registry. They only exist within the access control context. You cannot change group membership or other attributes of these virtual users and groups

Anonymous Portal User: This virtual user models a portal user who has not yet logged into the portal. Assigning roles to this user on a resource allows access to this resource prior to authentication to the portal server.This is useful for creating public welcome pages. The Anonymous Portal User is not considered to be a member of any group within the portal.On pages and their virtual resource parents CONTENT_NODES and PORTAL, you can only assign the Anonymous Portal User to the User role type

All Authenticated Portal Users: This virtual user group models the set of all users who are known by the portal. After successfully logging in to the portal, users lose the Anonymous Portal User identity and become authenticated members of the All Authenticated Portal Users virtual user group. Roles assigned to this user group allow establishment of permissions that will apply to all authenticated users and thus support setting up the default privileges for authenticated portal access.

All Portal User Groups:This virtual user group contains all non-virtual user groups.