I have two AWS accounts - let's call them "sender" and "worker". Sender has the 10 digit long code (10DLC) set up and it works for sending SMS. Worker determines when a notification should be sent and publishes to SNS.
How can SNS in the worker account leverage the 10DLC in the sender account?
The worker currently is unaware of any origination numbers (10DLC), and therefore cannot send.
The AWS documentation is very unclear on this : https://docs.aws.amazon.com/sns/latest/dg/sns-settings-sms-crossaccount-10dlc.html . It appears to only address the scenario of a logged in user account performing the send operation from the console. At that, it switches to the sender account in order to do it.
I'm aware of this question:
AWS 10DLC cross account
, but in it a lambda function specifies the originating number. In my scenario there are many subscribers to an SNS topic, and the sending function shouldn't be aware of the 10DLC configuration.
I have tried to perform the actions described in the AWS doc link above. It does nothing to permit adding new SMS subscribers, since there is no known origination number.
You can leverage the 10DLC number in the sender account by having the worker assume a role in the sender account (meaning that it temporarily becomes the sender account) and then calling SNS publish from there. Since the service sees this message as coming from the sender account, it will be able to leverage the 10DLC.
If your goal is to add subscribers to an existing topic in the sender account, the same method can be used.
So, you might have an IAM role called SMSSender in the sender account. This role needs to have permission to access SNS and publish, create subscriptions, etc. depending on your use case. The worker then leverages AssumeRole to use this role (becoming the sender account) to execute the operation.
Related
The way I understand Firebase Cloud Messaging at the moment, I will want to save all FCM tokens a user might have across devices to my backend and send a notification to all of these tokens at once when I want to notify that user about something.
Multiple tokens
Until this point, I assumed that each device only has one active token, however, reading this section of the documentation:
To enable this feature, make sure you have each sender's sender ID. When requesting registration, the client app fetches the token multiple times, each time with a different sender ID in audience field, using the token retrieval method for the given platform
Does this mean that I might need to target multiple active tokens per device?
Deletion
And now coming to the really important question. A simple solution to the above problem would be to simply store every token I ever retrieve in the backend and thus ensuring that my user will always receive the message.
However, what do I do if the user signs out of my app using Firebase Authentication, i.e. a different account is used in the same app on the same device?
I assume that the tokens I sent to my backend for this device will still be active - so now this user will receive notifications from another account because that account was signed in on the device previously.
I do have access to the current FCM token and I could delete that from my backend before signing out the old user, but considering the "Multiple tokens" section: how do I make sure that I can delete all FCM tokens of the old user from my backend?
Uniqueness
Additionally, assuming that old tokens are just dead for the device (will not trigger notifications anymore) when new ones are generated, can I be sure that this token will never be assigned to another device in the future?
TL;DR
How can I make sure that I have the correct FCM token(s) for my user stored in my backend and more importantly: how can I ensure that no tokens of other users are saved for some user in my backend?
I read through:
https://stackoverflow.com/a/40158260/6509751
However, I still do not know how to deal with multiple tokens.
Does this mean that I might need to target multiple active tokens per device?
An application has a single active token for each sender ID. It's fairly uncommon to have multiple sender ID, and you'd usually know if if you do. If you're sending from a single back-end, there's usually no need for having multiple sender IDs.
I am getting account level notifications from Amazon SNS. But I am not getting event publishing notifications.
I set up configuration set and gave sns destinations as endpoints. In account level notifications we get bounces, complaints and delivery notifications. But I want open and click tracking for emails. So I created event publishing events. I am giving configuration set name while I am sending email.
Do we need to set sender email as AWS account email or we can any verified email?
Is there any way troubleshoot that configuration set is passing or not?
i'm thinking about using Firebase for the notification service that my app needs. However, its important that the process of sending notifications is secure. I want to avoid a notification being sent from any member of the team without permission.
One way could be assigning restricted roles and permissions for the team members. However it also would be good to have any kind of activity log in the console, or have a log of all notifications sent including the name of the user. The console currently allows you to see all notifications sent, but i cannot see who sent it, and also the notification can be deleted from the log.
Any ideas on how to manage this? Which specific roles would you recommend me to use? Is it possible with Firebase?
You could write a function in Firebase which sends notifications, and you have logs on that function. Here is how to write a function which send notifications
As part of our solution, we want to deploy an FCM "app server" at each of our customer sites. Each customer site has their own users with their own devices using our app. However, we want to make sure that if one of the customer sites is compromised, an attacker could not abuse the FCM "app server" (e.g. by sending notifications to all devices at all customer sites).
Instead of sharing credentials between all customer sites, we are thinking of generating a unique server key for each customer site. That way if one customer site is compromised, we can disable that server key and stop any more FCM notifications from being sent.
Question: Can we be sure that an attacker cannot send global notifications to all devices?
Assuming an attacker has a server key and access to one customer site "app-server", can they get a list of all the registered devices?
Is there a default notification "topic" that is sent to all devices? (e.g. /topic/all or /topic/global). If so, can we disable that default topic?
Instead of sharing credentials between all customer sites, we are thinking of generating a unique server key for each customer site. That way if one customer site is compromised, we can disable that server key and stop any more FCM notifications from being sent.
If by "we are thinking of generating a unique server key for each customer site" you mean that you'll simply create a Firebase Project for each customer site, then I think this is the correct approach.
Can we be sure that an attacker cannot send global notifications to all devices?
An app can receive messages from a different Sender by implementing the getToken(authorizedEntity, scope) which will generate a different token for each Sender. In order to negate this action, you could simply call deleteToken(authorizedEntity, scope) (my reference).
This would invalidate the token for that corresponding sender (which is what they probably have and should be the only one on their App Server), which would automatically disable them for receiving messages to your App.
So as long as you're able to remove them as a valid sender from your app, then it's all good.
Assuming an attacker has a server key and access to one customer site "app-server", can they get a list of all the registered devices?
This depends on how the App Server is implemented. If the customer's App server is only used for sending messages, but the tokens are stored elsewhere, then probably no. There is no API to retrieve registration tokens on the server side for an App based on the Server Key (see #1 here).
Is there a default notification "topic" that sends to all devices? (e.g. /topic/all or /topic/global). If so, can we disable that default topic?
There isn't. There is the option to send a Notification to a specific app via the Firebase Notifications Console, but if the app doesn't authorize the Sender ID corresponding to that project, it won't receive any messages from it. I've tested this behavior out before posting, so I'm positive that this is how it works.
There is no way to restrict a server key to only allow certain topics/devices/etc.
I would consider using Cloud Functions for Firebase to solve this a different way. You could build an HTTPS function that took per-site authorization tokens (by any means you deem fit) and then that function calls through to Firebase Cloud Messaging to actually send the push notifications.
This way, you have complete control over what kinds of push notifications can be sent by the "client" sites, and you don't have to worry about cascading security problems in the event a client site gets compromised.
We are using Elastic Beanstalk to serve a REST API. Now, I want to develop an endpoint that serves notifications from an SNS-topic in an asynchronous way.
In order to receive those notifications, I need to subscribe the API-servers to the SNS-topic. How could I do this, with the scenario in mind that the EBS application can scale up to multiple servers and scale down again? I don't want a lot of dead links subscribed to the SNS-topic...
In spring world we have a #PostConstruct which gets called on server startup, where you can subscribe "this.server" url to a given topic (you may need to build a proper working subscription url --using InetAddress et el).
Hence there is the working subscribe url using #RestController which confirms such an subscription instantaneously causes sns endpoint to be registered. Any new servers will do the same aka getting registered themselves (when new stack is created). We also need additional code for the consumption of notification messages subsequently and do something when confirmed subscription endpoints receive one.
The way AWS wants you to use SNS is not by directly subscribing to it. Any notification which need to trigger something in a component should buffer notifications with an SQS queue. For this reason we chose to do Pub-Sub with a variable/scalable group of Subs using the Amazon managed Redis distribution.