Background:
We use a single-tenant-per-application model
All tenants run the same frontend and backend code that is deployed and hosted separately under different subdomains for each tenant
We provision separate AzureAD applications for each tenant, resulting in in a different ClientIDs for each
Problem:
As per the ADAL js wiki found here: https://github.com/AzureAD/azure-activedirectory-library-for-js/wiki/Config-authentication-context, our frontend application must specify the ClientID and backend API Endpoints when initializing ADAL.
Since each of our tenants has their own ClientID, we ended up adding all the possible ClientIDs and Endpoints into our code, and figuring out the values at runtime based on the current URL. This obviously doesn't scale very well as it requires a code change for each new tenant. We are thinking moving this work to the the CI/CD process, but are trying to understand if there is a better solution.
Is there a better way to manage multiple, single-tenant apps with ADAL js?
Since each instance of your application is registered separately (thus has its own ClientId), ADAL.js doesn't provide you a better solution.
You can either work with Angular Environments e. g.
environment.tenant1.ts
enviornment.tenant2.ts
And create a build artifact for each tenant using ng build --prod ---configuration=tenant1. I don't like this solution since you have multiple build artifacts.
Or you expose a middleware / REST API that returns the configuration for a specific client by its URL. This will be the only endpoint your client needs to know. However, you have to ensure the middleware is always up (single point of failure).
Related
I'm trying to create a multi-tenanted blazor application using ABP Framework and i'm struggling to figure out how to implement as the documentation is very limited.
My application needs to resolve the tenant based on the url. A tenant can have multiple urls, so therefore need to create a custom tenant resolver which looks up a url table for the tenant and returns the correct id. I have tried this in the HttpApi.Host project and its working fine but the issue is that it doesnt know anything about the URL that the blazor application was loaded on.
I'm now thinking about adding an http header to the api requests with the url, so that the tenant resolver can pull it. Before i head down this path, i'm concerned there is much easier and better way to accomplish this problem i'm tackling?
the documentation is very limited.
The documentation is rich, and the code is open source.
https://docs.abp.io/en/abp/latest/Multi-Tenancy#tenant-resolvers
https://github.com/abpframework/abp/tree/dev/framework/src/Volo.Abp.AspNetCore.MultiTenancy/Volo/Abp/AspNetCore/MultiTenancy
I just started using nx.dev to migrate from a single app repo to a monorepo as I have added a very basic static documentation app to the mix which is deployed to a subdomain docs.company.com.
My main application is currently deployed to main route company.com. However, one could think of it as different apps as well where there is app1, app2 and admin for example. I do like the idea of having everything as a single application as it can be easily deployed with nx and Vercels monorepo support.
I am just not sure what the go to approach is here. Of course, I could split up the main app into multiple apps and deploy them independently to subdomains such as:
admin.company.com
app1.company.com
app2.company.com
If understood correctly, I could also use multi zones support if I do not like subdomains and use one domain instead.
This main app, that could logically be split up in multiple apps is non public and authentication is required. It is completely client side rendered while apollo client is used to interatct with the GraphQL API. This API server also sets an http-only JWT cookie for authentication. I am quite sure I could mitigate the issue with subdomains in this regard by setting the domain cookie setting, such that the cookie is also valid for subdomains.
However, as the cookie is http-only I cannot access it from the client and need to keep track of the logged in status in my global state mangement (which is overmind.js). Splitting up the app would add some extra complexity to persist global state between subdomain apps.
I am not sure whether this is worth it or if it is better sticking to the one app approach. I would love to hear your opinion and maybe I have forgotten some major issues. Some questions that come to my mind:
What are the advantages and disadvantages of using subdomains?
Is it more preferable to use multi zones and only one app?
How could the auth/global state issues be solved if switching to multiple apps?
What are your thoughts?
I have two frontend apps. First one uses Static Generation (for SEO purposes), and the Second one uses Client Side Rendering (for all stuff behind auth flow).
I want to have both of them under the same purchased domain, with the base endpoints to be something like:
mydomain.com\public\* : for all my public facing statically generated content using the first App.
mydomain.com\auth\*: for all the stuff that lies behind the auth flow.. made using the second app.
So the question is:
How to map these two separate apps to two base endpoints under the same domain? I was reading this post Share an API Endpoint Between Services, but it seemed to be for the backend.
In case anyone is interested to know why two separate apps:
It's because the Static generation is done using Next.js, while the Client side stuff is done using simple create-react-app. This post explains why this combination needs to be separately deployed.
Refer to this
Create two separate s3 buckets for your NextJs and React app. Attach them to a CloudFront distribution. Attach a lambda function to your CloudFront distribution and route requests to different origin based on whether the request.uri.startsWith('/public') or not.
I've picked up Angular and am now developing two separate applications, the frontend, Angular app, and the backend, the Laravel app.
As of now my backend app is just an API endpoint that handles requests, database interaction, logic, validation, etc.
However, what stops someone from requesting /api/users/1 and getting that data?
Right now there is nothing in place that prevents this from occurring.
What's the best way to prevent this from occurring and verify the request is sent through the application and not through something like http://hurl.it from some random user?
You should first evaluate what routes need to be protected, and who should have access. Sometimes it might be fine to leave them open to the public.
Once you've figured that out you have a few options. I personally lean towards the oAuth 2.0 protocol. Some people find it to be over kill. Then there is also WSSE, I personally feel like today there is far better resources explaining the use of oAuth and would probably be easier to follow.
You can google around for oAuth server libraries for laravel. One such is: https://github.com/lucadegasperi/oauth2-server-laravel
You will also probably want to enable CORS if your angular app is on a different domain from your api. IE: api.example.com (holds api). And example.com is where your app lives.
For CORS laravel also has some packages, one such being: https://github.com/barryvdh/laravel-cors
I'm about to build a community platform from scratch. We are going to create the WebServices first and the community might have some third party components, so having solid WebServices is a good idea anyway.
Since the service is stateless we need authentication for every single call. Is it a good idea to implement the OAuth protocol for our service provider to perform this task although we are the only consumer right now?
By the way: We will deliver a mobile application before a website is launched.
The whole point of OAuth is to allow other websites (consumers) to get access to your data (you are the provider). Since you are the only consumer of your data, there is no need to implement OAuth at this stage of development.
Be lean, build something fast and put it in front of users/testers. Only at this point you will discover real bugs and get a feedback on the service so that you can improve it and steer the development in the right direction.
Note: OAuth as provided by App Engine (second paragraph) only supports users with Google Accounts (even if OpenID is used).
From my experience I created the REST WS in a authentication agnostic way: jersey methods accept everything, then there are several filters in order to validate the requests.
I used OpenId authentication for the web part, OAuth and BASIC AUTHENTICATION (with SSL) for API.
Probably it is not needed to create everything from the beginning, but remember to de-couple as much as possible your REST endpoint from the authentication: you will have a great benefit when you want to release APIs.
Last "philosophical" thing: OAuth is not totally stateless, in fact you have a temporary token that authenticates a user and it is similar to a session in the browser!