Problem Statement:
I am developing a single sign on solution for a midsize organization (<3000 employees) so that they can use it in their future internal software systems. The internal software systems are all subdomains of the company’s domain. (e.g.: hr.company.com, pm.company.com, etc.)
The future software systems will be mostly ASP.NET Core MVC applications with a possibility of having some SPAs or Blazor applications, but they will be mainly ASP.NET MVC.
The SSO System should be able to not only provide the authentication cookie but also it must be able to provide other software systems with the roles and claims that they may require.
The system admin should be able to revoke the claims of a user for a certain software system or logout the user from all the systems. It is required that the admin must be able to control the privilege’s of users in different systems from a central place. I also want the SSO system be as decoupled from other software systems as possible, without things getting too complex.
The solution needs to be self hosted and at least now I cannot used cloud based services.
My design:
Microsoft proposes sharing authentication cookie among ASP.NET apps as a valid way to provide an SSO experience. It seemed easy enough to me so I thought let’s go with it, especially as Identity Server is no longer free and OpenIddict may be too complex for what I have in mind.
In what I have in mind we will have a SSO application (with the address sso.company.com). We will keep user accounts and their claims and their roles using a customized ASP.NET Identity database. The internal systems will subscribe to the SSO application and the SSO application notifies them about the changes in the privileges of the user. To be more precise the SSO system will provide them with the latest claims and roles that a user have, in the notification.
When the unauthenticated users visit one of the internal systems (e.g. hr.company.com) they are redirected to the SSO web application, the SSO web application validates the user’s credentials, notifies the system that is specified in the return URL about the user’s claims, then creates the authentication cookie that contains some very basic claims like the name of the user, their job title, and their security stamp, the cookie’s domain will be set to ‘.company.com’, and the user will be redirected to the original website (in this example hr.company.com).
This is the general idea of what I want to implement. I have still some questions in mind.
- How should I create the notification mechanism? Should the SSO use some web service call to notify other systems? Should I use something like RabbitMQ?
- What would happen if the notification fail to reach its destination? How can I handle the risk of a user continuing with the wrong privileges?
- How should I renew the authentication cookie especially if I use sliding expiration?
I would be thankful if you tell me if the design makes any sense, how it can be improved, and your answers to the questions I listed above.
PedroAsking is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.