[OPENDJ-4774] Proxy production mode removes necessary global access control policy Created: 14/Feb/18  Updated: 08/Nov/19  Resolved: 30/May/18

Status: Done
Project: OpenDJ
Component/s: documentation, ease of use, proxy
Affects Version/s: 6.0.0
Fix Version/s: 6.5.0

Type: Bug Priority: Major
Reporter: Ondrej Fuchsik Assignee: Mark Craig
Resolution: Fixed Votes: 0
Labels: Verified

Epic Link: Bugs 6.5
Story Points: 1
QA Assignee: Ondrej Fuchsik

 Description   

While working on new tests for dj proxy with production mode enabled during installation, I noticed that it removes a global access control policy "Authenticated access all entries". However this policy is necessary for operations like Pre-Read and Post-Read controls, the Subtree Delete control, and the Permissive Modify control. Which is explicitly mentioned in Installation guide in description of --productionMode parameter. link => DS Setup Proxy   

When I added this policy like  this policy example , the pre-read control works as expected.

From my point of view, it is not big problem, however the documentation shouldn't mention this in proxy installation guide. Other sections of installation guide should be reviewed according to this. A description of --productionMode parameter is same for installation of directory-server, replication-server and proxy-server.



 Comments   
Comment by Mark Craig [ 14/Feb/18 ]

Perhaps I'm not fully understanding the problem. On a proxy it seems like a bug to turn off access for authenticated users by default, even in production. Ondrej Fuchsik, is that really what the --production-mode does to a proxy server? If so, I think we should fix the behavior with the option before changing the documentation.

It does make sense when setting up a server for production to turn off all access by default for a DS, where the directory admin/architect should make conscious decisions to grant data access with specific ACIs. But when you have only global access control policies and cannot further fine-tune access with ACIs, you should take those access decisions at the backend DS, not the proxy.

Comment by Mark Craig [ 14/Feb/18 ]

Going to unassign myself for now as it appears there might be a change to make to the config patch for proxy --productionMode before changing the docs.

Comment by Ondrej Fuchsik [ 15/Feb/18 ]

I am sure the removal of the global access policy is due to  --production-mode . Without this parameter the policy exists. For me the behavior now is odd, due to code or docs and I am not sure which one should be target for fix. Depends on what is exactly expected of --production-mode for proxy-server installation. 

Comment by Ludovic Poitou [ 30/Mar/18 ]

Ok, I don't think there is any bug or issue here.

The production mode doesn't remove any access. It is designed to provide the basic policies to read the RootDSE and the schema, but requires that an administrator explicitly defines what base-dns and attributes can be accessed. This is the same for DS.

The other parts of the policies that allow specific extended operations and controls are here to make that previous step easier. But they are not really operational without that step.

I agree that in order to test and use the Proxy in Production Mode, one must add a policy that grants access to specific base-dns to authenticated users, and the one documented is a good one albeit pretty permissive.

I am going to close this as not a defect. 

Comment by Ludovic Poitou [ 30/Mar/18 ]

The behavior is by design of the ProductionMode.

 

Comment by carole forel [ 29/May/18 ]

So shouldn't we make that appear in a clearer way in the documentation? It does not seem that obvious, does it?

Comment by Mark Craig [ 30/May/18 ]

The second example in the setup procedure at https://backstage.forgerock.com/docs/ds/6/install-guide/#setup-proxy demonstrates proxying traffic to dc=example,dc=com.

I agree that it could be helpful to add a step to the install procedure, explicitly showing how to open up access to dc=example,dc=com.

So I'll reopen this as a doc issue, assigning it to myself.

From an ease-of-use perspective, it seems natural to think that because you configured the proxy to forward traffic for some set of naming contexts, the proxy would let that traffic through without further configuration. Like so much of security, however, it could be that we're not smart enough to come up with an intuitive solution that is also secure enough for production use.

Comment by Mark Craig [ 30/May/18 ]

Updated the proxy setup procedure in the Install Guide to add a step that demonstrates adding access control when the setup option --productionMode was used

Comment by Ondrej Fuchsik [ 18/Sep/18 ]

I checked the 6.5 documentation (qa environment) and looks ok to me, so I am closing this issue.

Generated at Tue Mar 09 10:43:58 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.