Ok, I see your point and yes, partially this is related to the name "DONTCARE". I'm fine with renaming it to CANTDECIDE and then implementing it the way you suggest :)
Regards Carsten 2014-03-18 0:48 GMT-07:00 Mike Müller <[email protected]>: > > 2014-03-17 8:38 GMT-07:00 Mike Müller <[email protected]>: > > > > > Hi > > > > > > I think this is insecure by design and not correct: > > > The problem is not, that we do grant access if no ResourceAccessGate is > > > registered for application context. The problem is, that we grant > access > > > also if there is a ResourceAccessGate registered for application level > but > > > does return GateResult.DONTCARE. In this case no access should be > granted > > > as we do on provider context. > > > To see that actual wrong implementation in action have a look at the > > > integration > > > Test in > > > > SecuredProviderResourceAccessSecurityTest#testUpdateDeniedUpdateAllowedRead: > > > Here only READ is granted but not UPDATE. But because there are also > > > registered > > > ResourceAccessGates for application levels the access would be granted > for > > > update anyway if no application ResourceAccessGate denies updates (per > > > default > > > they only return GateResult.DONTCARE). > > > There's no disadvantage if we do not grant access if no > ResourceAccessGate > > > returns GateResult.GRANT. Because in the case if no ResourceAccessGate > is > > > defined we do not have a registered ResourceAccessSecurity service for > > > the application level. > > > So IMHO we definitively have to change this behavour to act similar as > in > > > the > > > provider context. > > > > > > > > ah, thanks, got it now. I think either way is a little bit strange. I > guess > > we all agree that if there is no application RAG, the resource is > > accessible (leaving out the provider RAG for now). > > Then you add an application RAG which say "DONTCARE" and out of the > sudden, > > the resource is not visible anymore. This seems a little bit > contradicting > > the term "DONTCARE". I think DONTCARE means you get the same result as if > > this check wasn't done and in the case of the application RAG that's > acess > > is granted. > > > > Regards > > Carsten > > > I think in this case the concept of DONTCARE is not clear. DONTCARE > doesn't mean > GRANT, it rather means "I can't decide". So if a RAG returns DONTCARE that > means > NOT if nobody else handles the resource we can grant access. Maybe it's > easier to > understand why this third answer (beside GRANT and DENY) should be > possible at > all, here's a use case: > Think of a LockdownGate which locks down the whole site and only allows > access to > logged in users. To do that we implement a RAG with a canReadMethod like > this > > public GateResult canRead(Resource resource) { > if (resource.getResourceResolver().getUserID() != null && ! > resource.getResourceResolver().getUserID().equals("anonymous") ) > { > return GateResult.DONTCARE; > } > else > { > return GateResult.DENIED; > } > } > > and register the RAG with the property finaloperations=read. > This ensures that not logged in users do not have read access. But it also > ensures > that logged in users do not have more access than before the registration > of the > LockdownGate because with the returning DONTCARE the gate delegates giving > access here to the other existing gates. If no other gate grants access > the logged > in user will not have additional access because of the LockdownGate, which > is > what we really want. To allow access would be wrong. > > We do exactly that with provider context RAGs so it would be wrong to do > something > else in the application context. The only difference between these two is, > that without > any RAG registered for the provider context access will be denied (because > the resource > provider asked for with the setted flag). In application context access > will be granted without > any RAG registered for application context (because in this case maybe you > do not want > to use ResourceAccessSecurity). But as soon as a RAG is registered we do > that because we > want to control the access and the registered RAGs have to grant access > explicitly. > > Maybe it would make sense to rename the DONTCARE to CANTDECIDE which would > explain the mechanism better. > > Best regards > mike > -- Carsten Ziegeler [email protected]
