WebSphere

 

Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows

 

Migrate the remaining access control configuration

 

+

Search Tips   |   Advanced Search

 

After successfully migrating your WebSphere Portal Express configuration, complete the required steps to migrate specific access control configurations that are not handled automatically by the migration process.

Migrate the following access control configurations manually:

  1. Migrate permissions on All Authenticated Portal Users and All Portal User Groups group
  2. Migrate permissions on WebSphere Portal Express 5.0.2.x administrative resources
  3. Migrate the Member Manager database using the command line
  4. Migrate credential vault data
Perform the following procedures after completing the steps described in the Using command line scripts or Using the migration wizard section:

  1. Migrating permissions on All Authenticated Portal Users and All Portal User Groups group

    Permissions on User Groups allows principals to perform the following tasks:

    • Edit group information

    • Change group membership

    • Change the access rights of the group members

    Follow this step to migrate permissions on user groups:

    1. On the current WebSphere Portal Express 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. For more information, refer to the portlet helps or The XML configuration interface. Follow these steps to assign the principals to roles on the appropriate user groups using the Resource Permissions portlet:

      1. Log in to portal using an administrator account.

      2. Open the Resource permissions portlet.

      3. Select the Resource type User Groups.

      4. Select the All Authenticated Portal Users option and analyze the existing role assignments on that user group.

      5. Use the Resource permissions portlet to create the same role assignments on the new portal.

      6. Repeat these steps for All Portal User Groups.

  2. Migrating permissions on WebSphere Portal Express 5.0.2.x administrative resources

    Administration portlets in the previous version map to the current version as shown below. Use the Resource Permissions portlet for the resource types Portlet Applications and Portlets on the 5.0.2.x system to analyze the existing role assignments on the Administration Portlets listed in the table and their corresponding Portlet Applications. Then use the Resource Permissions portlet to create the same role assignments for the Version 6.0 Administration Portlets on the new portal." Refer as needed to the instructions in the previous step.

    V5.0.2.x Admin Portlet V6.0 Admin Portlet
    • Manage Pages
    • Themes and Skins

    • Manage Pages
    • Themes and Skins

    • Install
    • Manage Applications
    • Manage Portlets
    • Web Clipping Editor

    • Manage Web Modules
    • Manage Applications
    • Manage Portlets
    • Web Clipping Editor

    • Users and Groups
    • Resource Permissions
    • User and Group Permissions
    • Credential Vault

    • Users and Groups
    • Resource Permissions
    • User and Group Permissions
    • Credential Vault

    • Global Settings
    • URL Mapping
    • Custom Unique Names
    • Supported Markups
    • Supported Clients
    • Search Administration

    • Frequent Users
    • Enable Tracing

    • Frequent Users
    • Enable Tracing

  3. Migrating the Member Manager database using the command line

    1. Follow these steps to migrate a DB2 Member Manager database:

      1. Connect to the previous WebSphere Portal Express database using the following command: 

        db2 connect to DB user db_user using db_password

      2. Use the following command to export the Member Manager tables from your previous database: 

        db2 export to filename.ixf of ixf SELECT * FROM db_user.table

        filename is the name of the ixf file.

        db_user is the name of the database user. table is the name of one of the following Member Manager tables:

        • WMMDBABVAL
        • WMMDBACMPV
        • WMMDBACOMP
        • WMMDBACVAL
        • WMMDBADTYP
        • WMMDBADVAL
        • WMMDBAIVAL
        • WMMDBAMTYP
        • WMMDBARVAL
        • WMMDBASVAL
        • WMMDBATR
        • WMMDBATVAL
        • WMMDBKEYS
        • WMMDBMBR
        • WMMGRPMBR
        • WMMKEYS
        • WMMLAACMPV
        • WMMLAACOMP
        • WMMLAACVAL
        • WMMLAADTYP
        • WMMLAADVAL
        • WMMLAAIVAL
        • WMMLAAMTYP
        • WMMLAARVAL
        • WMMLAASVAL
        • WMMLAATR
        • WMMLAATVAL
        • WMMLAEXTID
        • WMMLAKEYS
        • WMMLAMBR
        • WMMMBR
        • WMMMBRREL
        • WMMUSERREG

        See EXPORT Command for additional information about exporting data from a database.

      3. Optional:

        Use the following command to clean all tables from the current WebSphere Portal Express database if there is no Member Manager data on the database: 

        db2 DELETE FROM db_user.table table

        db_user is the name of the database user.

        table is the name of one of the above listed Member Manager tables.

      4. Use the following command to import the Member Manager tables from your previous database: 

        db2 import from filename.ixf of ixf INSERT INTO db_user.table

        filename is the name of the ixf file.

        Each filename should match the ones that you exported for the same table.

        db_user is the name of the database user. table is the name of one of the following Member Manager tables:

        • WMMDBABVAL
        • WMMDBACMPV
        • WMMDBACOMP
        • WMMDBACVAL
        • WMMDBADTYP
        • WMMDBADVAL
        • WMMDBAIVAL
        • WMMDBAMTYP
        • WMMDBARVAL
        • WMMDBASVAL
        • WMMDBATR
        • WMMDBATVAL
        • WMMDBKEYS
        • WMMDBMBR
        • WMMGRPMBR
        • WMMKEYS
        • WMMLAACMPV
        • WMMLAACOMP
        • WMMLAACVAL
        • WMMLAADTYP
        • WMMLAADVAL
        • WMMLAAIVAL
        • WMMLAAMTYP
        • WMMLAARVAL
        • WMMLAASVAL
        • WMMLAATR
        • WMMLAATVAL
        • WMMLAEXTID
        • WMMLAKEYS
        • WMMLAMBR
        • WMMMBR
        • WMMMBRREL
        • WMMUSERREG

        See IMPORT Command for additional information about exporting data from a database.

    2. Follow these steps to migrate a Cloudscape Member Manager database:

      1. Copy the Cloudscape database from the previous WebSphere Portal Express server to a location on the same machine as your current server.

        If your previous server is on the same machine as your current server, you do not need to do this step; however, you will need to stop the previous server if it is active.

      2. Edit the wpconfig_sourceDb.properties file to point to the previous server's Cloudscape database that you copied to the current server, for example:

        • Windows:

          source.wmm.DbUrl=jdbc:db2j:C:\\migrationcloudscape\\cloudscape\\wpsdb

        • Linux:

          source.wmm.DbUrl=jdbc:db2j:/opt/migrationcloudscape/cloudscape/wpsdb

        • i5/OS:

          source.wmm.DbUrl=jdbc:db2j:/opt/migrationcloudscape/cloudscape/wpsdb

      3. Run the database-transfer-wmm task to migrate/transfer the Member Manager database from the previous server to the current server, for example:

  4. Migrating credential vault data

    When you migrated the WebSphere Portal Express configuration using either the command line script or the wizard, the Credential Vault slots and segments were also migrated. This section assumes that the WebSphere Portal Express migration was successfully completed.

    Complete the following procedure if you want to migrate existing credential secrets to the current WebSphere Portal Express system.

    If you decide not to migrate existing credential secrets, users must provide their credential information the first time a Version 6.0 portlet attempts to use the data.

    The best method for migrating credential vault data is to use the XML Configuration Interface, which requires you to install an interim fix on the current and previous system. Otherwise, you can migrate your credential vault data through SQL and direct database operations.

    1. Migrating credential vault data through the XML Configuration Interface

      Migrating the credential secrets involves using the XML Configuration Interface to export the secrets from the previous WebSphere Portal Express and to import them into the current system.

      As credential secrets hold confidential information, this migration is done as a separate migration step that requires special command line options on the XML Configuration interface as well as changes to the WebSphere Portal Express system configuration for credential secret encryption. The credential export uses encryption to retain confidentiality of the secrets. Use the XML Configuration tool directly on the system where the WebSphere Portal Express server resides to minimize the communication path of the confidential information.

      Use the following steps to migrate credential secrets from the WebSphere Portal Express Default Vault:

      1. Install PK28148 on the previous WebSphere Portal Express system.

        Make sure that PK28148 (Credential Vault import/export through XML Access) has been successfully installed on the previous system.

        PK28148 is already included in WebSphere Portal Express Version 6.0.1.

      2. Change the configuration of the previous system to enable export of encrypted secrets.Add the following information to Credential Vault Service, as described in Setting configuration properties:

        Property key Data type and default value Description
        export.userDN Expected value: user DN string

         

        Default value: none

        		This is the user DN value of the XML Access user that should be allowed to import/export secrets via the XML Configuration interface. This is usually the same user DN string as defined in the same configuration file under the systemcred.dn key. The user needs authority to access the XML Configuration interface and must use the interface during import/export.
        export.cipher Expected value: cipher string

         

        Default value: AES

        		The cipher used during export for encryption. This cipher has to be available via Java JCE in the previous WebSphere Portal Express Server system.
        export.keyLength Expected value: integer

         

        Default value: 128

        		Number of bits used as key length for the cipher.

        Example: 

        export.userDN=uid=wpsadmin,o=default organization export.cipher=AES
