The master administrator
The master administrator user ID is created during the initial installation of WebSphere Portal with the role administrator on the portal...
admin@portal
This administrator is also the master administrator of the initial portal installation, and all virtual portals created. This master administrator is created with all necessary access permissions for administering tasks related to the initial portal and the virtual portals. The master administrator has the necessary privileges to run the tasks related to managing virtual portals. Use either the Virtual Portal Manager portlet or the provided ConfigEngine tasks to complete these tasks. For information about these tools, go to Administer virtual portals.
The Virtual Portal Manager portlet is installed as part of the initial portal installation. Use this portlet to create, modify, and delete virtual portals.
The master administrator defines the user population of each virtual portal. To separate the user populations of the virtual portals, the master administrator can either use the User and Group Permissions portlet or they can define realms in the VMM configuration files.
Before creating a virtual portal, we define a group of subadministrators. When creating the virtual portal, a default set of roles and access permissions is assigned to this group. As the master administrator, we can change these default assignments and delegate administration of individual virtual portals to subadministrators. Use the Resource Permissions portlet that is part of the Portal Access Control.
When we create a virtual portal, it is filled with a default set of portal pages and resources. We can further enhance the content of a virtual portal by either of the following ways:
- By the master administrator of the portal installation. For example, use xmlaccess.sh.
- By the subadministrators of the virtual portal. Use the Manage Pages portlet.
For information about the content of a virtual portal, go to Content of a virtual portal.
Typically, only the master administrator should have the access permissions for the following tasks:
- Use the Virtual Portal Manager portlet
- Use xmlaccess.sh to run tasks related to one of the virtual portals
- Install portlets, themes, and skins.
Do not grant the subadministrators of virtual portals the access permissions to run any installation-related tasks, such as installation of portlets or themes. All virtual portals share a common Java virtual machine (JVM). Therefore, it is important to restrict the administration privileges of the virtual portal subadministrators and prevent them from installing their own code artifacts, such as themes or portlets. Unstable or malicious code that is introduced on one virtual portal can destabilize the entire portal installation and all other virtual portals. A flexible way to introduce virtual portal-specific portlets without impacting any other virtual portal is to use web services for remote portlets (WSRP). By using WSRP, we can provide portlets on a remote server and then have the virtual portals consume those portlets so that users can access them remotely. For more information about using WSRP with the portal, go to Use WSRP services.
For more information about Portal Access Control, go to Controlling access. For more information about virtual portal security, go to Portal Access Control with virtual portals.
Parent Virtual portal roles and their capabilitiesRelated concepts:
Content of a virtual portal
Control access
Set resource permissions
WSRP services
xmlaccess.sh
Set user and group permissions
Technotes for virtual portals
Administer virtual portals