Troubleshooting Entitlements in WebLogic Portal
Applies to:
Oracle WebLogic Portal - Version: 9.2.0 to 10.3.0 - Release: Weblogic Platform to AS10gR3
Information in this document applies to any platform.
Troubleshooting Entitlements, WLP
Purpose
* Causes of Entitlement problems
o Resetting DB without resetting LDAP
o Resetting LDAP without resetting DB
o Updates without running Admin server
o LDAP replication errors
* Symptoms of Entitlement problems
o Missing Roles
o Missing Entitlements
o Entitlements not properly granting access
o PAT errors when viewing or editing Entitlements
* How to get from Symptom to Cause
o Enable Debug output
o Policy Checker tool
o LDAP Browser tool
* How to resolve cause
o Backup to clean state
o Reset LDAP and DB
Last Review Date
March 1, 2010
Instructions for the Reader
A Troubleshooting Guide is provided to assist in debugging a specific issue. When possible, diagnostic tools are included in the document to assist in troubleshooting.
Troubleshooting Details
Introduction:
As covered in Entitlement Internals Note 1068721.1, entitlements define access privileges to Portal resources, which comprised of roles, role policies, security policies. It is stored in both database tables and LDAP. Please note that this has been redesigned for WLP 10.3.2 where all policies and roles haven been completely moved to the database.
Causes to Entitlement Problems
* Resetting the database
o Resetting the database tables or changing to a new database schema without also resetting the internal embedded LDAP store
* Resetting LDAP
o Resetting the internal LDAP store without also resetting the database tables
* Updates while Admin Server is not running
o Updating Entitlement or Delegated Administration (DA) data via the Portal Admin Tool (PAT) without a running Admin Server
o Propagation without a running Admin Server
o Other scenarios like deleting Role when Admin Server down results in LDAP and DB out of sync issue. It is dealt as part of an unpublished bug 8114402.
* WLS/WLP LDAP replication errors
o In a cluster, each server has its own embedded LDAP store. These LDAP instances can get out of sync with each other and with the DB.
o As part of an unpublished bug 8092191, it was found that managed server update fails resulting in LDAP out-of-sync with Admin LDAP and DB
* Other Bugs
o Unpublished bug 8135022 - Long description for Role causes loss of Role in database, which caused LDAP and DB out-of-sync.
o Unpublished bug 8115204 - Race condition when creating Roles leads to LDAP out-of-sync with database.
Symptoms of Entitlement problems
* Missing roles seen in PAT at Visitor Entitlements tab
* Missing entitlements for resources - seen in PAT at a resource's Entitlements tab
* Entitlements not properly granting access
* NullPointerException when viewing roles
o PAT display error when viewing a Role's Details tab
* Error when editing entitlements
o "Error: Could not remove policy" when editing entitlement capabilities
* Error creating entitlement -
o "Error: Could not create policy" when adding role at Entitlements tab
Symptom to Cause
* Enable debug output
* Policy Checker tool
* LDAP Browser tool
Debug Output:
You can enable debug output to display additional information about security policy processing to troubleshoot the entitlement related issues. You need to enable debug output for WLP Entitlement classes 'com.bea.p13n.entitlements' package. It produces additional output in the log that can be helpful for diagnosing Entitlement behavior.
Please refer the documentation link on how to enable debug output. In your directory, create a text file called 'debug.properties', add the name of class(es) and/or package(s) followed by ': on'. When using package names, ensure you use the option 'usePackageNames: on'
For example, to enable Debug for WLP Entitlements' package add the following two lines in your 'debug.properties' file and restart the server.
usePackageNames: on
com.bea.p13n.entitlements: on
Note that not all debug output is useful or desirable. You can minimize clutter by enabling debug for a specific class (or classes) in the com.bea.p13n .entitlements package. One useful class is 'com.bea.p13n.entitlements.Authorization', which handles security policy checking via its isAccessAllowed() method. Enable debug on a specific class by editing debug.properties and adding the class name, for example 'com.bea.p13n.entitlements.Authorization: on' instead of enabling debug for the entire package.
Please avoid adding the entire package for entitlement like 'com.bea.p13n.entitlements: on'.
The sample debug output:
[com.bea.p13n.entitlements.management.internal.SecurityHelper.getAuthenticatedSubject():290] return auth subject:principals=[weblogic, Administrators]
All Debug lines start with the fully qualified name of the WebLogic class that produced the output including the specific line number within the class. The information following the brackets is the output produced by the debug statement in the code.
Policy Checker tool:
Policy checker tool is WLP supported utility used to verify that LDAP and DB data are in sync or not. It is a JSP file, which performs the following checks, and prints a report of all roles and security policies. It also flags any discrepancy between LDAP and DB data.
* Lookup Visitor Roles, Role Policies, and Security Policies in LDAP and verify corresponding policies in database
* Lookup Visitor Roles, Role Policies, and Security Policies in database and verify corresponding policies in LDAP
* Also checks DA roles and policies
To run the Policy Checker Tool
* Please download the policy cheker tool and unzip it.
* Edit webApp/jsp/PolicyChecker.jsp
o Update the app name and webapp name to point to your application and web application
+ At Line 9 --> appName="portalApp"; //change value to app to check
+ At Line 10 --> webName="groupspace"; // change value to webapp to check
* Save the PolicyCheckerApp as a Web Application Archive (.war) file
* Deploy the PolicyCheckerApp via the WLS console or weblogic.Deployer
* Run the tool by accessing PolicyChecker.jsp
o Eg. http://localhost:7001/webApp/jsp/PolicyChecker.jsp
Tip: If deploying or running PolicyChecker has any issues, you may need to change the p13n_app.jar bundled with the policychecker.zip with the version of your WebLogic Portal. As well refer the instructions mentioned in the PolicyChecker.jsp file.
The screen shows the first of eight checks performed by the Policy Checker tool. This check has identified and reported on all the Roles in LDAP, their scope, and whether corresponding policy refs exist in the DB.
Below screen shows an example of errors found. As part of the check 5, the tool has identified and reported on the security policies found in the database.
Note that the Policy Status column shows 'No LDAP Security Policy found' indicating that the corresponding policy data is missing from LDAP. This error condition was generated by resetting the LDAP without resetting the DB.
LDAP Browser
You can use any external LDAP browser to browse the LDAP data. The prerequisite for using embedded LDAP via any external LDAP is to set a password for the embedded LDAP via the WLS console.
* In the WLS console, navigate to Domain -> Security -> Embedded LDAP.
* Edit the Credential field
* Set a new password
* Restart the server
The sample connection details for LDAP server
* Set Host to your server's host name (e.g., localhost)
* Set Port to your server's port number (e.g., 7001)
* Set Base DN to the name of your domain prefixed by dc=, for example 'dc=mydomain'
* The domain name is in the domain's config.xml in the element
* Uncheck the Anonymous Bind checkbox
* Set User DN to 'cn=Admin'
* Set Password to the password you set for the embedded LDAP via the WLS console
* Click Connect
If You are successfully connected LDAP browser user interface will show WLP embedded LDAP server as shown in the screen.
Reading LDAP
WLP security data is stored in the XACMLRole and XACMLAuthorization trees
Sample XACMLRole entry
urn@Lbea@Lxacml@L2.0@Lentitlement@Lrole1@Lrole@Ltype@AE@AFwlp@AG@AM@AOEntApp@AEportalApp@
AM@AOWebapp@AEwebApp@AM@AOResource@AEcom_bea_p13n_role_policy_pool@AM@AOCapability@AE
com_bea_p13n_appl_role_policy_pool
com_bea_p13n_admin_role_policy_pool
com_bea_p13n_role_policy_pool
com_bea_p13n_role_segment_pool
Sample XACMLAuthorization
AE@AFwlp@AG@AM@AOEntApp@AEportalApp@AM@AOWebapp@AEwebApp@AM@AOResource@
AEcom_bea_p13n@ARPortlet@ARindex_1@AM@AOCapability@AEview
* Viewing the XACML Document:
o function:string-is-in">role1
How to resolve:
1) WebLogic Portal does not have a good official story for recovering from out-of-sync conditions. WebLogic Portal's official advice is to restore the latest clean database and LDAP backup then recreate any necessary Entitlement data. It is also encouraged to backup database and LDAP early and often.
Tip: backup your LDAP and DB before attempting to modify the records.
2) On the other hand, if you have a Propagation Inventory backup to restore the LDAP data, you can use it to restore synchronization between LDAP and DB. To do this, you need to first reset the LDAP and DB to a new clean state following the steps, then reimport the Inventory. Upon import, the Entitlement data from the inventory is recreated in LDAP and database.
1. To fully reset LDAP to a clean state, delete the embedded LDAP files
* Delete /servers/AdminServer/data/ldap
* Upon server restart, the LDAP store will be recreated
2. To fully reset the DB to a clean state, use create_db.sh/cmd
3. To run create_db.sh/cmd,edit /database.properties
* Change the DB vendor as required like 'database=oracle'
* Change the connection properties for your database
* oracle.user=myuser
* oracle.password=mypassword
* oracle.url=jdbc:bea:oracle://myhost:1521;SID=mysid
4. Execute /create_db.sh (or create_db.cmd)
5. create_db.sh/cmd reruns the SQL scripts that create the WLP database tables and system data. This includes dropping any existing tables and data. The result is a database that is in the same condition as a new domain after creation with config wiz.
3) It is also possible to clean up the DB and/or LDAP by deleting individual records, which takes more research and potentially trial and error. But this approach is not supported.

2010-03-01

usePackageNames: on
com.bea.p13n.entitlements: on

[com.bea.p13n.entitlements.management.internal.SecurityHelper.getAuthenticatedSubject():290] return auth subject:principals=[weblogic, Administrators]

urn@Lbea@Lxacml@L2.0@Lentitlement@Lrole1@Lrole@Ltype@AE@AFwlp@AG@AM@AOEntApp@AEportalApp@
AM@AOWebapp@AEwebApp@AM@AOResource@AEcom_bea_p13n_role_policy_pool@AM@AOCapability@AE
com_bea_p13n_appl_role_policy_pool
com_bea_p13n_admin_role_policy_pool
com_bea_p13n_role_policy_pool
com_bea_p13n_role_segment_pool

AE@AFwlp@AG@AM@AOEntApp@AEportalApp@AM@AOWebapp@AEwebApp@AM@AOResource@
AEcom_bea_p13n@ARPortlet@ARindex_1@AM@AOCapability@AEview
* Viewing the XACML Document:
o function:string-is-in">role1

* oracle.user=myuser
* oracle.password=mypassword
* oracle.url=jdbc:bea:oracle://myhost:1521;SID=mysid