We are currently developing a cloud solution that would require 2000+ clients to publish events (1-2 per second) into an Event Hub. We built a prototype that gives each client a Shared access policy (Authorization Rule), and creates a SAS token with a publisher policy as defined here
We thus are able to identify the publisher of each event by inspecting the x-opt-publisher system property, and to revoke access to the Event Hub for each client at any time, without having to resort to token expiry and renewal.
However, we recently learned that the maximum amount of SAPs / Authorization rules is 12, so this solution ultimately will not work.
Is there another solution to this problem? Our goals are:
Avoid having to use token refresh, as this would require adding code to all clients.
Being able to revoke access to the Event Hub instantly in case a client either gets compromised, misbehaves, malfunctions due to a bug, or the associated customer's contract is terminated
Avoid having to use a frontend service authenticating the clients, as we are talking about a substantial additional system load (5000 requests per second)
Avoid having to use IoT hub, as the costs are far higher than with our solution, and we do not need all that functionality
Thanks in advance
You don't need to create a dedicated SAS policy for each device or publisher. Please note that a publisher should only own a token signed for itself and should not be able to access the SAS policy key.
Feel free to check the publisher policy document here for more details.
Related
I have an application (Java Spring backend + iOS/Android native frontends) that uses AWS Cognito for Authentication and AWS SNS for sending push notifications to devices. The client apps currently pass the device-specific push tokens (FCM, APNS) to the backend, which informs SNS.
We are struggling to figure out the best way to deal with users logging out or simply not using the mobile apps for a while, and expiring/disabling those push tokens. Cognito does not appear to have any sort of trigger or notification for when a token expires or a user signs out. This leads to users still receiving app pushes after logging out or when their access/refresh tokens have expired.
I am looking for suggestions and best practices on what to do here. Some options we entertained are to inform our backend in a separate call, move all device management there, or even façade all of Cognito behind our own backend calls, but maybe there’s better ways.
last month they released refresh token revocation, is a way to revoke a refresh token and all access tokens that were previously issued by that refresh token become invalid
this is enabled for new user pools but i believe in your case, you need to manually enable it in (e.g. you created the user pool before the feature was released)
Cognito does not appear to have any sort of trigger or notification for when a token expires or a user signs out.
you are correct here, but, in case you use GlobalSignOut API in your App, you could track it via CloudTrail or EventBridge and trigger a lambda do to something with the event
Some options we entertained are to inform our backend in a separate call, move all device management there, or even façade all of Cognito behind our own backend calls
i worked in both scenarios, while the façade gives a lot of flexibility, if you are offering social login, it is annoying to setup the whole oidc flow,
in my projects i usually use cognito as an user directory to generate unique user ids and integrate with other aws services.
like DynamoDB with item-level control based on the Cognito User Id, which is handy:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_items.html
https://aws.amazon.com/blogs/mobile/building-fine-grained-authorization-using-amazon-cognito-user-pools-groups/
making it easy to create and manage user devices token etc
but maybe there’s better ways.
hope never dies 😆
I am working on an assignment where our customers will sync their crm data to our systems. The sync will be ongoing process. Any best practices or suggestions on google pub/sub for sharing one of our existing (or a new one) topic that our customer will publish too and we consume? Idea here is to keep sync asynchronous.
#Alex-hong is true if your customer is on GCP. If not, you have 2 solutions:
You can generate a service account and send it the JSON key file. Define the right role on the service account (as described by Alex) and let your customer use the Service Account and to publish to the PubSub topic. This solution implies an important development by your customer (Use external JSON key, use new libraries to push messages,...)
You can deploy a Cloud Function/Cloud Run endpoint and let your customer to simply perform an HTTP request. Of course, you can secure the call with Basic Authentication or APIkey (or something like that, that you check in your Cloud Function). The function only check the security and publish to PubSub. It's often simpler and more standard for your customer.
On the last point, it could be possible to set up an ESP in place of the function, but I never tested for publishing directly to PubSub.
You can give the other party the roles/pubsub.publisher role for your specific project if you own the topic. Alternatively, if they own the topic, they can grant you the role roles/pubsub.subscriber which will let you subscribe to that topic.
For more information, see Access Control
I am designing a product which would be deployed to AWS. It will use Cognito for user authentication. It will be a multi-tenant application.
The application has many modules/features. The pricing depends on the features selected by the client.
Please provide guidance on how can I implement a check if the feature is licensed or not. I don't want to put the logic inside each web api endpoint.
You should create an application microservice (callable via a API, but with access locked down to your own application) that receives information such as:
Authenticated User ID
Service wanting to be accessed
Resource-level information in case you want fine-grained access control
The authentication microservice would consult a database, apply appropriate business logic and return a success indicator.
Preferably:
Each request should be logged in an audit trail
If access is denied, return an error message that could hint at the reason why (eg 'This feature is requires subscription to the XYZ module')
Use some form of cache to make the queries super-fast (eg DAX for DynamoDB, or ElastiCache)
Licensing systems can often be more complex than actual applications!
We have lot of applications created under Amazon AWS-SNS to send a push to apple devices.
While creating each app we are uploading p12 files, even every application's has p12 expiry date in the next year our applications getting expired(disabled), Due to this push is not going to endpoints which are saved under the same application.
Could any one please help me that what are the various reasons which caused Application ARN disabled? Thank you in advance.
sometimes the device token changes. Then, if you're trying to use an endpoint associated with a invalid token, SNS will disable it.
Even if you enable it again manually, SNS will be informed that this endpoint is no longer available and will disable it again.
This may help you:
Re-enabling an endpoint associated with an invalid token
When a mobile platform (such as APNS or GCM) informs SNS that the token used in the publish request was invalid, SNS disables the endpoint associated with that token. SNS will then reject subsequent publishes to that token. While it may be tempting to simply re-enable the endpoint and keep publishing, in most situations doing this has no beneficial effects: the messages published don’t get delivered and the endpoint becomes disabled again soon after.
The reason for this is that the token associated with the endpoint is genuinely invalid. Deliveries to it cannot succeed because it no longer corresponds to any installed app. The next time it is published to, the mobile platform will again inform SNS that the token is invalid, and SNS will again disable the endpoint.
To re-enable a disabled endpoint, it needs to be associated with a valid token (by using SetEndpointAttributes API call) and then enabled. Only then will deliveries to that endpoint become successful. The only time re-enabling an endpoint without updating its token will work is when a token associated with that endpoint used to be invalid but then became valid again. This can happen, for example, when an app was uninstalled and then re-installed on the same mobile device and received the same mobile token. The approach presented above does this, making sure to only re-enable an endpoint after verifying that the token associated with it is the most current one available.
You can read more here: Mobile token management with Amazon SNS
To avoid issues with .p12 certificates expiring, you may now use .p8 tokens for APNS in Amazon SNS. Check this out: https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-sns-token-authentication-api-mobile-notifications/
I am wondering whether it is possible to implement a Cloud Foundry-hosted service that other CF applications can subscribe to, with the following requirements, and (more or less) within the existing CF facilities...
The context of the question is converting an existing CF Java based appication to a reusable service that can be deployed only once and reused by other (mulually unrelated) applications, instead of every application (or application set) having to incorporate a privately deployed instance of the service.
In a nutshell, subscribing applications should be able to store their data in the service, and interactive users to access this data. (An example of the data could be messages for a particular user, work items etc. sent by the subscribing applications, and the service is responsible for aggregating them on per-user basis and displaying to a logged-on user the summary of data targeted at him.)
Thus, requirements would be:
CF-hosted applications should be able to dynamically subscribe to (and later unsubscribe from) the service.
Subscribing applications may either share or have different identity providers (IdP's) and UAA instances.
The service has two kinds of endpoints:
endpoints intended for app2service (REST etc.) calls by the subscribing applications
endpoints intended for interactive access by users registred in the IdPs of the subscribing applications
Service's interactive endpoints are (preferably) protected by scopes. It must be (preferably) possible for the service to export its scope definitions to the UAAs of the subscribing applications (or rather for subscribing applications/UAAs to import them at the time of design, deployment or subscription), and for the administrator of a given UAA to assign service-defined scopes to appropriate users registered through this UAA/IdP combo (i.e. one associated with the subscribing application).
4.1. At the barest minimum, interactive endpoints may be left unprotected by scopes, but they should require and trigger authentication (e.g. having "intercept-url access=isAuthenticated()" in their Spring security descriptors). The servlet should be able to retrieve JWT token and identify the user making the request.
There should be a way for a service to associate between userid namespaces and subscription ids.
Two different subscription contexts associated with two different IdP's may both have user "John" but these are two different Johns.
So when user John arrives to an interactive endpoint of the service, the service needs to be able to figure out which IdP/subscription set (and hence data set) this John maps to.
Or, conversely, when a subscribed app performs an app2service call, the service should be able to identify the subscription id of the caller, in an authenticated way, and then figure out which IdP it is associated with.
Either way, it is essential that subscription mechanism provides for an establishment of a mapping between a subscription id and IdP used by a subscribing application; the service will need to know this mapping.
5.1. Not too sure how exactly things are to work out when two different UAA instances point to the same backing IdP.
Perhaps UAA can present its instance identity, but can it be made to present (in the generated JWT tokens) the identity of the backing IdP, and can the latter be signed?
Is it something that existing CF facilities provide for or that can be implemented on top of them with some ease?
Thanks.