I would like to deploy a second instance of our azure mobile service (in the US) and configure azure traffic manager so that each client will be routed to the best instance based on their DNS. This requires that a client shouldn't care which instance they get but at the moment they have to use an application key to access the service and the applications keys are different for both instances. Through the portal I can regenerate a key but I can't set it. Is there a way in which I can make this work?
Thanks
F
You can set the application and master key using command line tooling like so:
azure mobile key set <SERVICENAME> master <NEWVALUE>
You can read more about doing this here: http://chrisrisner.com/Using-the-Same-Client-Side-User-with-Multiple-Azure-Mobile-Services.
Note though that you'll need to think through how your services do data access. It's possible for each of the mobile services you generate to point to their own database (i.e. my data is in a US DC and your data is in a EU DC) but if traffic manager routes someone to a different mobile service than they usually use, their data won't be there (unless you've set up data replication). Alternately you can point multiple services at the same database (not difficult with the .NET backend, more difficult with the Node backend) though then you're dealing with at least one mobile service having to leave it's DC to access the data.
Related
We currently use Redis to store the session of one application currently running on Azure. We use it so when Azure scales the application the session is not stored locally in the application itself. We are in the process of placing another application in Azure too, and I'd like to know if we can use that same Redis instance, or if having two applications storing sessions on the same place might cause issues.
I wouldn't use different keys and the same Redis server and database. Your two web apps become co-joined twins. If one web app acts up, it can tank the other one.
If you're deploying the same web app code to two or more web apps, you could use the same Redis server but different databases within the server. Azure Redis Cache has one server, each with 16 databases. However, databases within the same server share service limits.
Or the absolute best thing to do is firewall the two web apps by using two different Azure Redis cache services.
It depends on your key. If you use a key that is only the user name. Then both applications read the same session state. You could do it by creating a composite key with the application name as part of the key.
I would use a seperate instances:
ensuring unique key names across applications adds complexity and risk
high load on one application can impact other applications
if the Redis instance goes down alle your applications fail
I have a security question related to Azure that I could really do with some guidance on the art of what is possible.
I would like to know if it is possible to restrict what services can be called (i.e what storage account endpoints can be used to write data to) from PaaS services such as service fabric or web apps (ASE). i.e. if I have a web app that writes to storage and someone maliciously altered the code to write to a third party storage account on Azure; is this something I could mitigate in advance by saying this application (i.e. this web app or this SF cluster) can only talk to a particular set of storage accounts or a particular database. So that even if the code was changed to talk to another storage account, it wouldnt be able to. I.e can I explicitly define as part of an environment what storage items an application can talk to; Is this something that is possible?
Azure Storage Accounts have Access Keys and Shared Access Keys that are used to authenticate REST calls to read / write data to them. Your app will be able to perform read / write operations against the Azure Storage Account that it has an access key and connection string for that it uses to connect to it with.
It's not possible to set any kind of firewall rule on an Azure App Service app to prevent it from communicating with certain internet or Azure endpoints. You can set NSG firewall rules with App Service Environment, but you still can only either open or close access; not restrict on certain DNS names or IP Addresses.
Perhaps you should look for a mitigation to this threat in the way applications are deployed, connection strings are managed and code is deployed:
Use Azure Role Based Access control to limit access to the resource in Azure, so unauthorized persons cannot modify deployments
Use a secure way of managing your source code. Remember it is not on the PaaS service, because that only holds the binaries.
Use SAS tokens for application access to storage accounts, not the full access keys. For example, a SAS key could be given write access, not read or list access to a storage account.
If, as a developer, you don't trust the person managing the application deployment, you could even consider signing your application parameters/connection strings. That only protects against tampering though, not against extraction of the connection string.
I am planning to have multiple azure mobile service instances, so the first requirement I have is to share the access token of authenticated user across different app instances. I found this article https://cgillum.tech/2016/03/07/app-service-token-store/ that states that right now we can not share the tokens as it is stored locally on machine, and placing it to blob storage is not recommended for production apps. What is the possible solution I have at this time?
I have read the blog you mentioned about App Service Token Store. As mentioned about where the tokens live:
Internally, all these tokens are stored in your app’s local file storage under D:/home/data/.auth/tokens. The tokens themselves are all encrypted in user-specific .json files using app-specific encryption keys and cryptographically signed as per best practice.
I found this article https://cgillum.tech/2016/03/07/app-service-token-store/ that states that right now we can not share the tokens as it is stored locally on machine.
As Azure-runtime-environment states about the Persisted files that an Azure Web App can deal with:
They are rooted in d:\home, which can also be found using the %HOME% environment variable.
These files are persistent, meaning that you can rely on them staying there until you do something to change them. Also, they are shared between all instances of your site (when you scale it up to multiple instances). Internally, the way this works is that they are stored in Azure Storage instead of living on the local file system.
Moreover, Azure app service would enable ARR Affinity to keep a client subsequent requests talking to the same instance. You could disable the session affinity cookie, then requests would be distributed across all the instances. For more details, you could refer to this blog.
Additionally, I have tried to disable ARR Affinity and scale my mobile service to multiple instances, then I could always browser https://[my-website].azurewebsites.net/.auth/me to retrieve information about the current logged-in user.
Per my understanding, you could accomplish the authentication/authorization by yourself to use auth middle-ware into your app. But, this requires more works to be done. Since the platform takes care of it for you, I assume that you could leverage Easy Auth and Token Store and scale your mobile service to multiple instances without worrying about anything.
So I have a mobile app that uses AWS's IAM infrastructure that effectively allows me to provide temporary access tokens to anonymous mobile devices, so that they can run queries against AWS services directly from the mobile device.
Does anyone know if Windows Azure has a drop in replacement for this sort of thing too? I've read about Windows Azure Access Control but all examples seem to focus on allowing authentication via the likes of Facebook, Twitter or Windows Live etc. In my case, I don't want the mobile user to have to "log-in" anywhere, I just want them to be able to access Azure services such as table storage, without having to go via my server.
Thanks!
You do have the ability to create Signed Access Signatures for all three Windows Azure Storage services (BLOBs, Queues and Tables) as well as for Windows Azure Service Bus Brokered Messages (Queues, Topics & Subscriptions). These SAS urls are temporary and you can create them ad-hoc with expiration times. After that time expires the device would have to request a new one, likely from your server. This reduce the load as they aren't coming back all the time, but you do still have to run something that will gen these SAS uris for the devices. You can generate SAS manually against the REST API direct, or you can use one of the SDKs to generate them for you (which also hit the REST API).
Note that when you create a SAS you have the option of doing so as a Policy, or adhoc. A policy allows you to revoke a SAS at a later time, but you can only have so many of these defined at a time (likely too big of a restriction for a mobile scenario if you are doing by device). The adhoc approach allows you pretty much as many as you need (I think), but you don't have the ability to revoke it, it just has to expire.
Another option is to look at Windows Azure Mobile Services. This service runs on servers managed by Microsoft and you can use it to get at just about anything you want. You'd want to look at the "Custom API" feature. Also, make sure you understand the pricing model of mobile services (or really, that stands for any option you decide to go with).
It's called managed identities in Azure
I need to to deploy 2 different worker role instances but each needs it's own configuration data (ID code, password, SenderCompID, etc.) to connect to a trading server. I can't share the credentials across the instances.
Each instance for any role (Worker or Web) are identical in terms of application based configuration. This is because all the instances are created from the same application will read exact same application configuration data.
If you write your application in a way that when application starts it reads data outside the machine (from azure storage, azure table or anything else outside the VM, mostly available on some server) and then configure itself then you could achieve your objective. You also need to provide instance specific data on server so each instance gets its own data. If I choose this option, i might use Azure table name i.e. Instance_ID# so each instance gets its own configuration and configured itself. This way I can modify the data any time on Azure Table and restart the role to load updated configuration. Other may have some other way to make it happen.
The other option is to have two role (worker or web) in same Azure application and while application code could be same in between two or more worker roles however you sure can configure them separately. Each of above options have its own pros and con.