export.keyLength=128

        After changing property values in Credential Vault Service, restart the previous server to save the changes.

      3. Export credential secrets from the previous system using the XML Configuration interface.When using the XML command line client for credential export, the command syntax is slightly different than normal command line client use because there are two additional parameters: 

        xmlaccess -user user -password password -url http://myhost:9081/wps/config/ 
-in XML_file -out result_file.xml -credentialexport -passphrase encryptionPassphrase
        The following rules apply to the above parameters:

        1. The options credentialexport and passphrase are mandatory for export or import of encrypted credential secrets during migration.

        2. The options credentialexport and passphrase are optional for all XML Configuration actions that do not export or import encrypted credential secrets during migration.

         

        Additional XML Syntax elements for credential secret migration

        Syntax element Description
        credentialexport A parameter without value that indicates that export of credentials should be enabled
        encryptionPassPhrase The passphrase for the encryption. The minimum length of this string is the number of bits set as export keylength in Credential Vault Service, divided by 8. The passphrase is used to create a key of the specified length for the encryption.

        For more information about the XML command line tool, refer to the XML configuration interface section of the appropriate information center version. For example, if the command line tool is for version 5.0.x, then use the 5.0.x information center.

         

        Sample file ExportVault.xml for version 5.0.x 

        <?xml version="1.0" encoding="UTF-8"?>
