RequestFactory and Security/Authentication

[Max E.]

Hello,

i have troubles understanding how Security works with RequestFactory
in GWT 2.1.
I do unterstand the documentation and I do unterstand the expenses
sample.

How can I restrict access for the client only to entities she is
allowed to access?
I found UserInformation, but how does it work?
How do my users authenticate to the server?
How can I validate that they are allowed to update or persist an
entity?
Unfortunately I did not find documentation for this topic.

[Tobias]

My understanding is that - apart from the basic authentication
support, e.g. against AppEngine - RequestFactory does not provide any
security-related framework. You have to make sure that the service
methods check for authorization. Also, make sure, the "side-effects"
that RequestFactory carries, like changed Entitys, don't get persisted
without an additional check. RequestFactoryServlet will findById(...)
any Entities as specified by the client request, and then call set...
() for any changed value, and it does that even for child entities. So
either you guard all your finders and setters, or you make sure that
the changes caused by calling these setters only get written to the
datastore by calling a special "persist" method. However, that persist-
method does not have a way of knowing exactly which child entities
have been changed, and in JDO for example, simply closing the
PersistenceManager or comitting the current transaction will cause all
changes to be written to the datastore. So in that case, I have to
inspect the transaction in order to know what exactly the
RequestFactoryServlet did to my data model and whether it's safe to
commit.

So I hope that GWT 2.1.1 gives us a possibility to see exactly what a
Request wants to do beforehand. In the current state, I honestly doubt
that RequestFactory should be used in a productive environment, as it
introduces really hard-to-overlook security problems. That's a pity
since it otherwise it would make for a really nice RPC-system. I think
the server-part needs a lot more work, and from looking at the 2.1.1-
wiki-pages it seems to get overhauled quite a bit.

Maybe someone from Google can comment on how the security issues can
be addressed effectively with the 2.1 RequestFactory?

Regards,
Tobias

[Stephen Haberman]

> In the current state, I honestly doubt that RequestFactory should
> be used in a productive environment, as it introduces really
> hard-to-overlook security problems.

That was my impression was well. I agree it will be interesting to see
how, if at all, this gets addressed in future releases.

- Stephen

[zixzigma]

I am also interested to know what is the best practice in implementing
client-side application-level security (role-based security).
Would be great if Google team provide some tips as how it fits within
RequestFactory and MVP.

[Thomas Broyer]

On 10 nov, 18:35, Stephen Haberman <stephen.haber...@gmail.com> wrote:
> > In the current state, I honestly doubt that RequestFactory should
> > be used in a productive environment, as it introduces really
> > hard-to-overlook security problems.
>
> That was my impression was well.

I think it really depends what your use case is. In our app, either
the user has only access to data for reading only (guarding the
methods with role-based checks would then be enough), or he can only
modifies objects that he has previously checked out (checking the
current user is the same as the "lock owner" is enough then), and he
can only check out objects that he's been given the "editor" role on
(checking that the current user is in the list of editors for the
object is enough then). But if the user has rights to modify an
object, he really can do anything with it.
I don't think RF has real security flaws for this use case (but I
honestly haven't investigated that much, given that it'll change soon
and we're at the very beginning of the project, which is due for
june).

> I agree it will be interesting to see
> how, if at all, this gets addressed in future releases.

Have you looked at http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1
?

[Stephen Haberman]

> On 10 nov, 18:35, Stephen Haberman <stephen.haber...@gmail.com> wrote:
> > > In the current state, I honestly doubt that RequestFactory should
> > > be used in a productive environment, as it introduces really
> > > hard-to-overlook security problems.
> >
> > That was my impression was well.
>
> I think it really depends what your use case is.

That could be.

My biggest concern is the client-driven object graph navigation that RF
allows. E.g. let's say you have a method:

Employee find(int id) {
// check employee access
return em.find(Employee.class, id);
}

Stringing together `with("employer")`, etc., can a malicious client
return more than just the employee from this method? Of course employer
must pass checkClass. But checkClass aside, the client can pull
arbitrary object graph data back that isn't subject to a user-/method-
specific check.

Similarly on save, if I have:

void saveMyEmployee(Employee ee) {
// check employee access
em.persist(ee);
}

And a malicious client sends in a JSON request that sets both the
employee name and the employer name, will `em.persist` cascade save both
the employee and the employer?

(I admit I don't regularly use JPA, so my knowledge of their cascading
semantics is not what it should be. I did use Hibernate once where
"cascade all" was how we had it configured, but I don't know how common
that is.)

I would feel a whole lot better about RF if the fields/object graph
navigation allowed for each find/save/service method was specified
and enforced on the server-side rather than being a client-directed
feature.

> Have you looked at RequestFactory_2_1_1?

Yeah, I definitely like RequestFactoryMagic showing up, but I didn't see
anything related to restricting field/object graph navigation.

- Stephen