On security system, part 1

This is an introductory post to the security system design and implementation in DataObjects.Net. Here we'd wanted to define common terms, considerations and requirements to the upcoming security system.

Bits of theory

Almost any access control model can be stated formally using the notions of users (subjects), objects, operations, and permissions, and the relationships between these entities.

• The term user refers to people who interface with the computer system directly or not and on behalf of whom some actions are being taken by a computer program or a process.
  
• An object in terms of classic OR/M can be any entity or a group of entities accessible within the mapped database(s).
  
• An operation is a standalone action invoked by the user on the objects.
  
• Permissions (or privileges) are authorizations to perform some action on
  the objects. The term permission refers to some combination of object and operation.
  

The role-based access control model (RBAC) adds one more fundamental term to the list — a role. A role is essentially a collection of permissions. Within an organization, roles are relatively stable, while users and permissions are both numerous and may change rapidly. Controlling all access through roles simplifies the management and review of access controls, therefore we'd prefer to follow role-based security model where users receive permissions only through the roles to which they are assigned.

Another advantage of the role-based access control model is the fact that roles are initially hierarchical — roles can inherit permissions from other roles. As a result, appropriate role hierarchies can be flexibly defined for any business process workflow, for example:

As a conclusion: although any access control system has its own advantages and limitations, we've chosen the RBAC one as a base for access control model in DataObjects.Net because of its flexibility and efficiency in the most usage scenarios.

Requirements and other considerations

First of all, we don't want to reinvent the wheel (again). If any core part of the standard .NET security system can be consumed, then it should be consumed. Mainly, I imply core interfaces such as IPrincipal, IIdentity, etc. This might help to use Thread.CurrentThread.Principal property in the same way as we use Thread.CurrentThread.CurrentCulture in localization extension, as well as more tightly integrate with system authentication services.

Other considerations:

• Security-related data mustn't be stored in serialized way in blob fields or something. It must be accessible via plain SQL.
  
• If this is possible, security system should be implemented as as extension (separate assembly) to the core framework.
  
• Security policy shouldn't be automatically applied to all persistent types. Only selectively chosen and configured persistent types should be subject for security system. This could be done with the help of special interface marker, attribute usage or similar.
  
• Authentication part should be extensible with custom types of authentication services (LDAP, WebServices, etc.).
  
• LINQ queries should be transparently re-written by security system to apply effective permissions.
  
• ASP.NET membership provider should be implemented as well.
  

This list doesn't pretend to be complete. Something might got out from our sight. If so, please don't hesitate to post a comment.

In the next posts of the series I'll try describing several aspects of the system in more detailed manner.