<request	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
					xsi:noNamespaceSchemaLocation="PortalConfig_1.2.1.xsd"
					type="export" export-users="true">

		<!-- Sample for exporting the credential vault data. -->
		<portal action="locate">
			<credential-segment action="export" objectid="*"/>
		</portal>
</request>
        The following is an example of how to use the XML configuration interface to export credential secrets: 

        xmlaccess.sh -user wpsadmin -password your_password -url http://portalhost:9081/wps/config/ 
             -in ExportVault.xml -out ExportedCredentialSecrets.xml 
             -credentialexport -passphrase JGD786JHgasdf8a67kjhUIT7sdj7nsh776jasdf786regUFZT756675zufurz

      4. Change the configuration of the current WebSphere Portal Express system to enable import of encrypted secrets.Set the following keys for the Credential Vault Service:

        Property key Data type and default value Description
        export.userDN Expected value: user DN string

         

        Default value: none

        		This is the user DN value of the XML Access user that should be allowed to import/export secrets via the XML Configuration interface. This is usually the same user DN string as defined in the same configuration file under the systemcred.dn key. This user needs authority to use the XML Configuration interface and has to be used during the import/export. Otherwise an import/export of credential secrets is not possible.
        export.enforceSSL Expected value: true or false

         

        Default value: true

        		This field controls if credential import/export must be done via secured HTTP connection (value="true") or if it shall be allowed to import/export credentials also via an unsecured HTTP connection (value="false")

        See Portal service configuration for information on how to make these changes for the Credential Vault Service.

        Restart the portal for your changes to take effect.

      5. Import credential secrets to the current WebSphere Portal Express system using the XML configuration interface.

        Use the XML command line client to import credential secrets into the current system. Because XML contains confidential information, use a secure connection for the import; see The XML configuration command line client and its syntax for information.

        The following is an example of how to use the XML configuration interface to import credential secrets: 

        xmlaccess.sh -user wpsadmin -password your_password -url https://portalhost:9444/wps/config/ 
             -in ExportedCredentialSecrets.xml -out result.xml 
             -credentialexport -passphrase JGD786JHgasdf8a67kjhUIT7sdj7nsh776jasdf786regUFZT756675zufurz 				 -truststore $WASHome/profiles/wp_profile/etc/DummyClientTrustFile.jks -trustpwd WebAS

        Notes:

        • Use the same passphrase used during export

        • The import may fail if the user DN schema has been changed between the previous and the current system or when credentials for users are contained in the xml file that are not present in the current system. In this case, manually remove the obsolete credential entries from the xml file before executing the import

        • You should import credentials using an HTTPS connection; however, if you choose not to, set the export.enforceSSL configuration property to false

      6. Dispose all xml files and copies that hold exported credentials - at minimum, this is the export file from the previous system: ExportedCredentialSecrets.xml.

      7. Delete obsolete shared credentials in the current system.Depending on the version of the previous system, some secrets and shared credential slots are migrated that are obsolete in the current version. Remove these slots using the Credential Vault administrative portlet under Administration>Access>Credential Vault. Select Manage system vault slots and delete the following slots, if applicable:

        • deployment.user

        • wmm.system.id.user

        • deployment.truststore

        • deployment.keystore

    2. Migrating credential vault data through SQL and direct database operations

      Migrating the credential secrets involves moving two tables, VAULT_DATA and VAULT_RESOURCES from the previous WebSphere Portal Express database to the current WebSphere Portal Express database. The table definition has not changed in WebSphere Portal Express Version 6.0, so the data does not need to be changed. Because the database is now split in different database domains, the data also has to be split. Use an import and export utility that is provided by the database server to migrate the data.

      The following example explains how to import and export the tables when DB2 is the database server. Use this example as a general guide for your environment. Perform this procedure before any users have accessed the current WebSphere Portal Express system and potentially added additional data to the system.If migrating from 5.0.2.x: Add the following lines to either the export or the import SQL command to avoid a data type mismatch: 

      CRED_SEGMENT.USER_MAPPED>0=>CRED_SEGMENT.USER_MAPPED='Y'
