Orchard CMS custom membership

Question

What is the preferred way of integrating a custom membership provider with Orchard?

I have seen a couple of posts around implementing a new IMembershipService and IUserService (from Orchard.Users) and then there other modules such as OpenAuthentication which seem to do a lot more than that (but still uses the UserPart??).

We already have an ASP.NET Membership provider written, can this be integrated as is?

Ecotype

Answer 1

Custom implementation of IMembershipService is a way to go if you don't want to use the default Orchard.Users module at all. Useful when you still want to do forms authentication, but just store the auth data somewhere else, not in UserPart.

If you would like to create a totally custom authentication scheme, that overrides the form-based default one (username + password), override IAuthenticationService.

So, generally speaking:

• IMembershipProvider is about authentication data management (create/retrieve users)
• IAuthenticationProvider is about performing the authentication (sign in/out/get current user etc.)

Depending on your needs you can override either one or both.

The common auth modules, like the OpenAuth one, add additional authentication options to the existing default one without actually replacing it, IIRC.

Gravedigger

If implementing IMembershipService using a separate data store, where does the ContentItem property come from on for the IUser returned? – Ecotype

Hmmm, good question actually. The IUser needs to be a content item so it complicates things a bit, but only a bit. You can create a single content item ("User" one, for example) with no parts and put that one as a value of the ContentItem property for every IUser. If attaching other parts to user is not needed in your scenario, this will work perfectly. – Gravedigger

You could also eg. put the current site content item in there, so you wouldn't need to create anything. Current site is accessible via IOrchardServices.WorkContext.CurrentSite. – Gravedigger

Actually, I was partially wrong - double checked the code and yes, you'd need to create a "User" content item for each user for Roles to work. Roles module attaches UserRolesPart to a user for authorization purposes, so user has to exist as a content item. Of course that's not the problem if you also create a custom IAuthorizationService and do not utilize the one Orchard.Roles module provides. – Gravedigger

So the best solution would be to create a module that adds a part to a user and stores some data needed to wire a given Orchard user with your external one (eg. some ID) inside. Then, in your IMembershipService you could use that ID to fill your custom IUser object with necessary data from the external data store. – Gravedigger

I wanted to replace the Orchard.Roles so re-implemented IAuthorizationService. fyi... A side effect of not storing the users as content items is that the Orchard.Security.Providers.FormsAuthenticationService will no longer work, on calling the GetAuthenticatedUser() method, it loads the user using the IContentManager rather than going to the IMembershipService. It was an easy job to implement IAuthenticationService taking the existing implementation and altering a couple of lines. Should the default implementation use IContentManager or should it be changed to use IMembershipService? – Ecotype