Closed tidyui closed 6 years ago
Going along with this, I presume this includes plugging into the Identity OAuth pipeline to support OWIN logins?
Yes that would be awesome. The only thing I've been thinking about is how user/group management should be handled. The entire framework is storage agnostic, EF is just a repository implementation, but data could just as well be stored in JSON or Azure Table Storage (for example).
Should the Identity module be implemented in the same way or should it just go for a single data implementation (for example EF)?
My first inclination would be to build off of EFCore, since, from my understanding, it is designed to support a variety of data sources which then standardizes the actions needed to get that data. However, I've only dealt with EF in the context of SQL as opposed to other storages like Mongo and JSON.
I apologize for asking this, but is the current identity module completely separate from AspNetIdentity?
The idea of providing the ISecurity
interface was to completely separate the authentication from Piranha.Core. In many cases people use Piranha to plug CMS functionality into an existing application and single sign-on for the manager has been a popular request.
And I don't see any problem in implementing AspNet Identity using EF, but maybe we should name the module something like Piranha.Identity.EF
so it's clear that it uses EF as data provider just like the project Piranha.EF
contains the repository implementations for EF.
I think I have a "simpler" solution to the whole user/group/security design. First of we could add a core objects for users & groups and repositories for it in the same manner as the rest of the data management. This would be the basic implementation of the user management and could be implemented with AspNet Identity in Piranha.EF
.
The Identity implementation of ISecurity
could then use the repositories from the core implementation.
If a custom single sign-on is needed for a project a custom implementation of ISecurity
can be implemented which will handle login & permission checks. The default admin-views for users can be removed from the admin as there will most likely be a user admin interface somewhere else.
Does this make sense?
I would say Piranha.Identity.EF
is a solid choice of name for the module, since it follows Microsoft.AspnNetCore
conventions.
So my understanding of the security implementation would be using ISecurity
as the interface that Piranha would actually use for managing the authentication, and the system would inject Piranha.Identity.EF.Security
for example as the default provider, correct? And if someone wants to plug in something else entirely for their provider (say they create their own SecurityImpl
class which uses Windows Auth), they can replace the default Piranha.Identity.EF.Security
injection, right? If that's the case, I think that makes plenty of sense!
Exactly!
This has been implemented by @gyretech, see the repositories:
Create
ISecurity
implementation for AspNet Identity.