Migrate the access control configuration

 

+
Search Tips   |   Advanced Search

 

All Authenticated and All Anonymous Users
Resource types
External_ACL resource
Portal resource
Administrative places, pages, and portlets
Portal V4.1.x administrative resources
Portal 4.2.x administrative resources
Portal 5.0.x administrative resources
Migrate credential vault data

Delete the previous Portal resource entries from Tivoli Access Manager

 

Migrate permissions on All Authenticated and All Anonymous Users

The migration tasks automatically migrate most permissions on user groups but do not migrate permissions on:

  • All Authenticated Users and All Anonymous Users
  • All Authenticated Portal Users

Use the following steps to migrate permissions on these groups.

  1. Use the Portal V4.x ACL portlet or the Portal V5.0.x User and Group Permissions portlet to determine the permissions that principals had on All Authenticated Users and All Anonymous Users.

  2. For a 4.x source server, consult the table in the Plan section to determine which roles correspond to the Portal V4.x permissions.

  3. On the Portal V5.1 system, use the User and Group Permissions portlet, the Resource Permissions portlet, or the XML configuration interface to assign the principals to roles on the appropriate user groups.

 

Migrate resource type permissions from a Portal v4.x source server

In Portal V4.x, principals could have Create and Delegate permissions on resource types. The role-based access control for Portal V5.1 does not provide an exact equivalent for permissions on resource types. Portal V5.1 uses virtual resources instead of resource types.

The following table maps Portal V4.x resource types to Portal V5.1 virtual resources:

Resource Type Virtual Resource
Portlet Applications Portlet Applications

This virtual resource includes all portlets and portlet applications.

Portlets Portlet Applications

This virtual resource includes all portlets and portlet applications.

Pages Pages

This virtual resource includes all pages, labels, and external URLs.

Places Pages

This virtual resource includes all pages, labels, and external URLs.

User Groups User Groups

Portal Portal

External_ACL External Access Control

Resource Collections N/A

Principals with Delegate permission on Portal V4.x resource types should be assigned Security Administrator roles on the appropriate Portal V5.1 virtual resources. The Security Administrator role allows principals to modify the access control configuration for all child resources of the corresponding virtual resource.

Create permissions do not need to be migrated because they are not necessary in Portal V5.1. In Portal V5.1, principals with the Administrator, Manager, Editor, or Privileged User roles on a resource are automatically allowed to create new resources underneath that resource in the resource hierarchy.

Follow these steps to manually migrate permissions on resource types:

  1. Determine which principals had permissions on each resource type in Portal V4.x. Using the Portal V4.x administrative interface to determine permissions on each resource type for all principals is difficult. In the administrative interface, permissions are displayed by principal. In order to determine which principals have which permissions, select each principal individually and determine if they had permissions on a resource type. A quicker alternative is to use the SQL queries that is described here to determine the list of principals.

    1. Run the following SQL commands on Portal 4.x database to determine which principals had permissions on various resource types. These commands do not help you determine which permissions the principals have; as described in step b, still use the ACL portlet to determine exactly which permissions the principals have.

      Portal:

      select name from user_desc where oid in (select subjectid from acl where objecttype=0 and objectid=-1)

      Pages:

      select name from user_desc where oid in (select subjectid from acl where objecttype=3 and objectid=-1)

      Portlet Applications:

      select name from user_desc where oid in (select subjectid from acl where objecttype=15 and objectid=-1)

      Portlets:

      select name from user_desc where oid in (select subjectid from acl where objecttype=2 and objectid=-1)

      User Groups:

      select name from user_desc where oid in (select subjectid from acl where objecttype=4 and objectid=-1)

      Users:

      select name from user_desc where oid in (select subjectid from acl where objecttype=1 and objectid=-1)

      External_ACL:

      select name from user_desc where oid in (select subjectid from acl where objecttype=18 and objectid=-1)

    2. For each set of principals that is returned by the above queries, use the Portal V4.x ACL portlet to determine which principals had the Delegate permission on each resource type.

  2. Consult the preceding table to determine which Portal V5.1 virtual resources correspond to the Portal V4.x resource types.

  3. For each set of principals that had delegate permissions on the resource types, use the Resource Permissions portlet, the User and Groups Permissions portlet, or the XML configuration interface on the Portal V5.0.x system to assign principals to Security Administrator roles on the appropriate virtual resources.

 