CRED_SEGMENT.USER_MAPPED=0=>CRED_SEGMENT.USER_MAPPED='N'

      1. Export the tables from the previous WebSphere Portal Express database.

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

        2. Enter the following commands (type each section of text on one line): 

          connect to wpsdb user dbuser using dbuserpw export to C:/temp/vault.res.customization.wp5.ixf of ixf messages C:/temp/vault.res.customization.wp5.msgtxt SELECT DISTINCT 
VAULT_RESOURCES.RESOURCE_NAME FROM VAULT_RESOURCES, CRED_SLOT, CRED_SEGMENT WHERE VAULT_RESOURCES.RESOURCE_NAME = 
CRED_SLOT.RESOURCE_NAME AND CRED_SLOT.SEGMENT_OID = CRED_SEGMENT.OID AND CRED_SEGMENT.USER_MAPPED > 0
export to C:/temp/vault.res.release.wp5.ixf of ixf messages C:/temp/vault.res.release.wp5.msgtxt SELECT DISTINCT 
VAULT_RESOURCES.RESOURCE_NAME FROM VAULT_RESOURCES, CRED_SLOT, CRED_SEGMENT WHERE VAULT_RESOURCES.RESOURCE_NAME = 
CRED_SLOT.RESOURCE_NAME AND CRED_SLOT.SEGMENT_OID = CRED_SEGMENT.OID AND CRED_SEGMENT.USER_MAPPED = 0 

export to C:/temp/vault.data.customization.wp5.ixf of ixf messages C:/temp/vault.data.customization.wp5.msgtxt SELECT VAULT_DATA.RESOURCE_NAME, VAULT_DATA.USER_DN, VAULT_DATA.USERID, VAULT_DATA.PWD, VAULT_DATA.BINARY_DATA FROM CRED_SEGMENT, CRED_SLOT, VAULT_DATA  WHERE VAULT_DATA.RESOURCE_NAME = CRED_SLOT.RESOURCE_NAME AND CRED_SLOT.SEGMENT_OID = CRED_SEGMENT.OID AND CRED_SEGMENT.USER_MAPPED > 0 

