Azure App Service Custom Domain limitation - azure-appservice

We work with Azure App Service and custom domain feature to set the websites of our clients to our App service (with appropriate SSL for sure) The limitation of custom domain seems to be 250 or 500? Someone has the truth? We products is a SAAS and the growth of our business depending to.
Thank you

The number of custom domains per app is 500. See this doc for all limits per App Service Plan tier.

Related

How to restrict access to a small user community (IAM users) in GCP / Cloud DNS / HTTPS application

I have a request to restrict the access (access control) to a small user community in GCP.
Let me explain the question.
This is the current set up:
A valid GCP Organization: MyOrganization.com (under which the GCP project is deployed / provisioned)
Cloud DNS (To configure domain names, A & TXT records, zones and subdomains to build the URL for the application).
Oauth client set up (tokens, authorized redirects URIs, etc.).
HTTPS load balancer (GKE -managed k8s service- with ingress service), SSL certificate and keys issued by a trusted CA.
The application was built using python + Django framework.
I have already deployed the application (GCP resources) and it is working smooth.
The thing is that, since we are working in GCP, all IAM users who has a valid userID#MyOrgnization.com can access the application (https://URL-for-my-Appl.com).
Now, I have a new request, which consists in restricting access (access control) to the application only for a small user community within that GCP organization.
For example, I need to ensure that only specific IAM users can access the application (https://URL-for-my-Appl.com), such as:
user1#MyOrganization.com
user2#MyOrganization.com
user3#MyOrganization.com
user4#MyOrganization.com
How could I do that, taking into account the info I sent earlier ?
thanks!
You can use Cloud IAP (Identity Aware Proxy) in order to do that.
Identity-Aware Proxy (IAP) lets you manage access to applications
running in App Engine standard environment, App Engine flexible
environment, Compute Engine, and GKE. IAP establishes a central
authorization layer for applications accessed by HTTPS, so you can
adopt an application-level access control model instead of using
network-level firewalls. When you turn on IAP, you must also use
signed headers or the App Engine standard environment Users API to
secure your app.
Note: you can configure it on your load balancer.
It's not clear in your question if your application uses google auth (but considering that you talk about org-restricted login I think so) - if that's the case you should be able to enable it without virtually touching anything in your application if you are using the Users API.
The best and easiest solution is to deploy IAP (Identity Aware Proxy) on your HTTPS Loadbalancer
Then, grant only the user that you want (or create a gsuite user group and grant it, it's often easier to manage)

Scale out Microsoft bot framework app in multi region environment

I am setting up the MS Bot framework service environment in Azure. I was able to successfully set up the channel which connects to single bot service for a single app. Now, we would like to scale this environment globally (all over the world) and we would like to setup multi-region environments. When a user connects from the channel app (MS Team) then they should be able to connect to their nearest Azure region and get the response back. How can we set up the geographic load balancer for Microsoft bot framework web app bot service?
We tried to set up the traffic manager however we have constraint since Microsoft bot channel registration service has Microsoft APP ID (ClientID) and Password and it can only connect to only one messaging endpoint URL
Actual results:
Microsoft Bot channel registration app cannot connect to more than one messaging endpoints of the different region and how can we load balance MS Bot Service.
Expected results:
How can we load balance (latency by region) MS Bot Application?
Sample Scale out diagram
Amit,
Azure bots typically run as Azure App Services. The Azure App Service has built in scaling capabilities. Depending on the pricing tier you select for the App Service, you can scale out to as many as 20 instances. You can go to 100 instances if you're in an 'Isolated' tier. You can also scale up to add memory and cpu. That's some really powerful resources you can bring it to.
I realize that you're trying to reduce latency but I wanted to point the scaling feature out first. You have another challenge I don't think if possible to overcome at this time.
If MS Teams is the only channel you're users will be using, then trying to manage traffic on your own is probably going to be ineffective. You're constraint is going to be where the MS Teams service is located. Teams is what's talking to your bot, not the user directly.
The path is something like this:
User -> MS Teams -> Azure Bot Service -> Azure App Service.
Since you have no control over the Teams to Bot connection, you cant manage the traffic.
You could deploy multiple bots to different regions, then instruct your users to connect to the appropriate regional bot channel in Teams. This isn't an automatic traffic management but would at least provide some of the region support you're looking for.

How to setup Azure web service for Dynamics 365

Good morning everyone,
My apologies if this post is too similar to this post:
Dynamics 365 and Azure integration
but I am struggling to understand exactly what is needed in order to setup a web service on an Azure server that is consumable by a Dynamics 365 plugin. Based on my research it appears that it goes as follows but I would like to see if any knows of a better guide.
1.) Construct the web service as normal on the Azure Windows Server.
2.) Register a proper DNS Domain name (friendly-name) and route it to the Azure server.
3.) Secure that Azure server/URL with a certificate.
4.) Call the web service from my C# Dynamics 365 plugin.
Is that everything or might I be missing something critical? Thank you!
4 might be an issue, given you want to use certificate based security, not sure that will work, you might need to use another mechanism, e.g. basic user name and password. Otherwise looks okay.
Plug-in isolation, trusts, and statistics
Web access
Sandboxed plug-ins and custom workflow activities can access the
network through the HTTP and HTTPS protocols. This capability provides
support for accessing popular web resources like social sites, news
feeds, web services, and more. The following web access restrictions
apply to this sandbox capability.
Only the HTTP and HTTPS protocols are allowed.
Access to localhost (loopback) is not permitted.
IP addresses cannot be used. You must use a named web address that requires DNS name resolution.
Anonymous authentication is supported and recommended. There is no provision for prompting the logged on user for credentials or saving
those credentials.

