WebSphere Application Server & Liberty

WebSphere Application Server & Liberty

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

When the product don't do what you need. A history about WebSphere Portal migration issues related to security

By Gabriel Aberasturi posted Tue November 29, 2016 09:03 AM

  

 I'm on a team responsible for migrating from WebSphere Portal / Web Content Manager v6.1 to v8.5.5. Without going into details of the entire migration process (perhaps in a specific blog) the main problem we encountered was that there is no process to migrate "directly" from Portal / WCM v6.1 to v8.5.5. In our case, the problem lies in the WCM since the rest of the components (page, portlets,...) have been "migrated" in other ways.
 
  And what is special about the WCM? Since all its contents and components reside in database and the change from version to version introduces changes in databases so there are no "shortcuts". The migration must be done by the "official" procedure.
 
  So for the WCM we have a WebSphere Portal v8 "gateway" to which we migrate all the contents of version 6.1.
 
  And how do we get the contents of v8 to v8.5.5? Version 8.5.5 of the portal introduces an important feature of syndication between different versions of portal

 
  Cross version syndication
  Cross-version syndication is supported between the following releases. Syndication from a newer release to an older release is not supported. Cross-version syndication of the Portal Site Library is also not supported.

  • WebSphere® Portal version 7.0.0.2 with CF26 or higher.
  • WebSphere Portal 8.0.0.1 with CF09 or higher.
  • WebSphere Portal 8.5 or higher.

 

  At this point we have an environment in which we can carry out the migration. When we made the first attempts, the main problem we encountered was the time it took to migrate from version 6.1 to 8 (between 48 and 72 hours !!!) and then we had to syndicate between v8 and v8.5.5 !!! Even so we finally had several portals on v8.5.5 !!!
 
  During the first tests and while the new issues were completed Portal 8.5.5 everything looked very good, but when we started with the "serious" tests the first problems arose, certain users did not see contents.
 
  In the v8 portal we had the correct securitywcm_library_user_access_permisions_03.JPG

but not in v8.5.5

wcm_library_user_access_permisions_02.JPG

and it was when we discovered (Reviewing WebSphere Portal 8.5 Knowledge Center documentation) ...seems that is not possible to syndicate user access permissions during the syndication process. We have the same behavior since version 6.1!!!!


  Creating a syndication relationship by using the Administration view
 

      Changes to only the library name or description are syndicated. Changes to other library properties, such as user access to a library, are not syndicated. If you want the same settings on all your syndicated libraries, you must manually make the same changes to any subscriber libraries.

  Syndication relationships
 
    Some information about a Library is only syndicated the first time syndication occurs and not on subsequent updates and rebuilds. If you change the user access to a library, you must manually make the same changes to any subscriber libraries if you want the same settings on all your syndicated libraries.

 
  Due to the number of libraries (70-90) and different levels of security, both a level of roles and elements, contents, categories, ... reconfiguring security manually is not a very feasible option.
    
  The first question was this "Library user access permissions"
   
  This Thread put us on track, export/import of libraries. 


  Exporting and importing web content libraries
     
  Limitations of exporting and importing a web content library.

  • Saved versions of items are not exported. Only the current version of each item is exported.
  • Children are only exported and imported when the parent is successfully exported and imported.
  • If an item exists on the target server with the same path, name and ID, then the item is overwritten.
  • Library and item level access controls remain unchanged when a library is exported and imported. You need to run the member fixer tool on the imported library to fix references to missing users and groups.
  • You cannot import an item if an item on the target server has the same ID but a different parent than the item that is being imported.
  • Projects are not exported.

   
  By doing tests we have seen that you can export and import from v6.1 to v8.5.5 directly so the following paragraph is true.
 

Importing libraries into different versions
    You can import libraries from a different version of Web Content Manager so long as the version you are importing the library into is later than the version you exported the library from
    

 Four weeks ago I attended the following webcast


  Webcast: Best Practices for Staging to Production in WebSphere Portal 8.5
      

and asked for
 
  "In Portal 8.5 when we export/import a library user access permisions are created. Why when we are syndicating the user access permision are not syndicating between environments? we are having the same behavior since Portal 6.1"
 

  Answer more or less: "Working as design, because between environments the security could be different"
   
  Perfect, but then why when I export/import libraries the security settings are maintained?
   
  What if security is no different between environments? And if you have an authoring and several Rendering environment? Methods like exporting and importing the JCR database work correctly when libraries are in the portal itself (not in Virtual Portals), but what happen when your libraries are in Virtual Portals? the method still valid?
 
  Therefore in our case we have detected a possible improvement of the product. When you sindicate for the first time, ask if you want to replicate library user access permisions. Another option is to be able to export/import only security (part is already done because during a library export/import is done) using a tool like memberFixer or release the API to do programatically.
 
  With everything explained during this post we have open in
 

  IBM RFE Community
  Request for Enhancement (RFE) Community users! Here you have an opportunity to collaborate directly with the IBM product development teams and other product users.
   

  A proposal to enhancement how the user access security is propagate between environments.

 
  Headline: WebContent Mananger Library User Access propagation
  ID: 97843

 

  Please helps us getting this new feature in a near CF of WebSphere Portal voting the proposal, thank you very much!!!! :-)

1 comment
0 views

Permalink

Comments

Thu December 08, 2016 01:48 AM

WCM API

I had a similar issue working for a client a couple of years ago. The workaround was to write an application that used the WCM API to generate an xml file with the permissions for each library and each resource type in the library.  

Then the same application could be installed on the target environment and use the xml as input to recreate the permissions of the original environment.