ROP, server-side state and "session fixation problem"

[Andrus Adamchik <an...@objectstyle.org>]

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

Re: ROP, server-side state and "session fixation problem"

[Andrus Adamchik <an...@objectstyle.org>]

On Sep 14, 2012, at 9:58 AM, Andrus Adamchik <an...@objectstyle.org> wrote:

> 1. (3.0, 3.1) Document needed Tomcat (and Jetty?) configuration to turn off "session fixation problem".

This part is done. Actually pretty simple:

http://svn.apache.org/viewvc/cayenne/main/branches/STABLE-3.1/tutorials/tutorial-rop-server/src/main/webapp/META-INF/context.xml?view=markup&pathrev=1384995

Re: ROP, server-side state and "session fixation problem"

[Andrus Adamchik <an...@objectstyle.org>]

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 <jo...@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
>> 
>> 
>> 
>> 

Re: ROP, server-side state and "session fixation problem"

[John Huss <jo...@gmail.com>]

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
>
>
>
>