Sitefinity is using standard ASP.NET Membership model for working with users and providing security infrastructure. ASP.NET Membership model is provider based, which means that it does not limit its functionality to working with any specific kind for data storage (e.g. SQL Server or even database).
So, before I go into more details, Sitefinity is perfectly capable of what you are after.
While I cannot fully explain the ASP.NET Membership and provider model in this ticket, I will give you broad directions and suggestions. For specifics you can consult following articles later on:
Provider model pattern:
The general idea is following:
Let us assume that for the backend (or Sitefinity administration) you are satisfied with the built in membership (stored in SQL Server for example) and you do not wish to mix the public members with the admin staff. So, the next step for you is to define additional membership provider in the web.config file as it has been described in the KB article you have found yourself:
Now, here comes the twist. In the KB article, author is implementing a standard ASP.NET built-in provider (System.Web.Security.SqlMembershipProvider), however, you will have little use of this provider since you need to communicate with the thrid party system. In order to achieve this you will need to implement your own membership provider which will not communicate with the database, but rather this 3rd party system. Here is a link to the good article that explains this:
Also, you may try querying google for "implementing custom membership provider", which will return you some 8 million results - so you are not alone in this.
This, solves the problem of integrating Sitefinity with the third party membership system. What we are left with is implementing the business logic for the end users.
Sitefinity comes with a very simple user interface command that denies access to anonymous users, so the first task is of the trivial nature. You just deny the access.
Now, you are referring to the attributes ("A", "B", "C")... since you will be using Membership system, I suggest we move to its terminology. In ASP.NET Membership every user can belong to one or more roles. So, instead of having attributes, users will belong to roles. Allow me to digress for a moment, users can also have attributes such as height, home address, name of the dog... and so on, which are called Profile properties (there is also Profile provider), but let us go back to our initial task.
So, we have found the way to separate anonymous and logged in users. What we are left with is to apply different rules based on their roles. For rules which include single role, this is quite straightforward since you can use built in page permissions to define access rights based on the roles. Since you can set permissions only per roles, you will not be able to set certain permission only if user belongs to roles "A" AND "B". Nevertheless, there are simple workarounds for this scenario.
- First, we can create some sort of a joint role and call it "AB". In your provider you can simply implement this logic, by making sure that users that belong to roles "A" and "B" also automatically become members of role "AB". While this is probably the simplest way to handle this, it may prove hard to maintain in the future because it is to be expected that business rules will change.
- Second option would be more robust and would go somewhat in this direction. You would create a simple http handler that would intercept the request to the CMS and perform the user / role / business rules analysis. If user is not allowed to see the requested page or resource you would redirect him to some predefined page, otherwise you wouldn't do anything. Here is a KB that explains this approach:
Finally you could create a module or tool which would allow business users to define business rules on the fly. E.g. You would parallel provide the tree view with all the pages and list of roles with checkboxes. Then business user could select a given page and mark the roles required for access to that page and its children, thus effectively creating a business rule.
I am sorry for the lengthy post, but the subject is such that I could not have answered it shorter and provide all the needed information. Let us know if there is anything else we can do for you.
the Telerik team