-
Notifications
You must be signed in to change notification settings - Fork 627
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
5.1.1.3.3 Introduce Identity Server 4 for identity management #34
Comments
Initial discussion in the room here at NDC with @RichardCampbell and the team is to bring this forward now. At a high level we are proposing implementing Identity Server 4 as our HTbox auth solution which can support single sign-on across HTbox products. This would become the central auth solution. This will likely spin out into sub issues but bumping this to kick start the discussion. cc/ @tonysurma |
I'm going to advocate for IdentityServer (http://identityserver.io/) for a few reasons:
|
I think the comment you made @RichardCampbell is also worth highlighting, whatever the solution agree on we don't want to introduce a barrier (or at least a significant one) for a new developer to get started with the solution. If they have to provision some azure services before they can start contributing then that will be a a hurdle that is probably not desirable. |
Initial work started to implement an identity server for Htbox. Once ready we will use this issue to track work to move the auth over to calls via the new identity server. |
Are you also considering to include multi-tenant support and cross domain SSO? |
@Sarvesh-Gupta It's been discussed and nothing is ruled out. The exact deployment cases for allReady I'm sure will evolve with need. The main site currently can be used by multiple orgs in a shared approach. So multiple orgs can exist on the same instance and from the public facing side, campaigns for all orgs are shown. @RichardCampbell did discuss the possibility of Htbox hosting "instances" of allReady for individual charities in cases where those may want to be dedicated and possibly even branded separately. In that use case we could be looking at either a true multi-tenant approach, single hosted app, serving under different domains or it might be a case of a deployed instance per org. In a multi-tenant approach it would be a discussion around whether that includes a shared DB or db per org. With identity server there is the possibility of having SSO across future Htbox apps in a hosted scenario. But also the possibility of individual orgs being configured to pass through to their own corporate identity services such as Azure AD. I don't think anything is set in stone at this stage. This initial identity server story is around standing up a htbox hosted and branded server. We would then move the authentication out of allReady. That gives us scope to configure the application in various scenarios as the needs arise. |
No description provided.
The text was updated successfully, but these errors were encountered: