Integrated Scenarios in Shared Membership

In previous versions of Community Server, it was impossible to support shared membership with other Community Server sites or existing ASP.NET applications unless they were installed into a single database.

With Shared Membership, new integration scenarios are now available due to the clean separation of content and membership data, as depicted below.

Shared Membership brought about the separation of content and membership.

Integration Scenarios

One of the two primary integration scenarios is shared membership for multiple Community Server sites. In this scenario, membership is centralized while each site is responsible for its own content (see image below). Since all sites are running Community Server 2007, no custom code is needed and configuration is relatively painless. This scenario is currently being used by Microsoft with their http://www.asp.net/, http://www.iis.net/, http://www.silverlight.net/, and http://www.windowsclient.net/ sites. Once a user has registered for one of these sites, they can successfully login to any of the others without the need for further registration. In addition, password and profile information is also maintained across all sites with no code customizations.

Scenario 1: Shared membership for multiple Community Server sites

The other integration scenario supported by Shared Membership is leveraging the membership store of an existing ASP.NET application for a Community Server site. In this scenario, membership and application data already exist and Community Server 2007 is being added to the mix. Depending on the specifics, it may be necessary to write some code, but there are situations where a little configuration and running a simple database script will be all that’s necessary.

Scenario 2: Leveraging an existing application’s membership store

Where will Membership data reside?

Regardless of which of the previous two scenarios is most likely to meet your needs, you still must decide the location for the membership data. Up to this point, we have talked about membership as a single unit. In reality it is composed of three distinct components: Membership, Profile, and Roles. Since the purpose of this kind of integration is shared membership, we can safely assume that membership data will be centrally located. Furthermore, since profile data tends to be tied to a specific user, rather than his/her interaction with a site, it is customary for this data to live alongside the membership data; hence also centrally located. As a result, of the three components, the only decision is where to store roles information. The choice is really based on the particular needs of the sites.

By selecting the first option, storing roles centrally, a user will have the same permissions regardless of which site s/he accesses. In this case, a system administrator in one site will be able to administer all sites, by default. Similarly, a moderator in one site will be a moderator in all sites.

Option 1: Roles, Profile, and Membership are all centralized. Permissions are identical across all sites.

On the other hand, if roles are not stored centrally, but locally (with regards to the site), then each site will be able to dictate a different set of permissions per user. So, for example, if you want a user to have administrative capabilities in one site but not necessarily in another, then you should keep roles local.

Option 2: Profile and Membership are centralized. Roles are “local”. Permissions can vary per site.

It’s important to note that there is not always a primary site. If you do have a main Community Server site, then that site’s database would be the location for all centralized data, as pictured in the two options above. If each site in the group is equally important, then it’s possible to just have a centralized database (no site) that each of the satellite sites communicate with for Membership, Profile, and/or Roles information. If that is indeed the case, then we have two final options, based on the above options.

Option 3: Roles, Profile, and Membership are all centralized (database only). Permissions are identical across all sites.

Notice that in the case of no primary site and local roles, there is no centralized role information since it would need to be associated with a particular site.

Option 4: Profile and Membership are centralized (database only). Roles are “local”. Permissions can vary per site.

Summary

Shared Membership introduces new ways of integrating multiple Community Server sites and your existing ASP.NET membership-based applications. Not only can you decide to host your membership data outside of Community Server 2007, but you can also choose which portions of Membership (Users, Profile, Roles) should be local to your instance of Community Server.