> 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
