Hi Jay, I'm thinking that the API would change very little - certainly 100% backward compatible with existing app engine code. For the simple use- case though - 'on' or 'off' - configure it in app.yaml - if it's on, then the datastore essentially has a 'login:required' flag on it, and all keys for that application must contain the openid provider - that field on the key is not something the developer can set (like the app id). If it's off, then its what we have now. An extra method on the Key class - e.g. Key.openid_provider() would make sense as well - when the config is off, it returns None. Exposing to the customer whether this flag was set would also be very helpful. The important thing here is that developer doesn't even have the opportunity to muck it up. Every app in the marketplace with this flag on is suddenly seeming much more secure to the customer. Beyond the marketplace, using openid in this fashion means customers are not restricted to google apps - any (trusted) openid provider would work.
There's plenty of other stuff to consider, such as adminstrator access to the datastore - it's hard to see how you could avoid allowing app administrators full privileges. But that's a different problem - where you can trust the integrity of the vendor, and don't need to worry about their ability to deliver a bug free application that won't expose your data accidentally. Then there's google's access to the data as well - I can't work out from the terms what the restrictions on google's access are. I'm guessing most of incentives for google to keep it secure are reputational, and while those are pretty good incentives, it is a bit of a grey area for customers. It would also be good to be able to specify the lock against particular kinds - Nick highlighted this advantage in his 'enforcing data isolation...' article linked above. The problem with this though is that it introduces the ability for the developer to muck it up. It would also be a lot messier to expose the configuration to the customer. But still, making it configuration based is good, and it can be easily highlighted in the admin console which Kinds are secured and which are not. Remember the goal here is not to prevent malicious attacks - just make it easy for developers to deliver applications that secure their customers data, and that customers understand to be secure. Cheers, Colin On May 12, 3:02 pm, Jay <jbaker.w...@gmail.com> wrote: > Nice discussion. Hawkett, what do you think the api you are describing > might look like? Or is there no change because app engine would know > that an app has been deployed to a google apps domain (through Google > Apps Marketplace) and build that info into the keys or what not like > they currently do with app-id? If there is a change to the api, can > you sketch an example of how you are thinking about it? > > On May 11, 5:10 pm, hawkett <hawk...@gmail.com> wrote: > > > > > I tried arguing for a similar model around this about 18 months ago > > >http://groups.google.com/group/google-appengine/browse_thread/thread/... > > > And created an issue for it > > >http://code.google.com/p/googleappengine/issues/detail?id=945 > > > It's not quite the same as what you are asking, as I was looking for a > > common admin console for a single app deployment by the vendor (not > > the customer) with multiple customers and multiple backing datatsores > > - precisely because of the customer confidence thing. The main > > argument was that being professional and trustworthy didn't prevent > > bugs - having different customer's data separated at the platform > > level is a whole different world of customer comfort to saying 'I > > promise we programmed it real safe'. It's not about whether I > > programmed it real safe or not - it't about reducing barrers to > > customer acceptance. > > > The single app/admin console is a must-have from my perspective - > > managing a stack of different app versions across multiple customers > > would be a logistical nightmare (well we know it is - that's what this > > cloud thing is for). > > > The concept of '1-click, new customer, separate datastore, single > > admin console with both consolidated and drill-down stats' seems > > compelling to me. Granted the marketplace delivers all of that except > > the separate datastores, so I'm not complaining, but the separate > > datastore thing has a lot of strong arguments. > > > In fact, the separate datastore would apply to task queues as well. > > The main reason is that when something goes wrong, it can go wrong for > > all your customers - getting tasks for one customer stuck in the > > queue? That impacts all of your customers. One customer pushing > > quotas? That impacts all your customers. The thread above links to an > > issue in another project that highlights the sort of things customers > > are scared of. > > > I noticed when I changed my app's name the other day, and used a > > bookmark from before the name change (containing a key from the old > > app), GAE threw an error that basically said 'this app can't access > > this other app's data' - and it was a warm fuzzy feeling that the > > platform was sorting that stuff out. Now if the key also contained a > > customer identifier, the same logic could easily apply. 'Customer > > identifier' could be an openid provider, which every google apps > > account is. > > > Now I know each of us can implement that right now with the dbhooks > > article that Nick wrote, and that's definitely very cool - but that's > > a gazillion developers all rolling their own solution - and that looks > > scary as hell to a conservative customer. They don't know who they > > can trust - it's a much easier sell to say google does it at the > > platform level - and a much easier sell is a win for google as well, > > especially if they are taking a cut on the platform use - especially > > by big conservative customers. > > > It is a bit of strange argument, because on the one hand I am saying > > we don't want things that go wrong in the app to affect all our > > customers, and the other hand arguing that google should move > > functionality into the platform, where if things go wrong, well that's > > not just my customers, but everyone's customers. But its an argument > > that works, because google has the resourcesto handle that kind of > > stuff - it's their core business. An that's a lot more attractive to > > customers. > > > Anyway, just thinking out loud really... > > > On May 7, 8:53 pm, Andy Burke <abu...@bitflood.org> wrote: > > > > > This doesn't have to involve a great deal of extra complexity in your > > > > code. > > > > The keyword here is "multitenancy", and there are several possible > > > > solutions. One option is detailed in my blog post > > > > here:http://blog.notdot.net/2009/11/API-call-hooks-for-fun-and-profitandan... > > > > here:http://blog.notdot.net/2009/11/Enforcing-data-isolation-with-CurrentU... > > > > I'm sorry, but hooking the API to do this seems pretty complex to me. > > > > As a developer, it would be much nicer if I could create apps that > > > were specifically meant to be deployed into a customer's Google Apps > > > domain. My code would be significantly simpler in that it would just > > > operate on a datastore assuming that the datastore is owned by the > > > consumer of the app and not shared with any other consumers. > > > > > A third option is to use a model that several of our customers are > > > > already > > > > using: Have your users create an app engine app and add you as an > > > > administrator, whereupon you deploy your app to their instance. > > > > This seems like an awfully big hurdle for someone to deploy an app. > > > Shouldn't Google's goal be to make Google Apps as easy to use as > > > possible? By making it easier for 3rd party developers to enhance the > > > value of Google Apps, both Google and the 3rd party developers would > > > benefit. > > > > The GAE system is already fairly user-unfriendly. Every time I go to > > > my dashboard, I get redirected to my start page which doesn't actually > > > list any of my apps. There's no support email for me to talk to. > > > Instead, I have to craft specific URLs to get to my apps. Now, this > > > is likely a bug and I'll eventually get around to reporting it, but > > > imagining trying to walk some customer through the process of getting > > > an account and deploying an app seems like pure pain to me. > > > > I'd much prefer if there were a Google Apps Marketplace. I could > > > create my app with GAE and configure it to be made available through > > > the Google Apps Marketplace. People who have Google Apps could easily > > > browse/search the marketplace, where I could provide screenshots, > > > pricing information, etc. Then, with a single click they could choose > > > to consume my app in their domain. > > > > > Users seem generally tolerant of this if you are professional. FogBugz, > > > > for > > > > example, have an excellent bug tracking (and more) platform, which is > > > > optionally hosted on their hardware. The same goes for a plethora of > > > > other > > > > companies. > > > > I agree, but I would prefer if I could just take myself out of the > > > loop. It's their data. I really don't want access to it. I'm > > > presenting a system whereby I can develop an app that potentially > > > deals with sensitive data and I can assure customers that only they > > > (and Google) have access to that data, not me. > > > > Someone else raised the issue of bugs that would require access to the > > > datastore to resolve. If that were the case, I would much rather have > > > a customer opt-in to giving me some type of access to their data when > > > they find it necessary because of a software bug. In that case, the > > > vast majority of users would probably not need to ever give me > > > access. Only the minority who encounter a bug and want to help in the > > > resolution would need to expose their data to me as the developer. > > > > > One important thing to note is that there are few (if any) plausible > > > > scenarios that _don't_ require trust from your users. Since you wrote > > > > the > > > > code, you could easily be doing nearly anything with their data; if you > > > > provide for updates, you could modify the app to disclose information to > > > > you, even if you don't have direct access to their datastore. > > > > Essentially > > > > the only way around this would be to provide your users with the > > > > source, and > > > > make updates entirely manual and up to them to apply. > > > > Sure, but customers are used to running software. They're not as used > > > to having their data live under someone else's control. > > > > But, to be honest, let's just forget that I even mentioned the > > > security issue with regard to the datastore: the fact still remains > > > that it would be much less work for me as a developer if I could > > > develop an app that works against a client's own datastore rather than > > > my app's shared datastore. > > > > The complexity of my models goes down: > > > - I don't need to store information about which clients own which > > > data > > > > My development time goes down: > > > - I don't need to spend time enforcing client separation > > > - I don't need to write as much code to handle who the current > > > client using the app is > > > - I don't need to develop a time/storage billing system per-client > > > to recoup my GAE hosting costs > > > > My potential return goes up: > > > - Lots of companies are using Google Apps for hosting their domains, > > > this is a nice market for me to target > > > - Google Apps Marketplace would provide an easy way for people to > > > find and subscribe to/buy my application > > > - Google makes out well, too, taking some percentage of the > > > subscription/sale > > > > All these things seem like they'd be wins on both Google's side and > > > GAE developers' sides. Yes, your links may provide ways that GAE > > > developers can do some of this, but it's certainly less attractive > > > than the solution I'm proposing. > > > > andy > > > > -- > > > 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-appeng...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > google-appengine+unsubscr...@googlegroups.com. > > > For more options, visit this group > > > athttp://groups.google.com/group/google-appengine?hl=en. > > > -- > > You > > ... > > 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-appeng...@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.
