We have a problem trying to segregate viewing access to Audit Events.
We have more than 15 organizations entitled to use Policy Manager as per developing APIs.
Each organizations have a dedicated role, one of which being: "Message Audit Records: in security zone "<organization_name>_zone". Each organization have their own root folder "<organization_name>_folder", with a security zone option "<organization_name>_zone" applied on it. Each organization have multiple developers.
Let's say we have a user "user1" with role "org1_role" creating an API "org1_api" within folder or sub-folder of "org1_folder". He can see only its own audit events for "org1_api". Fine.
Now if "user1" is also entitled to develop for "org2", thus getting an additional role '"org2_role", he can't see audit events generated by an API in security zone "org2_zone".
More than this, if "user3" is a co-worker of "user1" thus for only role also "org1", he can't see events created by his co-worker "user1".
This seems to be due to internal role "Manage org1_api service" being automagically applied to the API creator, "user1".
If we add this very same induced role to "user3", then it works.
Are we doing this completly wrong ?
What we want: multiple users within the same organization (same role) only see their APIs in audit events.
Audits do not get assigned zones instead they inherit a zone from the service that produced the audit. In order to view an audit, the user must have read permission for the service that produced it. As you have noted that the user that creates the service through the API Portal will be assigned the role to review audits and any user that wants to view the audits will need to be apart of the same role or zone that includes the service.
Director, CA Support