Migrate permissions on the External_ACL resource

Users with Manage and Delegate permissions on the External_ACL resource in Portal V4.x were allowed to put resources under the protection of an external security manager such as Tivoli Access Manager. This permission maps to the Security Administrator@External Access Control role in Portal V5.1.

Follow these steps to manually migrate permissions on the External_ACL resource:

  1. On the Portal V4.x system, use the ACL portlet or the XML configuration interface to determine the permissions that principals had on the External_ACL resource.

  2. Consult the preceding resource type mapping table and the role mapping table in the Plan section to determine how the Portal V4.x resource types and permissions correspond to Portal V5.1 virtual resources and roles.

  3. Use the external security manager interface to assign the principals to roles on the External Access Control virtual resource.

 

Migrate permissions on the Portal resource

Principals with Manage permission on the Portal resource in Portal V4.x were allowed to change the access control configuration of the portal. This permission maps to the Security Administrator@Portal role.

Users who had Manage and Delegate permissions on the Portal resource in Portal V4.x can be added to the wpsadmins group in Portal V5.1 to get access to the portal.

Follow these steps to manually migrate permissions on the Portal resource:

  1. On the Portal V4.x system, use the ACL portlet or the XML configuration interface to determine the permissions that principals had on the Portal resource.

  2. Consult the preceding resource type mapping table and the role mapping table in the Plan section to determine how the Portal V4.x resource types and permissions correspond to Portal V5.1 virtual resources and roles.

  3. On the Portal V5.1 system, use the Resource Permissions portlet, the User and Group Permissions portlet, or the XML configuration interface to assign the principals to roles on the Portal virtual resource.

 

Migrate permissions for administrative places, pages, and portlets

Because the administrative places, pages, and portlets have changed in different releases of Portal, permissions on these resources must be manually migrated. The following sections show the mapping between the administrative resources in previous versions of Portal and Portal V5.1.

Follow these steps to migrate permissions on administrative places, pages, and portlets:

  1. On the Portal V4.x system, use the ACL portlet or the XML configuration interface to determine the permissions that principals had administrative resources.

  2. Consult the following tables to determine how the administrative resources in Portal V4.x correspond to Portal V5.1.

  3. On the Portal V5.1 system, use the Resource Permissions portlet, the User and Groups Permissions portlet, or the XML configuration interface to assign principals to roles on the appropriate administrative resources.

 

Migrate permissions on Portal V4.1.x administrative resources

The following table explains how to map administrative resources from Portal V4.1.x to Portal V5.1 in a way that takes advantage of inheritance through the resource hierarchy in Portal V5.1.

Administrative Page Group/Page V5.1 Administrative Page
Work with Pages Page Customizer
Edit Layout and Content inherit from Page Customizer
Manage Places and Pages inherit from Portal User Interface
Set Permissions inherit from Page Customizer
Choose Skins inherit from Page Customizer
Portal Administration Administration
Portlets Portlets
   Install Portlets inherit from Portlets
   Portlet Applications inherit from Portlets
   Manage Portlets inherit from Portlets
   Web Clipping inherit from Portlets
   Manage Web Services N/A
   Web Services N/A
Portal Settings Portal Settings
   Global Settings inherit from Portal Settings
   Themes and Skins inherit from Portal User Interface
   Manage Clients inherit from Portal Settings
   Manage Markups inherit from Portal Settings
   Manage Search Index inherit from Portal Settings
   Enable Tracing inherit from Portal Analysis
Users and Groups Access
   Manage Users inherit from Access
   Manage Groups inherit from Access
Security Access
   Access Control List inherit from Access
   Credential Vault inherit from Access
Portal Content N/A
   Manage Content Organizer N/A
   Content Organizer N/A
N/A Portal User Interface
N/A URL Mapping - inherit from Portal Settings
N/A Custom Unique Names - inherit from Portal Settings
N/A Portal Analysis
N/A Frequent Users - inherit from WebSphere Portal Analysis

