IBM Support

Resolving E_ACCESS_DENIED authorization errors in Content Platform Engine

Technical Blog Post


Abstract

Resolving E_ACCESS_DENIED authorization errors in Content Platform Engine. These errors could occur for any operation such as, but not specific to, DELETE or CHECKIN.

Body

A very common issue that we see in support are authorization problems to Content Engine objects. Sometimes access rights issues are difficult to narrow down through looking at the Security entries for the object through the GUI. When all else fails you can use the Security tracing subsystem in the Content Engine. I would like to discuss how to troubleshoot a security authorization issues using the p8_server_trace.log file.



A basic understanding of how authorization works is important. The basic components are: The "Caller Principal", the user who is calling the Content Platform Engine. The "User Access Token", a list of principals including the user and all the groups that the user is a member of. An algorithm that compares the "User Access Token" against various Access Control Lists, owner information and other object properties to determine the user's effective access to the CE object. When this access check fails, either an E_ACCESS_DENIED exception is thrown or no object is returned from the server, such as in the case of a query.

For more detailed information on Content Platform Engine authorization and access rights, please see the following help topic:

https://www.ibm.com/docs/en/filenet-p8-platform/5.5.x?topic=infrastructure-managing-security



1. When troubleshooting a complex security issue, the first thing you need to do is reproduce the issue and capture the p8_server_trace.log file. Use either FileNet Enterprise Manager or Administration Console for Content Platform Engine to turn on full Security, Error and EJB tracing. Reproduce the problem and capture the p8_server_trace.log file. In a cluster environment, be sure to capture the p8_server_trace.log from all servers. Please remember to turn off tracing once the issue has been reproduced.

trace1Trace2

2. Analyzing the p8_server_trace.log file

Use the following steps to identify and troubleshoot authorization errors.

1. Find the error (ie. 'E_ACCESS_DENIED') in the log. Make sure that it really is an authorization error. Usually message will include an "insufficient access" error, but "read only" errors could also be because of an access rights issue.

2. Search up from the error message in the log and find the closest <securitytracedetail> in the same thread.

  • If the "short" form (which has <isaccessgranted>) then find the ID of the object being checked and search up for that ID to the closest appropriate "long" form.
  • If the "long" form (which has <accesstoken>, <securitydescriptor> and <appliedmarkings>) then that most likely has the information needed to identify the problem.

3. Look at the "long" form of the <securitytracedetail>, this will have the following information

  • The User Access Token - is the user in the expected groups?
  • The Security Description - this has the full Access Control List (ACL) and the owner. Check the Access Control Entries (ACE) to see which ones have "ispresentintoken="true"" and which ones have "ispresentintoken="false"".
  • The Active Markings - Are there any Markings denying required access rights.



Here is an example of a user trying to delete a document and receiving an "insufficient access" error.

1. I searched the p8_server_trace.log from the bottom up and found the "E_ACCESS_DENIED" error that shows the user has insufficient access rights to delete the document object.

Trace3

2. I search up from the error message for the first <securitytracedetail> in the same thread which happens to be the "short" form. Note the thread ID's (57DD3861) match between the log entries. The effective access to the object for this user does not include the DELETE access right.

Trace4



3. I search up for the first "long" form <securitytracedetail> in the same thread. This shows the effective access again and the User Access Token.

Trace5


4. The <securitydescriptor> element of the <securitytracedetail> shows the effective access that comes from the Access Control List (ACL). Note that it does have the DELETE access right listed, so it cannot be the root of the problem. The owner of the object is also listed.

Trace6


5. The <appliedmarkings> element of the <securitytracedetail> shows the effect of markings on the access rights of the object. In this example, it shows the root cause of the E_ACCESS_DENIED error. There is a marking applied to this object which denies the DELETE access right to the user. To correct this issue you would either remove the marking or give this user the USE_MARKING access right on the marking set.

Trace7


6. These last elements provide some timing and statistical information that can be helpful in diagnosing performance problems.

Trace8

I hope this sheds some light on how to use the security tracing to resolve complex security issues when they arise.  Thanks.

If the security entries appear to be correct, ensure the document (or ce object) is not exclusively checked out by another user.
The following error:
E_ACCESS_DENIED: The requester has insufficient access rights to perform the requested operation. ComponentBindingLabel is a read-only property and cannot be updated at this time.
can be an indication of the document being exclusively checked out by another user.

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSNVNV","label":"FileNet Content Manager"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

UID

ibm11280332