Background:
WebCenter Portal 11g uses a policy store to maintain your application's security policies and grants those policies to users and groups of the application. By default, the policy store is stored within an XML file located at: [domain directory]/config/fmwconfig/system-jazn-data.xml. WebCenter supports migrating the policy store to an LDAP or database repository. Examples of when the policy store is updated are:
These changes are part of the regular maintenance of a Portal or Spaces application and therefore the policy store needs to be scalable for a production implementation.
To maintain Oracle support, a production-implemented WebCenter Portal 11g policy store must reside in an LDAP or database repository. The migration can be done through the Enterprise Manager application or through the WebLogic Scripting (WLST) command line tool. Details of those steps are covered within Oracle's documentation, which can be found here for the 11.1.1.6 WebCenter Portal implementation:
http://docs.oracle.com/cd/E23943_01/webcenter.1111/e12405/wcadm_security_credstore.htm#BABGJEHC
To migrate the policy store to a database the Open Platform Security Services (OPSS) schema needs to be installed through the Repository Creation Utility (RCU) and the datasource assigned within the WebLogic console. This is the same process that’s used to install the WebCenter schemas during the initial implementation.
Best Practice:
Perform the policy store migration as soon as possible after the initial environment has been verified and before beginning any customizations to the WebCenter Portal application. This will reduce the chance of errors during the migration.
Before the policy store migration make sure to back-up the following files as there is not an automated script to rollback the migration if there are issues:
Rolling back these two files will change the domain back to a file-based policy store.
Issue with client that did not migrate the policy store:
I have recently been assisting a client with their production WebCenter Spaces 11g environment that could no longer create any new spaces. Prior to this error, the client created a new space and noticed that their admin user could no longer access the administrative screens and lost other application and space permissions.
The client's production spaces application was using a file-based policy store and through analysis and backup of the system-jazn-data.xml file we noticed that any increase to this file would trigger the policy store to not load properly. With this client's environment the system-jazn-data.xml file was approximately 2.5MB in size when this issue occurred but we were able to recreate the issue with Oracle's assistance in other environments with varying file sizes. Rather than an exact file size issue it seemed to be an issue on how the application loads this data from the file.
Working with Oracle Support, our next step was to migrate the policy store to the database in our Test environment. We added the OPSS schema through RCU and added the OPSS datasource within our WebLogic console. Using Enterprise Manager we migrated the policy store to the database. We then restarted our domain and logged into our Spaces application. Immediately after login we were redirected to an "Unauthorized" page and the redirect was happening infinitely.
After further analysis it seemed there was a separate issue where the system-jazn-data.xml had duplicate grants within the file. Any duplicate grants actually caused the policy store migration to fail, but no message was sent to the UI of this error. With Oracle Support’s assistance, we manually removed the duplicate grants from the system-jazn-data.xml file and re-performed the database policy store migration. It was successful.
It is still unknown how these duplicate policy store grants were added to the policy store file, but that is why the best practice is to migrate from the file-based policy store to a database or LDAP repository before any customizations (i.e. Spaces or Pages) are added to the application to prevent any issues during the migration.
After the policy store migration we were able to successfully create spaces. We successfully tested creation of 100 spaces in the WebCenter Spaces application. This satisfied the client, and the issue was resolved. We then performed the same policy store migration to a database within the production system and regression tested. We saw the same successful results and were able to create new spaces again.
If you have questions about WebCenter Portal, trust TEAM to answer them. Contact us today.
No Comments Yet
Let us know what you think