export to C:/temp/vault.data.release.wp5.ixf of ixf messages C:/temp/vault.data.release.wp5.msgtxt SELECT  VAULT_DATA.RESOURCE_NAME, VAULT_DATA.USER_DN, VAULT_DATA.USERID, VAULT_DATA.PWD, VAULT_DATA.BINARY_DATA FROM CRED_SEGMENT, CRED_SLOT, VAULT_DATA  WHERE VAULT_DATA.RESOURCE_NAME = CRED_SLOT.RESOURCE_NAME AND CRED_SLOT.SEGMENT_OID = CRED_SEGMENT.OID AND CRED_SEGMENT.USER_MAPPED = 0

disconnect wpsdb

          where wpsdb is the database name of the previous WebSphere Portal Express database, 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 current WebSphere Portal Express database.

        1. If the current WebSphere Portal Express database server is not on the same machine as the previous WebSphere Portal Express database server, copy the exported ixf files to the current WebSphere Portal Express database server machine.

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

        3. Enter the following commands (type each section of text on one line): 

          connect to wpsdb user dbuser using dbuserpw 

import from C:/temp/vault.res.customization.wp5.ixf of ixf modified by indexschema=customization messages C:/temp/vault.res.customization.wp6.msgtxt INSERT INTO CUSTOMIZATION.VAULT_RESOURCES 

import from C:/temp/vault.res.release.wp5.ixf of ixf modified by indexschema=release messages C:/temp/vault.res.release.wp6.msgtxt INSERT INTO RELEASE.VAULT_RESOURCES 

import from C:/temp/vault.data.customization.wp5.ixf of ixf modified by indexschema=customization messages C:/temp/vault.data.customization.wp6.msgtxt INSERT INTO CUSTOMIZATION.VAULT_DATA 

import from C:/temp/vault.data.release.wp5.ixf of ixf modified by indexschema=release messages C:/temp/vault.data.release.wp6.msgtxt INSERT INTO RELEASE.VAULT_DATA

          where wpsdb is the database name of the current WebSphere Portal Express database, 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 and VAULT_DATA tables 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. The same is true for the VAULT_DATA table. Credentials that are already stored in the table must not be redefined. 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 "SCHEMA_NAME.VAULT_RESOURCES or VAULT_DATA" from having duplicate rows for those columns. SQLSTATE=23505

        4. Enter the following commands: 

          select USER_DN, RESOURCE_NAME 
from RELEASE.VAULT_DATA vd1
where EXISTS 
   (SELECT * FROM RELEASE.VAULT_DATA vd2 
    WHERE LOWER(vd1.USER_DN) = LOWER(vd2.USER_DN) 
    and vd1.RESOURCE_NAME = vd2.RESOURCE_NAME
    and vd1.USER_DN < vd2.USER_DN)

          select USER_DN, RESOURCE_NAME 
from CUSTOMIZATION.VAULT_DATA vd1
where EXISTS 
   (SELECT * FROM CUSTOMIZATION.VAULT_DATA vd2 
    WHERE LOWER(vd1.USER_DN) = LOWER(vd2.USER_DN) 
    and vd1.RESOURCE_NAME = vd2.RESOURCE_NAME
    and vd1.USER_DN < vd2.USER_DN)
          Any value returned by these commands shows a potential user DN conflict where a conversion to lower case would not complete successfully. Those entries will have to be reviewed for its matching user DN and the duplicate rows will have to be removed manually. Rerun the above commands until no values are returned.If the above commands do not return any values, enter the following commands to update the user DN fields to the lower case string: 

          UPDATE RELEASE.VAULT_DATA
SET USER_DN = LOWER(USER_DN)

UPDATE CUSTOMIZATION.VAULT_DATA
SET USER_DN = LOWER(USER_DN)

        5. Enter the following command: 

          disconnect wpsdb

          where wpsdb is the database name of the current WebSphere Portal Express database.

      3. Use the method described in Setting configuration properties to make sure that the system.dn value in Credential Vault Service representing the current version of WebSphere Portal Express is set to the same value that was used in the previous WebSphere Portal Express system. This dn is used to store system (shared) credentials. If this value is different, the vault will not return the credential secrets for shared slots.

 

Related information

 

Parent topic:

Migrating

 

Previous topic

Migrating WebSphere Portal Configurations

 

Next topic

Migrating additional components