1

I am designing a platform where a large number of cloud-enabled embedded devices will be sending push notifications to mobile apps using Amazon SNS.

Each embedded device should create a SNS topic and publish to that topic. Users will register to a topic and receive these notifications.

My question is: how should the embedded devices handle authentication/authorization with AWS in order to create the topics and publish the notifications. Here are the options I have considered so far:

  • Create a single IAM user that will be 'shared' by all embedded devices. Not a good idea: if a single device is hacked, all of them are compromised.
  • Create a different IAM user for each embedded device. This could be an option but AWS limits this to 5000
  • Setup an intermediate server which talks to AWS; an IAM user would be created for the server. The server then generates temporary credentials on demand for the embedded devices, and the devices use this to authenticate with AWS. I don't like this because it introduces an additional dependency / single point of failure (the intermediate server).

What other options do I have? I am sure I'm not the first one to face this problem.

  • 1
    Is there a reason that you do not want to use AWS IoT? This service is designed exactly for what you are trying to do. All your questions regarding users and permissions are handled with certificates which provides for solid security for your devices. – John Hanley Apr 26 '18 at 20:21
  • Yes, there are reasons, but too elaborate to discuss here. BTW you say that IoT is "designed exactly for what I am trying to do" but I didn't say anything about what I am trying to do. Only that the devices need to send push notifications using SNS. Obviously that's not the only thing they do. – Grodriguez May 7 '18 at 16:23
  • You wrote: "Large number of cloud enabled devices" gives a hint. – John Hanley May 7 '18 at 18:28
  • Another service to look at: AWS IoT Credentials Provider. I have not yet worked with this service as it was just announced. aws.amazon.com/blogs/security/… – John Hanley May 7 '18 at 18:29
  • What type of embedded devices? If you mean Apple or Android this is easier, if you mean custom hardware devices then you need to really clarify this. – John Hanley May 7 '18 at 19:47
2
+100

You could do something like this: Secure Authentication Flow

Pre-requisites and Setup:

  1. Install the Javascript SDK on your embedded device (since you haven't mentioned limitations of the device, this architecture assumes your device is capable enough of running the Javascript SDK)
  2. Create a 'User Pool' within Cognito (either through the AWS Console or API, CLI etc.)
  3. As part of the initial device setup, sign up a new user per device using unique attributes that align with your architecture, intended app audience and business model

Authentication Flow:

  1. When you want to push a new message to SNS, the following things take place:
  2. Your application (on the embedded device) initiates a Secure Remote Password Authentication with Cognito (via SDK methods, of course)
  3. If the authentication request succeeds, Cognito responds with a token
  4. Your application uses the token and calls a POST Endpoint exposed by API Gateway and authenticates with the token received in Step 3
  5. The token is used to authenticate against the 'User Pool' on Cognito to verify if the request came from a genuine device
  6. If the authentication request succeeds, API Gateway invokes a Lambda Function that has an appropriate IAM Role attached to it, this IAM Role essentially allows it to publish messages to SNS Topics
  7. The Lambda Function publishes the message to the desired SNS Topic. Since you mentioned that each device will publish to its own SNS Topic, the information about the SNS Topic can be stored in user metadata fields within Cognito
  • Looks good. But is there any reason why I should specifically use the Javascript SDK? I guess I can just use any of the available SDKs (or even no SDK if I can just make HTTP requests) – Grodriguez May 14 '18 at 7:52
  • @Grodriguez: Just that the SDK acts as a good wrapper, you could always call the relevant REST APIs in case SDKs are a no-go! – Abishay Rao May 15 '18 at 8:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.