|Number of votes:||3|
EPiServer CMS 5 uses the built-in Membership and Role provider feature in ASP.NET. This feature was introduced with ASP.NET 2.0 and exposes a pluggable authentication and authorization architecture. In previous versions of EPiServer this information was stored in the EPiServer database, even if you used the configurable authentication chain to allow users in other systems to log on, EPiServer would create a wrapper object for these users in order to be able to store information about the user, and to assign a unique ID used to secure resources in the system. With the use of the membership and role provider system this has changed. EPiServer is more losely coupled to the user and roles, which scales better and allows for even more customization.
When you log in to EPiServer, the username and password you provide will be sent to the membership handler in ASP.NET. It will check the configuration to see which provider should be responsible for authenticating the user. If the user can be authenticated the next step is to look up which roles this user should be a member of. The roles correspond to the groups in EPiServer. The core role API will look up the responsible role provider by looking for the default provider in web.config and ask the provider which roles the user should be a member of. You can write your own providers, intercepting this logic and both authenticate and authorize users.
The providers (both membership and role) available when installing EPiServer are:
The Windows provider allows authentication and authorization of local windows accounts and domain accounts available on the server. The role provider will give you the windows groups you're a member of.
The SQL Server provider allows you to authenticate and authorize against accounts stored in an SQL Server or SQL Server Express database. The tables needed to store this information can be added by using the %systemroot%\Microsoft.NET\Framework\vNNN\aspnet_regsql.exe application. The EPiServer CMS 5 database has already been configured with the neccessary tables. If you want to store these users somewhere else, run the application and change the provider configuration to point to another data source.
The Multiplexing provider replaces the authentication chain in EPiServer 4. The job of the Multiplexing membership and role providers are to allow more than one provider to take part in the authentication and authorization process. By default, ASP.NET only allow one provider at a time. With the Multiplexing provider you can have as many as you'd like.
The membership and role providers are specified in different configuration sections in web.config.
This example shows three membership and role providers, with the WindowsMembershipProvider and WindowsRoleProvider set as default providers. This means that the other providers will not be used for authentication or authorization
type="EPiServer.Security.WindowsRoleProvider, EPiServer" />
System.Web, Version=22.214.171.124, Culture=neutral,
Version=126.96.36.199, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
Before adding new providers you usually have to clear the provider collection from existing providers. Because ASP.NET makes applications inherit configuration settings from the levels above them in the application hierarchy you will get any providers configured in machine.config and the machine wide web.config files. You can clear the collection with the <clear /> element.
You can create users and groups from admin mode in EPiServer and any other interface that can talk to the provider base classes. However, not all providers allow this. E.g. the WindowsProvider does not allow you to create new users, but it will allow you to log on as an existing one.
The default provider, as specified in web.config, will be used when you attempt to create a new user in Admin mode. If you're using the MultiplexingProvider, its default provider will be used.
In EPiServer CMS 5 you have the possibility to create virtual roles in addition to the standard roles. A virtual role is a role who is created programmatically. This means that it is not dependant on static settings in the database and that the criterias for access rights for this role can change on the fly (in accordance to your code). You could, for example, create a role that gives certain permissions during certain hours of the day. Another possible scenario would be to give a user permissions based on the criteria that he/she is member of both role1 and role2.
The virtual roles are configured in the <virtualRoles> section of the web.config. See the following example of an "Anonymous" role:
type="EPiServer.Security.AnonymousRole, EPiServer" />
Predefined Virtual Roles in EPiServer CMS 5
EPiServer delivers four virtual roles out of the box:
Apart from the obvious roles here, Administrator and Creator could use some explanation. The reason for the virtual role Administrator is to create localized versions of the administrator account depending on language. The swedish word would, for example, be Administratör.
Creator is only used when evaluating AccessControlLists in EPiServer and it will return true if the current principal is the same as the Creator for an ACL.
See the sub topic Virtual Roles in the Membership and role Providers section of the SDK documentation.<<A name=Creating_your_own_provider>
If you wish to create your own providers we recommend you to read the article Building Custom Providers for ASP.NET 2.0 Membership on MSDN.com.