Serviced membership? Steps to take?

Jun 24, 2014 at 10:00 AM
I'm in the process of building a membership service based on ASP Identity. Your SimpleSecurity-project has helped me to encapsulate membership management and decouple it from the application domain. My next step is to decide where to put the "service boundary". Some of my demands:
1) The membership-service will be consumed by several applications and built as a WCF-service hosted on IIS. The two main reasons for setting up a common service is a) all applications should use the same set of users and b) the involved applications should support single-sign-on.

2) All applications have their own login page, but after beeing authenticated in one application it should be possible to jump to another without a new login. (Single-Sign-On). All applications are on the same main-domain and by using the same machinekey on all involved servers we think this can support SSO easily. The authentication ticket will be valid on all servers.

3) The applications which will consume the membership service use three-tier architecture and have a frontend (ASP.NET Webform/MVC) and a backend (IIS-hosted WCF-services). Both frontend and backend needs to authenticate the user. User credentials are passed in WCF-calls. The business logic in the backend not only needs to authenticate the user, it also needs authorization and access to custom user properties.

Actually we already have a Membership as a service today, but it is built on Membership- and Roleprovider and not ASP Identity. By switching to ASP Identity I hope we can get a better flexibiliy. We need to customize user properties and we need to enforce twofactor-authentication a.s.o.

But now I feel very unsure where to put the "service boundary". My plan is to divide our "common membership package" into two parts; one service instance hosted on a application server and a helper-assembly which the applications can include in their solutions. This helper-assembly will hide as much complexity as possible. For instance all the calls to the membership service. The question is what "level" in your SimpleSecurity is suitable for a) put in the common membership service and b) put in the helper-assembly.

To make it even more complex; The common membership service should only handle SOME of the general user properties and none of the user roles. The user roles and more system specific user properties should be handled by each application locally (preferable using ASP Identity, but not necessarily). If possible, I would like a solution where an ApplicationUser-object in a given application is a actually a "merge" of 1) a public user entity stored in a central repository shared among all applications and 2) a set of systemspecific user properties and roles stored in the local application. And I have no idea how to accomplish this... Is a custom UserStore (IUserStore) the way to go? But isn't that for persistance only? I would like to have logic like password hashing, e-mail confirmation, twofactor authentication a.s.o. put in the common service...

This was not really a question, but I would be very thankful for any thoughts and ideas... :-)