The following table shows a one-to-one mapping of the administrative place and page hierarchy from Portal V4.1.x to Portal V5.1. This information is provided for reference only; do not use this table as a guide for migrating permissions on administrative resources. Use the preceding table to help you migrate permissions on administrative resources.

Administrative Page Group/Page V5.1 Administrative Page
Work with Pages Page Customizer
Edit Layout and Content Content
Manage Page Groups and Pages Manage Pages/Properties
Set Permissions Locks
Choose Skins Appearance
Portal Administration Administration
Portlets Portlets
   Install Portlets Install
   Portlet Applications Manage Applications
   Manage Portlets Manage Portlets
   Web Clipping Web Clipping
   Manage Web Services N/A
   Web Services N/A
Portal Settings Portal Settings
   Global Settings Global Settings
   Themes and Skins Themes and Skins
   Manage Clients Supported Markups
   Manage Markups Supported Clients
   Enable Tracing Enable Tracing
Users and Groups Access
   Manage Users Users and Groups
   Manage Groups Users and Groups
Security Access
   Access Control List Resource Permissions and User Group Permissions
   Credential Vault Credential Vault
Portal Content N/A
   Manage Content Organizer N/A
   Content Organizer N/A
N/A Portal User Interface
N/A URL Mapping
N/A Custom Unique Names
N/A Portal Analysis
N/A Frequent Users

Administrative Portlets

The following table maps administrative portlets from Portal V4.1.x to Portal V5.1.

Administrative Portlet V5.1 Administrative Portlet
Edit Layout and Content Content
Manage Page Groups and Pages Manage Pages/Properties
Set Permissions Locks
Choose Skins Appearance
Install Portlet Install Portlet
Manage Portlet Applications Manage Portlet Applications
Manage Portlets Manage Portlets
Web Clipper Web Clipper
Manage Web Services N/A
Web Services N/A
Global Settings Global Settings
Themes and Skins Themes and Skins
Manage Clients Manage Clients
Manage Markups Manage Markups
Enable Tracing Enable Tracing
Manage Users Users and Group
Manage User Groups Users and Group
Access Control List Resource Permissions/User Group Permissions
Credential Vault Credential Vault
Manage Content Organizer PDM
N/A Frequent Users

 

Migrate permissions on Portal 4.2.x administrative resources

The following table explains how to map administrative resources from Portal 4.2.x to Portal V5.1 in a way that takes advantage of inheritance through the resource hierarchy in Portal V5.1.

Administrative Page/Place V5.1 Administrative Page
Work with Pages Page Customizer
Edit My Pages inherit from Page Customizer
Edit Layout inherit from Portal User Interface
Manage Pages and Places inherit from Page Customizer
Set Permissions inherit from Page Customizer
Choose Skins inherit from Page Customizer
Organize Favorites Organize Favorites
Portal Administration Administration
Portlets Portlets
   Install Portlets inherit from Portlets
   Portlet Applications inherit from Portlets
   Manage Portlets inherit from Portlets
   Web Clipping inherit from Portlets
   Manage Web Services N/A
   Web Services N/A
Portal Settings Portal Settings
   Global Settings inherit from Portal Settings
   Themes and Skins inherit from Portal User Interface
   Manage Clients inherit from Portal Settings
   Manage Markups inherit from Portal Settings
   Manage Search Index inherit from Portal Settings
   Enable Tracing inherit from Portal Analysis
Users and Groups Access
   Manage Users inherit from Access
   Manage Groups inherit from Access
Security Access
   Access Control List inherit from Access
   Credential Vault inherit from Access
Portal Content N/A
   Manage Content Organizer N/A
   Content Organizer N/A
N/A Portal User Interface
N/A URL Mapping - inherit from Portal Settings
N/A Custom Unique Names - inherit from Portal Settings
N/A Portal Analysis
N/A Frequent Users - inherit from Portal Analysis

The following table shows a one-to-one mapping of the administrative place and page hierarchy from Portal 4.2.x to Portal V5.1. This information is provided for reference only; do not use this table as a guide for migrating permissions on administrative resources. Use the preceding table to help migrate permissions on administrative resources.

