So i'm in the middle of defining the architecture for an application I've been waiting to start and have hit a bit of a bump. I 'm having a bit of a hard time figuring out how to handle multi-tenancy in conjunction with Top-Level domains.
Here's the gist of what I am trying to accomplish:
Users can come to the site and register for an account, when they register they can set up the application to use their own registered domain name. I'm not handling registrations (but do provide good instructions on how to register and point the domain for most Domain Registration companies) just the application end of it.
What I am having a hard time figuring out is how sites like Wordpress.com and Typepad handle the multi-tenancy at the application level.
So say a request comes in for www.test.com/ it reaches my multi-tenancy application but how do I serve the correct site? do I pull the headers from the request and serve a site based on that.
For instance if you were using Apache as your web server for your application, there's no way you would be adding virtual host config to apache every time a person registered for the application with a custom domain. So they have to be handling it programmatically but I can't seem to find any resources that are clear about how to handle the multi-tenancy of top-level domains at the application level.
General idea is not that difficult. When request gets to your application you have to parse url and get some tenantID from that. Similar question in asp.net mvc 3 was asked on question. You'll find my answer there with solution in our application. On sites like wp or similar i believe that proxy is adding some http header data to request so the application layer already gets tenantID.
Related
I would like your feedback and opinion about using { FrontDoor + Appservices + Authentication + restrict access to FD only }
I do confirm I can set up all of this thanks to all contribution/ forums / blog found on the net. I can use my custom domain which request AD authentication and I am correctly redirect to my appservices (in browser: I see my custom domain name and never see any *.azurefdnet or *azurewebsites.net as expected).
The only problem is that I needed to use a custom domain to make it works. For production purpose it is acceptable to have a custom domain but for dev or test I wonder if we can do it without custom domain by simply keeping original address like *.azurefd.net and *.azurewebsites.net
I struggle to make it works without custom domain. I keep getting “too many redirection” message or ‘403 sites blocked’.
Does anyone success to do it ? My general configuration looks like
My backend is linked with my appservices
Details of my backend is:
I think my problem is with BackendHostHeader but not sure. When i used custom domain for my production it works. But remind i do not want to use custom domain for dev and test.
My route looks like
And finally my appservices is secure to allow frontdoor only
When my user goes to stackoverflo.azurefd.net they get AD authentication which is good but just after i get redirection to xxx.azurewebsites.net with 403 forbidden (which looks normal because of restriction to FD only).
I tried to change the backend host header by replacing by FD value but in this case i get a error with loop redirection.
Is it a feasible scenario without custom domain ?
Regards
PS: i configured Azure ADApp to allow reply url to my FD like stackoverflo.azurefd.net/.auth/login/aad/callback
Yes, you can Restrict the access to website without using Custom Domain.
Goto the Application you want to restrict the access in Azure Portal and select the Networking from left Pane, now click on Access Restrictions.
For complete information you can go through this Microsoft Documentation.
In essence, only allow requests/responses to/from Azure Front Door. There are different options, however, I'm having trouble finding details on implementation and best practices. I think the proper solution would be to create a Virtual Network to use to integrate the two services.
One nuance exists, the Web Apps have staging slots that may require a different solution since they use Azure Active Directory to prevent public access to pre-production.
I found a little more insight here, but still found it a bit confusing.
It seems that if I have a custom domain with subdomains with Front Door, there should be an easy way to prevent direct access to the backend addresses of the Web Apps and only allow through the custom DNS and Front Door.
This was helpful, however, I'm still getting 403 from the Front Door, so I must be missing something in how to configure.
Middleware? This also was helpful, but seems to indicate it can only be accomplished by middleware and I'm running Node/Express not .NET Core. Is it true, it can only be accomplished through middleware code?
This also mentions the same details.
What is missing? How to configuration this across different application stacks.
The documentation is inaccurate when it states
< To lock down your application to accept traffic only from your specific Front Door, you will need to set up IP ACLs for your backend and then restrict the traffic on your backend to the specific value of the header 'X-Azure-FDID' sent by Front Door. These steps are detailed out as below:
It requires either setting up IP ACLs for your backend or implementing middleware code to conditionally match on your specific header value for 'X-Azure-FDID'. Both may not be required, the documentation is unclear.
I think you DO need both IP ACLs and checking the 'X-Azure-FDID' header. (I wish it was not needed...). If you only use IP restriction, your back-end is still open for all Front Doors around the globe, also those of other Azure Customers. And if you use only the check on the 'X-Azure-FDID' header, you are open for attackers trying to guess the header with brute force. Only the combination of IP ACL and checking the header will protect your back-end, because then you can be sure that the 'X-Azure-FDID' header was indeed added by a real Front Door service, and not spoofed.
See also this post, where it's explained clearly.
I would have asked this in a follow-up comment to this comment but my reputation is still too low.
So here are the questions: Is it possible to change the endpoint URL of a browser or to add an endpoint URL so that my application can send its POST request not to a web service owned by the browser manufacturer but to a web service that runs inside my intranet? As my application is run in an intranet without connection to the internet a customized browser wouldn't be a perfect solution but it would be possible.
And now for the 2nd part: If it is possible - are there ready-to-use push service libraries for PHP? So far all I've found are libraries that let an application send notifications like https://github.com/web-push-libs/web-push-php.
Is it possible to change the endpoint URL of a browser
No, currently it is not possible to change the browser push service.
And in any case you would also have to run an instance of the browser push service on your own servers (e.g. https://github.com/mozilla-services/autopush).
I think in this case you can just use any transport like web sockets, for instance and a notification API to show it to the user. Not sure if persistent connections will work within service worker context, but this should not be a problem if you're still customizing a browser.
I'm looking for some suggestions on how to go about creating a user in one of my asp.net mvc websites from another one, basically integrate the two sites a bit.
Site A (ASP.NET MVC 4, VS 2012) needs to take some information from a customer upon a POST action and from within that action (server side) send a POST to Site B (MVC 5, VS 2013, ASP.NET Identity 2) to create a user in it (it doesn't have to wait for the post to complete, it can fire and forget...but open to suggestions here too). Both sites are owned and operated by myself, but exist for different purposes up until now.
I'm thinking I need to expose a controller action on Site B that will allow another Site A to POST to it the information needed to create the user.
Would it make sense to just add this as another action to my existing controller in Site B that creates user accounts, or would it make more sense to create a web api controller that handles it separately? Are there performance differences between the two controller types?
Also, how would I secure this new endpoint/action - I'm considering generating an api key of sorts (generating and storing a GUID as a private key that they submit with the request) to verify that it is in fact Site A making the request (all over https of course), and no one else. I only want to open this up to Site A to do, and this single action is likely as far as integrating these sites will ever go.
Any feedback would be very helpful. Thanks!
I currently have a web config file in a web service that is using the following code snippet so that it can access resources on Sharepoint
<identity impersonate="true" userName="[domain admin]" password="[password]"/>
Clearly this situation is not a good idea and we are currently replacing this with the correct way of doing things. However, in the mean time we are creating a new domain user that is NOT the domain admin and using that as a stop gap. The domain admin was used as people were too lazy to determine the right security levels required and a domain admin will be guaranteed access to every resource.
My question is: What is the minimum level of security that this domain user requires in order to continue accessing the Sharepoint Web Service? What sort of things should I be thinking about?
What web service are you talking about exactly? SharePoint web services are permissions aware, just like any other module, so it is different if you want to say read items or create a site. You need to know first what you are trying to accomplish and then give the user the exact permissions to do that