4 ms·

One more example I'll use next time someone asks me "why service oriented architecture". Interaction with AWS should be wrapped in an app service. So the keys

One more example I'll use next time someone asks me "why service oriented architecture". Interaction with AWS should be wrapped in an app service. So the keys will be on your server. Your web sites or apps talk with that service, not the underlying implementation behind it (i.e. AWS). The API exposed by your app service should be secure by default. Sometimes some of those apps start as web sites, and they keep a lot of their logic in their controllers, even views. So when time comes to port this to a native phone app for ex., database logins, secret keys and other private implementation details "naturally" end up in application code, since an app consists of the native code version of said controllers and views. This could've been easily avoided if you automatically split things in secure services from the very start.

trustlook 13y ago
Besides AWS, so many SDKs are used client oriented design, like Dropbox and Facebook. The consequence of leaking those keys may not critical as the AWS though.
- DigitalBison 13y ago
  Maybe not as critical in a strict financial sense, but absolutely critical in a privacy and data confidentiality sense.
ossreality 13y ago
Except that you don't understand the problem either and have replicated it and just moved it.
aluskuiuc 13y ago
That said; the AWS APIs offer a lot of tools to hand keys to clients with extremely limited scope, both in API access and time boundaries. For example; a game could be given access keys that allow it to write a high score only to a particular row of a DynamoDB table, the one corresponding to that user. Direct device->AWS use can make a lot of scaling issues very simple without needing a middleman service on every request. However this does not obviate the need for a federation brokering-type service that auths the device, calls AWS to get a time-limited token with permissions scoped just so, and hands that back to the client. AWS provides Amazon/Google/FB web identity federation for just this use case: http://aws.amazon.com/iam/details/manage-federation/ http://aws.amazon.com/iam/details/manage-federation/.
- mantrax4 13y ago
  This is all great, and indeed solves the security issues in exposing AWS. And I'm sure it does wonders for locking in clients to AWS APIs ;) As for scalability, there's no inherent scalability issue with middlemen services. There's potentially some added lag (not necessarily), but a pure middleman service (with maybe a bit of caching) is an "embarrassingly parallel" workload. If it gets slow, you just add more servers. And they could be Amazon EC2 servers, nothing bad about that! :)
deleted 13y ago
[deleted]

trustlook 13y ago

Besides AWS, so many SDKs are used client oriented design, like Dropbox and Facebook. The consequence of leaking those keys may not critical as the AWS though.

DigitalBison 13y ago
Maybe not as critical in a strict financial sense, but absolutely critical in a privacy and data confidentiality sense.

ossreality 13y ago

Except that you don't understand the problem either and have replicated it and just moved it.

aluskuiuc 13y ago

That said; the AWS APIs offer a lot of tools to hand keys to clients with extremely limited scope, both in API access and time boundaries. For example; a game could be given access keys that allow it to write a high score only to a particular row of a DynamoDB table, the one corresponding to that user. Direct device->AWS use can make a lot of scaling issues very simple without needing a middleman service on every request. However this does not obviate the need for a federation brokering-type service that auths the device, calls AWS to get a time-limited token with permissions scoped just so, and hands that back to the client. AWS provides Amazon/Google/FB web identity federation for just this use case: http://aws.amazon.com/iam/details/manage-federation/ http://aws.amazon.com/iam/details/manage-federation/.

mantrax4 13y ago
This is all great, and indeed solves the security issues in exposing AWS. And I'm sure it does wonders for locking in clients to AWS APIs ;) As for scalability, there's no inherent scalability issue with middlemen services. There's potentially some added lag (not necessarily), but a pure middleman service (with maybe a bit of caching) is an "embarrassingly parallel" workload. If it gets slow, you just add more servers. And they could be Amazon EC2 servers, nothing bad about that! :)

deleted 13y ago

[deleted]