Administrative Page Group/Page V5.1 Administrative Page
Work with Pages Page Customizer
Edit My Pages Content
Edit Layout Content
Manage Places and Pages Manage Pages/Properties
Set Permissions Locks
Choose Skins Appearance
Organize Favorites Organize Favorites
Organize Favorites Administration
Portlets Portlets
   Install portlets Install
   Portlet Applications Manage Applications
   Manage Portlets Manage Portlets
   Web Clipping Web Clipping
   Manage Web Services N/A
   Web Services N/A
Portal Settings Portal Settings
   Global Settings Global Settings
   Themes and Skins Themes and Skins
   Manage Clients Supported Markups
   Manage Markups Supported Clients
   Enable Tracing Enable Tracing
Users and Groups Access
   Manage Users Users and Groups
   Manage Groups Users and Groups
Security Access
   Access Control List Resource Permissions and User Group Permissions
   Credential Vault Credential Vault
Portal Content N/A
   Manage Content Organizer N/A
   Content Organizer N/A
N/A Portal User Interface
N/A URL Mapping
N/A Custom Unique Names
N/A Portal Analysis
N/A Frequent Users

Administrative Portlets

The following table maps administrative portlets from Portal 4.2.x to Portal V5.1.

Administrative Portlet V5.1 Administrative Portlet
Quick Customizer Content
Edit Layout and Content Content
Manage Page Groups and Pages Manage Pages/Properties
Set Permissions Locks
Choose Skins Appearance
Organize Favorites Organize Favorites
Install Portlet Install Portlet
Manage Portlet Applications Manage Portlet Applications
Manage Portlets Manage Portlets
Web Clipper Web Clipper
Manage Web Services N/A
Web Services N/A
Global Settings Global Settings
Themes and Skins Themes and Skins
Manage Clients Manage Clients
Manage Markups Manage Markups
Enable Tracing Enable Tracing
Manage Users Users and Group
Manage User Groups Users and Group
Access Control List Resource Permissions/User Group Permissions
Credential Vault Credential Vault
Manage Content Organizer PDM
N/A Frequent Users

 

Migrate permissions on Portal 5.0.x administrative resources

Administrative resources and Page Hierarchies remained the same between 5.0.x and 5.1. As did the permission types. Therefore, if you have assigned specific permission to any of the below resources, assign the same permissions to the resource in the 5.1 server.

V5.0.x Administrative Page
Page Customizer
Content
Manage Pages/Properties
Locks
Appearance
Administration
Portlets
Install
Manage Applications
Manage Portlets
Web Clipping
Portal Settings
Global Settings
Themes and Skins
Supported Markups
Supported Clients
Enable Tracing
Access
Users and Groups
Resource Permissions and User Group Permissions
Credential Vault
Portal User Interface
URL Mapping
Custom Unique Names
Portal Analysis
Frequent Users

V5.0.x Administrative Portlet
Content
Manage Pages/Properties
Locks
Appearance
Organize Favorites
Install Portlet
Manage Portlet Applications
Manage Portlets
Web Clipper
Global Settings
Themes and Skins
Manage Clients
Manage Markups
Enable Tracing
Users and Group
Resource Permissions/User Group Permissions
Credential Vault
PDM
Frequent Users

 

Migrate credential vault data

The migration process automatically migrates Credential Vault slots and segments with the migrate-credential-slots-segments task. This section assumes that the migrate-credential-slots-segments task has been completed successfully.

Existing credentials are handled differently depending on your environment:

  • Standard Portal Vault: complete the following procedure if you want to migrate existing credentials to the Portal V5.1 system.

  • Third-party vault implementation (Tivoli Access Manager): No additional steps are required. Existing credentials should function in the Portal V5.1 system.

If you decide not to migrate existing credentials, users must provide their credential information the first time a V5.1 portlet attempts to use the data.

Migrate the credentials involves moving two tables, VAULT_DATA and VAULT_RESOURCES from the previous Portal database to the Portal V5.1 database. The table definition has not changed in Portal V5.1, so the data does not need to be changed. There are two ways to move the tables:

  • Back up and restore the tables

  • Use an import and export utility that is provided by the database server