Can a Windows Azure Mobile Service accept GET requests from any domain?

I have a PhoneGap App running on WP7 that I would like to connect to a Windows Azure Mobile Service. However, in order for this to work in my testing using JSFiddle.net I had to add the JSFiddle domain to the CORS settings in the Windows Azure Mobile Service.
Why do I need to add domains to the CORS setting on the server when doing a simple GET?
Since the Mobile Service requires a key from the JavaScript code I don't see why I cannot open up this web service to any request that supplies the correct key but adding . does not seem to work. If this worked I could move on to testing the scenario on the Phone.
Am I missing something architecturally here or is this just a feature that no-one else is looking for?!
If you want to allow any domain to access your mobile service, you can add the * in the list of cross-origin resource sharing hostnames under the configure tab.
Notice that the application key is not secure. From the 'How to use an HTML/JavaScript client for Windows Azure Mobile Services' tutorial (emphasis mine):
Application key: A unique value that is generated by Mobile Services, distributed with your app, and presented in client-generated requests. While useful for limiting access to your mobile service from random clients, this key is not secure and should not be used to authenticate users of your app.
The takeaway is that you should not count on that key to secure your service.

Appfabric Azure

Real application how can i use this app fabric ??
How can i put my business logic in this and this logic use in my windows azure application??
Thanks
The Azure AppFabric is a collection of services that allow to you leverage functionality traditionally provided on premise by infrasture components common to most networks. Currently, it consists of the following:
Azure AppFabric Service Bus - allows for connection of applications by providing a centralized relay point in the cloud. Applications create outbound connections to the rendezvous location, thus helping mitigate the challenges posed by security measures like firewall restrictions on in-bound connections and IP masking via NAT layers. This feature includes both 'real time' options as well a 'message buffer' dynamic to allow for more disconnected style communication.
Azure AppFabric Access Control Service - the "ACS" allows WIF applications to quickly access various identity providers and consume a single format of claims token. Used in conjunction with products like ADFS, it allows cloud hosted applications to authenticate against on-premise identity stores.
Azure AppFabric Cache Service - currently in public testing, this service brings the "Velocity" style functionality to applications. This provides them with a distributed cache system as well as a new session provider.
There's more features/services coming in 2011, but these are the hot ones currently. Regarding hosting your business logic, this is not something that is currently available in the Azure AppFabric. There's been mentions that we may eventually see the potential for placing applications "on the edge", meaning the servers that front the Azure AppFabric connections, but no ETA or even firm commitment that this will happen.
You can implement your business logic in Windows Azure, in a web or worker role depending if you need it to be synchronous or asynchronous.
You can surface the business logic using the service bus, though you could also implement your logic on premise and surface them via the service bus.
AppFabric is not a business logic layer. Think of AppFabric as cross-cuts, or glue between different parts of your application.
For now Business logic goes in components like a web or worker role, or an on premise app which you could expose on the internet using AppFabric Service Bus.
In a future release, AppFabric will release "Composite Apps" which in a nutshell seem to allow you to deploy managed WCF/WF workflow services, which makes for a better "business engine". But for now I think you could probably just use Workflow services in a web role.

Resources