In Google Cloud Messaging, one of the options available on the push API key was to restrict senders to specific IP addresses (whitelist). This allowed you to dedicate a group of push servers, and prevent machines with other IPs from sending pushes to GCM.
Does Firebase Cloud Messaging have the same or a similar option? I'm not able to find it, and it seems to have gone down the memory hole. If it has the option, how would you configure it?
The Firebase Cloud Messaging REST API to send messages is open to all callers. The authorization options are described here. As far as I know there is no direct way to limit usage of the API to specific IP addresses.
Related
Users of ours running their code, on premise, access data we provide them via GCP's BigQuery API. It's a REST API with a client library wrapper.
We want to protect access to the BigQuery API backend with a firewall (in order to whitelist client IP's etc). What are the best options, preferably some GCP solution? Reading Google's documentation it's not clear if I can include the client's IP address in a GCP VPC, or if there's another way of doing it. Cloudflare also seems like an option, but I'd prefer to use a GCP offering.
I have built an API to my web application so that customers can access certain functionality without going through the dashboard. I have secured it by providing an API key to each customer that identifies them and restricts the IP address from which they can connect.
I have now had a request from a customer to allow them to access this API from their Salesforce platform. I don't know much about Salesforce, and when I asked them to let me know their IP address so I could create their API key, all they could give me was the list of reserved IP addresses published by Salesforce. This IP space is huge (millions), covering all of Salesforce, meaning that if someone gained access to the API key they'd be able to use it from any Salesforce account.
I have read some things about Salesforce having an OAuth service and having some kind of Application Connect service, but it mostly seems to be designed around allowing 3rd parties to connect to Salesforce - I'm getting a bit bogged down trying to determine if this is any use in my scenario (which requires authentication in the other direction).
I'd be grateful for any insight into whether there's something more specific I can do identify a particular Salesforce customer beyond simply putting dozens of CIDR blocks in my API key. I could ask my customer to identify themselves in the referer header when they call my API, for example, but of course that's trivial to spoof.
Thanks.
IPs can be spoofed too
Salesforce has a concept of "protected custom settings". You could make a "managed package" (Salesforce plugin, but you don't need to distribute it on their appexchange, Google Play/App Store equivalent), install it for the client and then enter the API key to the setting in a way that even client's sysadmins can't read it.
It'd be bit of work to set it up but might pay off if you think you'll get more customers on the platform.
How about a crude but effective iframe? or a link to your page they'd embed somewhere in their app?
Do you have just api keys? If you'd expose OAuth2 endpoint SF users could login to your app and then SF code could use access_token they got back instead of api keys. Or maybe you can protect access with certificate? Calling app would have to sign requests with a certificate. Client could upload it to their SF, you'd upload to your app...
You could demand the API calls to include the user's SF "session id" and you could use that to run some queries against source SF org. Org Id, user's login history etc things that are impossible to tweak even by sysadmins...
I am trying to configure Gmail API in a way so I can pull the inbox messages as well as respond against them. Basically, I am implementing a CRM and this one of the modules of that CRM. I got an email from Gmail verification support telling me that this needs to undergo a security assessment if your application can send Google suer data from a restricted scope to remote servers. For third-party security assessment, they mentioned that it may cost from $8,000 to $75,000. Is there some other way to tackle this? This is too much!
Is it possible to disallow topic subscriptions to wildcards in ActiveMQ 5 (classic)?
E.g. subscribing to > will broadcast all messages to all consumers even if a consumer should not be able to subscribe to all topics (and isn't even aware of all topics).
I already tried to create <authorizationEntries> with the <authorizationPlugin>, but wasn't able to prohibit wildcard subscription.
Do you have any ideas how to completely wildcard subscription or message forwarding to wildcards for specific / all users?
As hashed out in the comments you are approaching this problem from the wrong direction. Rather than trying to disable wildcard subscriptions the correct approach is to limit what topics will actually be delivered regardless of what is subscribed to.
This is done by setting an appropriate ACL for each user (reusing the same credentials for 500k clients is a REALLY bad idea).
ActiveMQ uses a plugin based system to supply Authentication and Authorisation control based on the Java standard called JAAS. With JAAS you can plug nearly any storage mechanism (e.g. database, LDAP,...) into ActiveMQ to store your user/password details and the ACL of what topics they can access. Details of how to use JAAS with ActiveMQ can be found here
I am building a bot that will interact with the Google Hangouts Chat API. I need to punch a hole in my firewall to receive incoming HTTPS requests.
Is there a subnet I can expect Google to send requests from? I would rather not open the bot to the entire world.
For organizational reasons, we cannot use pub/sub endpoints. We just need an ip or ip range from google to whitelist