cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: ROP, server-side state and "session fixation problem"
Date Fri, 14 Sep 2012 13:58:43 GMT
So I guess our attack plan might be this:

1. (3.0, 3.1) Document needed Tomcat (and Jetty?) configuration to turn off "session fixation
problem".
2. (3.2) Implement stateless connection working with BASIC auth (that should throw on stateful
operations… the only one I can think of is "commitChangesToParent"). 
3. (3.2) Provide some pluggable mechanism for session-based stateful authentication and operation.
(Hmm, would anyone really care about it if we have stateless operation)
4. (?) Create some pluggable framework for role-based authorization. E.g. I can think even
a set of simple rules like "only allow queries mapped in the Modeler to be run", "do not allow
commits", "do not allow SQLTemplates" should go a long way to bring the level of the ROP service
security to the level of your average web service.

Andrus

On Sep 13, 2012, at 10:24 PM, John Huss <johnthuss@gmail.com> wrote:

> My ROP app unfortunately got canned, but I had created a custom login
> message (along with some others) that contained the username and password.
> If correct if would store the User object in the session and then check
> for it on subsequent requests.
> 
> There is quite a bit to be done to properly secure an ROP service even
> beyond authentication.  You really want to be able to limit what queries
> are able to run and which objects can be accessed, and there is no standard
> approach for handling this.  I modeled my approach after what WebObjects
> did, but I didn't complete it.
> 
> On Thursday, September 13, 2012, Andrus Adamchik wrote:
> 
>> Have a bit of an issue with ROP and the latest containers:
>> 
>> https://issues.apache.org/jira/browse/CAY-1739
>> 
>> Essentially with BASIC auth we can no longer force the ROP client to
>> return back to the same session between requests. Both recent Tomcat and
>> Jetty would reset session ID on every request (as every request is under
>> BASIC auth protection). A workaround now is special Tomcat configuration to
>> disable session resets. We can and should document it, but ideally I'd like
>> ROP to work anywhere out of the box.
>> 
>> We can't reliably track the changing session ID on the client, as it will
>> create a client-side race condition.
>> 
>> Long term I think we should reserve BASIC auth for the stateless apps (why
>> create a server side session if we can create a Cayenne stack for every
>> request on the fly). We don't have a stateless option in ROP and this is a
>> shame.
>> 
>> So the question is what to do for stateful apps (and specifically in 3.1
>> where all ROP apps are stateful by definition)? Anyone has implemented ROP
>> auth other than BASIC? (Otherwise I don't understand how this problem
>> wasn't noticed till now).
>> 
>> Andrus
>> 
>> 
>> 
>> 


Mime
View raw message