|
|
|
|
|
by mantrax4
4460 days ago
|
|
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. |
|
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/.