You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 27, 2022. It is now read-only.
With IdentityServer4 you can provide secrets and config for static identity providers(Google, Google OAuth, Hotmail, Github etc).
For a real multi-tenancy setup we'd need this to be non-static and unconditional for a single application (so no 'conditions' in the application construction, but conditions determining the set of external authentications on-the-fly).
I presume this has advantages, but also bugs/errors and more research to be done to make it suitable for Thor/RSRC/future clubs.
Advantage known so far:
With the solution (package) above we can determine external IDP's dynamically (based on database). It could be over-designing as well, which we need to prevent if this is the case.
...
Disadvantages:
Not sure how to do the client-auth mapping and whether we should do this ourselves.
...
The text was updated successfully, but these errors were encountered:
This solution seems to work. Now need to provide proper database seeding as the package does not take care of this.
Also need to build proper management API and MVC for it to configure it by admin roles.
When a new tenant is made the option for configuring a ID4 domain should be possible.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Thinking about dynamic (persistence based) configuration of external configuration providers (per client even?).
https://github.com/Aguafrommars/DymamicAuthProviders
With IdentityServer4 you can provide secrets and config for static identity providers(Google, Google OAuth, Hotmail, Github etc).
For a real multi-tenancy setup we'd need this to be non-static and unconditional for a single application (so no 'conditions' in the application construction, but conditions determining the set of external authentications on-the-fly).
I presume this has advantages, but also bugs/errors and more research to be done to make it suitable for Thor/RSRC/future clubs.
Advantage known so far:
Disadvantages:
The text was updated successfully, but these errors were encountered: