Difference between site user and membership

[aruss]

Membership type looks redundant to me if you just authenticate current identity and create site user every time a subject (human) uses the identity provider (facebook, google). Why not just add a list of identity providers subject uses to sign in to the site user and restrict access by roles?

In my case, I use an STS to provide webSSO and central point of user management for all applications. The whole identity provider management is done outside the CMS scope, and the CMS gets only authenticated. I solved it by mapping the roles defined in central user store to Kooboo site user roles and restricted the page access (if needed) by roles. It works great. For this I just needed to change site user creation logic, that it.

So I trying to understand should I remove the whole membership logic and stick with site user with roles, because like I said the memberships looks redundant to me in my case.

Cheers aruss

[kooboo-jifeng]

Hi @aruss

In general sites, there will have two types users are "Manager" and "Member".

Manager charge of the site management such like manage the contents, site settings etc. They usually consider as back-end users and will have some high permissions can change anything on the site.

Member is the consumer of the site front-end, they are different with the manager. They can only granted to visit the front-end pages. The manager can decide which pages are restricted to the members.

The membership is a member center for manage the member list. The member register from open identity provider are become more and more popular, so we need to support it in the membership.

In the other side, the manager is considered as internal user role, for the security reason, it usually not need to connect with the open identity provider.

The membership is a optional option for the site, you can decide if you want to enable the membership feature. Just go to set the "Membership" property as null on the site setting page.

[aruss]

Hi @kooboo-jifeng

Sounds quite odd to me because the HttpContext.Current.User.Identity is not authenticated while HttpContext.Member().GetMember().Identity is.

So in case you have codebase that uses standard .net identity it would not work.

Actually I would expect that if the subject authenticates with one of identity providers he creates a standard site user and add a membership to it, so if he is authenticated he can add additional memberships to same user. This user will have multiple roles and pages a restricted by roles. So in this case you always has a current identity authenticated and can access all the memberships and profile and if the user gets an editor role he is eminently able to edit content without creating a separate account.

In a case you use STS the Identity Model provides a authenticated principal with list of claims (including roles) at this point all the third party identity provider authentication is already happened. In this case there is still no possibility to restrict front end pages, because current version relies on membership.

I think simple checkbox for “require authentication” and a list of roles will do the same job. But I have a question, what was a major cause for the decision for splitting backend and frontend users and not just separate it by roles or groups or even better claims?

Cheers aruss

[kooboo-jifeng]

It is because the Kooboo CMS is a multip-sites platform, we need to allow the sites have different user with same user id. The membersip have smiliar design with site and contents. It is easy to export/import, share the membership in different sites.

[aruss]

Ok, but normally it’s a common practice to use one user account across all the sites and store site specific data, like profiles, on each site. The way like MS or Google do it, they have multiple sites but only one user account. Interesting thing is, if you have multiple sites with multiple memberships and one user that uses Facebook is authenticated on all this sites and have multiple memberships so at the end you have one Facebook account that is centralized spitted to multiple memberships so it reverting the pattern of centralized user account (whatever it might be called)

Another problem is (maybe I didn’t got it) if I want create TextContent and assign it to the creation user, like user creates a thing and then list all users things in user profile page. Normally I would do it as follows

ServiceFactory.TextContentManager.Add(repository, folder, null, null,
        formValues, HttpContext.Current.Request.Files, null, HttpContext.Current.User.Identity.Name);

So can I just add a membership identity name as UserId to the TextContent? Or would I need to add a custom filed to my TextContent?

Cheers aruss

[kooboo-jifeng]

1. I hope will more clear when you see the following image :)

1. When you do not use the workflow feature, you can do it like that. Because the UserId field is only used in workflow. Otherwise you have to create your owner field to store the membership id.

[aruss]

I got the idea behind it. And I like the cool UI :)

But I don't much like this approach because I don’t want to maintain multiple users for the same subjects. The exact opposite is required so one subject can use multiple providers to be able to sign in with the same user.

The same style like https://account.live.com is used to login to multiple sites, each site maintains own user profile, that it.

I changed Kooboo in my fork to be able to do this. Each time subject authenticates with STS Kooboo synchronizes the local Kooboo user and related site users profile with Identity that come from STS. roles, name, email and so on.

So I removed all the membership releated code and replaced it with default Identity (HttpContext.Current.User)

The page permission settings as well

This way there is no difference between backend user and front end user, you can promote every frontend user to developer or whatever, or just ban him by setting the user to inactive so he can’t sign in anymore in all sites, or just for particular site (this can be done by setting a custom property in users profile or extending site user)

Cheers aruss

[kooboo-jifeng]

Great, :+1:

Kooboo CMS allow the people extend the membership OR replace it fully to achieve they goals, but for the common edition of Kooboo CMS, we expected to provide a simple, easily feature for general sites.

We want to make Kooboo CMS as more and more extendable, replaceable and flexible. :)

[aruss]

Hi @kooboo-jifeng

In my fork https://github.com/aruss/Kooboo.CMS/tree/customized I fully cut out the membership and I had to remove it from everywhere across the code. And it works well sofar.

But the problem is we have sites that uses the original Kooboo membership and the customized one, but both uses common modifications.

It would be nice if the membership logic would be exposed via couple interfaces and the management UI would be completely replaceable.

Stuff like:

• checking if user is authenticated
• login
• logout
• assign users to sites
• reset password
• manage users
• manage roles

So people can replace the login logic via custom ones, like in my case with Federated Identity or maybe with https://github.com/brockallen/BrockAllen.MembershipReboot or whatever they come up with.

Cheers aruss

[talves]

I agree with @aruss on this item. I have also been looking into using MembershipReboot with Kooboo. I have just been stuck on other projects or would be able to make a better contribution at this time.

[kooboo-jifeng]

Hi @aruss

I totally agree you too, I think it is better. It is in the plan, thank you very much.

[aruss]

If you need any help implementing it I would love to help. Because I want a solution with which you also agree, so it stays generic.

[kooboo-jifeng]

@aruss

I reviewed the code of Kooboo CMS membership again. I think the class which in the Kooboo.CMS.Membership.Services is possible to replace already. Is it enough for you to replace the default implementation?