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