> "The system" in this case is the combination of the GAE platform and > an application running on said platform.
No, I would prefer GAE to implement the system completely, using existing elements. How? In app.yaml, you specify that your application supports mapping multiple google apps user spaces to your app. Currently it only allows one. This is an application marketplace type concept. When my app is added, a new data partition is created for their users. Most importantly I am the administrator of the app and all of the data partitions - this is different to deploying my app to their GAE account - it still resides in my account, and the customer has no administrative rights beyond what I give the in my application code. I need only have one app deployed. With this model, registration, user provisioning, authentication and data partitioning are all handled external to my application code using building blocks that are already present in the GAE offering. The only change to my application code from right now is an entry in app.yaml. It's not even particularly complicated - especially for me, the application developer. I can imagine implementations that don't even require the app.yaml entry. I'll admit (as I'm sure you will) that this thread has led me to think more deeply about the implementation of the use case from my original post, but the above is not excessive, and is much preferable to application code. It would allow some great additions, such as a common billing and payment engine - something most app developers would love to have taken off their plate. Yet another feature this would allow - version migration for customers. I deploy separate versions of my app, and have the ability to move customer data partitions between app deployments. An obvious use case is that some customers may be happy to try new features in beta, others may want to wait for release versions. It is worth noting that google apps essentially supports this feature currently with the checkbox indicating that you want the latest features. These are all major development efforts that carry significant risks to your customers, and are mostly diversions to core creative application development. Common use cases should be moved to the platform layer, freeing the developer to actually build their application. This, I think, is a good summary of the stated goals of GAE platform. I'll add the above implementation as a suggestion to 945 to clear up any misunderstanding about platform vs application. > The GAE security architecture is not based on "not allowing cross data > store queries". It's based on authenticated access to partitioned > datastores, which is a very different thing. I did say - '...security architecture of GAE is based on trustable external authentication, data partitioning, mapping that data partition to the authenticated entity, and not allowing cross data store queries' I realise they are different things, that's why I listed them separately. As it stands GAE does not allow cross data store queries, and from my perspective that is an aspect of the security architecture. 106 wants that aspect 'relaxed'. While I don't think GAE will implement cross data store queries using the data API (I still think exposing an application API to access said data, or supporting one data partition for many apps is the right choice), a possible implementation that would be acceptable to me is adding an entry to app.yaml specifying how strict data partitioning should be for an application. For my use case I would choose the strictest option, and for yours something less so. It's not ideal, as an error in app.yaml could lead to the cited bug, but the risk profile much less, and more easily auditable. On Dec 30, 12:53 am, Andy Freeman <ana...@earthlink.net> wrote: > > 'The system spawns a virtual instance of the app - or at least allows > > mapping a single datastore partition to the authenticated entity. You > > coudl extend it by allowing multiple datastores per authenticated > > entity and choosing the appropriate one at authentication time.' > > > I haven't mentioned application code at all. If you have interpreted > > 'the system'' to mean my application code, then I think you are being > > disingenuous. > > "The system" in this case is the combination of the GAE platform and > an application running on said platform. > > > What's the point of a feature request for my own application code? > > Oh really? The reason that this requires a feature request is that it > isn't (currently) possible for an application running on GAE to > request the creation of another datastore. (One could call an outside > agent to request another application, but ....) > > > Do you support request 106? > > Yes. > > > Do you oppose 945? > > Not sure. > > > At the moment, I am getting the idea you support 106, > > but not the implication that it would support queries across > > datastores. > > 106 allows an application to access multiple datastores, so why would > I think that it doesn't? > > Note that the ability of an application to access multiple datastores > does not imply the ability to access arbitrary datastores. Note also > that the ability to access multiple datastores could be satisfied via > a "datastore login" API used by the application which would be as > secure as anything by the platform before the application starts. > (Both schemes can be exploited by malicious code. Both are only as > secure as the platform's login.) > > > I am also understanding that you oppose the data > > segregation from 945 because you think it doesn't serve a purpose. > > I'm skeptical of 945 because it's a lot of mechanism. There are many > ways to get data segregation using the existing partitioning. > > > This is despite the fact that the entire security architecture of GAE > > is based on trustable external authentication, data partitioning, > > mapping that data partition to the authenticated entity, and not > > allowing cross data store queries. > > The GAE security architecture is not based on "not allowing cross data > store queries". It's based on authenticated access to partitioned > datastores, which is a very different thing. One could have > authenticated access to partitioned datastores AND cross datastore > queries. One could have authenticated access to choice of partitioned > datastore but not have cross datastore queries. One have > authenticated access to choice of partitioned datastores and allow > cross datastore queries. One could even have an "authenticated > choice" mechanism that allowed cross datastore queries for some > datastores and not others. > > > Are you saying the current GAE security architecture is wrong? > > No. > > > Or just that they should get rid of the data partitioning to deliver > > feature 106? > > No. > > On Dec 26, 5:50 am, hawkett <hawk...@gmail.com> wrote: > > > > Huh? You were requesting the ability to spawn a new datastore and to > > > have the login scheme for a given pile of application code pick the > > > datastore. The above is about methods for separating datastores and > > > whether the method for separating them should depend on how the > > > datastore is chose > > > I assume you are talking about this statement from my first post? - > > > 'The system spawns a virtual instance of the app - or at least allows > > mapping a single datastore partition to the authenticated entity. You > > coudl extend it by allowing multiple datastores per authenticated > > entity and choosing the appropriate one at authentication time.' > > > I haven't mentioned application code at all. If you have interpreted > > 'the system'' to mean my application code, then I think you are being > > disingenuous. What's the point of a feature request for my own > > application code? The feature request has the term 'data segregation' > > in its title, and doesn't include the proposed extension (as this > > would add significant additional complexity). Anyway, when I request > > functionality in 'the system' in a GAE feature request, I am talking > > about GAE, not my own application code. If you're talking about some > > other statement I made, then please say what it is. > > > > With no post-login check, the application runs using whatever > > > datastore the login procedure finds acceptable. > > > Yes, it does. This is not our application code, and we trust it. If > > you don't trust it, modify it or choose a different authentication > > mechanism that you do trust. > > > > If the login > > > procedure fails or the datastore layer serves up the wrong datastore, > > > the application still does its thing. > > > Raise and fix the bug in the authentication/db layer. > > > What is your actual position Andy? Do you support request 106? Do > > you oppose 945? At the moment, I am getting the idea you support 106, > > but not the implication that it would support queries across > > datastores. I am also understanding that you oppose the data > > segregation from 945 because you think it doesn't serve a purpose. > > This is despite the fact that the entire security architecture of GAE > > is based on trustable external authentication, data partitioning, > > mapping that data partition to the authenticated entity, and not > > allowing cross data store queries. Are you saying the current GAE > > security architecture is wrong? Or just that they should get rid of > > the data partitioning to deliver feature 106? If this is your > > position, then it seems totally unsustainable to me. > > > On Dec 24, 11:45 pm, Andy Freeman <ana...@earthlink.net> wrote: > > > > >> You're hoping that the partitioning for a given datastore depends on > > > >> how google allows access to said datastore > > > > Exactly - that is the feature request I am proposing. > > > > Huh? You were requesting the ability to spawn a new datastore and to > > > have the login scheme for a given pile of application code pick the > > > datastore. The above is about methods for separating datastores and > > > whether the method for separating them should depend on how the > > > datastore is chosen. > > > > > I don't agree. You should trust your authentication mechanism - this > > > > is a trust relationship. If you don't trust it, then you need to > > > > address that problem, not write additional application code which adds > > > > to the complexity of your security implementation. Complexity in your > > > > security implementation increases risk, not decreases it. Note this > > > > is not an argument against defense in depth - it is an argument for > > > > simplicity in each implementation layer. > > > > Let's look at these alternatives. > > > > With no post-login check, the application runs using whatever > > > datastore the login procedure finds acceptable. If the login > > > procedure fails or the datastore layer serves up the wrong datastore, > > > the application still does its thing. > > > > Post-validate may catch either of those errors. (Of course, the post- > > > validate could fail as well and allow access when it shouldn't, but > > > that just leaves you no worse off than you were without the check.) > > > Yes, the post-validate may block execution when it shouldn't, but > > > that's likely to be because the datastore layer is misbehaving, > > > delivering wrong data. The application may have failed eventually > > > anyway when running with a misbehaving datastore layer, but detection > > > during validation is better because the application doesn't get a > > > chance to corrupt user-data. > > > > On Dec 24, 10:17 am, hawkett <hawk...@gmail.com> wrote: > > > > > > You're hoping that the partitioning for a given datastore depends on > > > > > how google allows access to said datastore > > > > > Exactly - that is the feature request I am proposing. It seems > > > > likely to me that GAE uses a data partitioning feature of BigTable > > > > (maybe not, I don't know, but to me it seems the right place to > > > > implement a data partitioning function) - they should expand the way > > > > GAE uses that BigTable feature to offer the functionality I am > > > > requesting. > > > > > > If your customers are serious, they must, regardless of how your > > > > > application is deployed, regardless of who handles login/access > > > > > management. Login code isn't the only risk. > > > > > Perhaps, but the threshold is significantly lowered - customers are > > > > more likely to undertake an audit (rather than go to a competitor) if > > > > they can see you are using platform features for security - I stand by > > > > the assertion that 100% of customers who engage you for the first time > > > > will prefer you to be using the platform over custom application code > > > > - especially for security. > > > > > > And, if you're serious about login code, you must validate the login > > > > > result. That is, once it is determined that a given user running your > > > > > application should use a given datastore, the application then must > > > > > look the datastore that it is trying to use and verify that it is > > > > > actually the correct datastore for that user > > > > > I don't agree. You should trust your authentication mechanism - this > > > > is a trust relationship. If you don't trust it, then you need to > > > > address that problem, not write additional application code which adds > > > > to the complexity of your security implementation. Complexity in your > > > > security implementation increases risk, not decreases it. Note this > > > > is not an argument against defense in depth - it is an argument for > > > > simplicity in each implementation layer. We are talking about the > > > > authentication layer, and the db access layer, and both should be > > > > platform concerns, not application concerns (at least from my > > > > perspective) - certainly they are > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