The following example explains how to import and export the tables when DB2 is the database server. Use this example as general guide for your environment. Perform this procedure before any users have accessed the Portal V5.1 system and potentially added additional data to the system.

  1. Export the tables from the previous Portal database.

    1. On the previous Portal database server, start the DB2 Command Line Processor (CLP) (Windows) or the DB2 shell (Unix).

    2. Enter the following commands: 
      db2 connect to <wps4x-db> user <dbuser> using <dbuserpw>
db2 export to C:/temp/vault.data.wp4.ixf of ixf messages C:/temp/vault.data.wp4.msgtxt select * from VAULT_DATA
db2 export to C:/temp/vault.res.wp4.ixf of ixf messages C:/temp/vault/res.wp4.msgtxt select * from VAULT_RESOURCES
db2 disconnect <wps-db>

      where <dbuser> is the database administrator user ID and <dbuserpw> is the password for this user ID

  2. Import the data in the tables to the Portal V5.1 database.

    1. If the Portal V5.1 database server is not the same machine as the previous Portal database server, copy the exported vault.data.wp4.ixf and vault.res.ixf files to the Portal V5.1 database server machine.

    2. On the Portal V5.1 database server, start the DB2 Command Line Processor (CLP) (Windows) or DB2 shell (Unix).

    3. Enter the following commands: 
      db2 connect to <wps5-db> user <dbuser> using <dbuserpw>
db2 import from C:/temp/vault.res.wp4.ixf of ixf modified by indexschema=<dbuser> messages C:/temp/vault/res.wp5.msgtxt insert into VAULT_RESOURCES
db2 import from C:/temp/vault.data.wp4.ixf of ixf modified by indexschema=<dbuser> messages C:/temp/vault/data.wp5.msgtxt insert into VAULT_DATA

      where <dbuser> is the database administrator user ID and <dbuserpw> is the password for this user ID

      Under certain conditions, the import into the VAULT_RESOURCES table might generate errors indicating that a row with the same resource name already exists. Disregard this error. The VAULT_RESOURCES table only defines Resource names for use in the credential vault. If the names already exist, there is no need to redefine them. Here is an example of this type of error: 

      SQL0803N  One or more values in the INSERT statement, UPDATE statement, or 
foreign key update caused by a DELETE statement are not valid because the 
primary key, unique constraint or unique index identified by "1" constrains 
table "DB2ADMIN.VAULT_RESOURCES" from having duplicate rows for those columns. 
SQLSTATE=23505

    4. If the Portal V5.1 system uses a database-only configuration for Member Manager, change the USER_DN values in the VAULT_DATA table using the following SQL scripts. See Member Manager for more information. 
      db2 update VAULT_DATA set USER_DN='uid=<wpsadmin>,o=default organization' where USER_DN='uid=<wpsadmin>,o=root organization'

db2 update VAULT_DATA set USER_DN=left(USER_DN,length(USER_DN)-length(',O=root organization')) where USER_DN='uid=<wpsadmin>,o=default organization'

      where <wpsadmin> is the portal administrator user

    5. Enter the following command: db2 disconnect wps5.

  3. Make sure that the system.dn value in the vaultservice.properties file for Portal V5.1 is set to the same value that was used in the previous Portal system. This dn is used to store system (shared) credentials. If this value is different, the vault will not return the vault data.

 

Delete the previous Portal resource entries from Tivoli Access Manager

If you used Tivoli Access Manager with the previous Portal version, you might need to clean up obsolete resource entries that are left in the Tivoli Access Manager object space. complete this step if you are using the same Tivoli Access Manager system that you used with the previous Portal version. This step is not necessary if you are using different Tivoli Access Manager systems for the previous Portal version and Portal V5.1. Do not perform this step until you are finished using the older version of Portal.

  1. On the previous Portal system, open the externalaccesscontrolservice.properties file and determine the value for <pd_root>.

  2. On the Tivoli Access Manager system, go to the pdadmin command line and enter the following command to delete the object space entries corresponding to the previous Portal version resources: pdadmin> delete objectspace <pd_root>*

  3. On the Tivoli Access Manager system, go to the pdadmin command line and enter the following command to delete the ACLs that were associated with the previous Portal version resources: pdadmin> acl delete <acl_name>.

 

See also

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.