Newbie question on URLs for multitenant applications
-
We're in the evaluation stage of outsourcing our AuthN needs, and I'm looking for advice on a couple of things that weren't entirely clear from the online FusionAuth documentation.
Our SaaS application is multitenant, where many corporate clients are given custom domains client-name.ourapp.co. Internally we use a templating scheme so that we can substitute the client-specific URLs in emails and notifications. Although there is also a general URL that will work for any client, that is not seen by clients with the custom ones.
As I understand FusionAuth, we would expect to use the Tenant concept to model our production, dev, staging, and QA environments, and the Application concept to model our (one) app. I want to minimize the amount of per-client management that has to happen through the FusionAuth UI - zero would be best unless the client has their own IdP so that we need to configure a Connector. My thought was to leave direct knowledge of our clients entirely out of FusionAuth, keep shell objects for the users in our existing database, and use the API through the Java client to synchronize user state and trigger actions.
Does that sound like a reasonable approach overall?
One roadblock I'm seeing, at least based on an impression from the documentation, is that the emails from FusionAuth for a given application are expected to reference fixed URLs. Using the approach of synchronization through the API, is there enough flexibility in what data we store in the FusionAuth User record so that we can parameterize the templates with the client-specific URLs?
Thanks for any input!
-
Welcome to the FusionAuth Community!
I want to avoid giving too specific advice on architecture in our community forums, but what you have outlined here certainly seems plausible, at least at first pass. Could you elaborate a bit on what you mean regarding 'shell objects for the users'? I will also see if my colleagues have any other feedback for you. If they do, I will be sure to pass it along here.
Regarding the user object, you have the ability to set up a lambda function to add custom functionality.
One can make any number of custom claims on the user object to help you facilitate what you are trying to create (re: 'parameterize the templates'). A good example of this can be found here.In addition to lambdas, FusionAuth also has significant extensibility through its external identity providers, connectors, and API's which you can mold to your use case. As an aside, if it is possible to do in FusionAuth, it will most certainly be doable through our APIs (some of our customers don't even really use the UI).
I hope this helps!
Thanks,
Josh
