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.

DataObjects.Net Contribution Program

Hello All,

Starting from the version 4.4 we are happy to officially announce the DataObjects.Net Contribution Program. The main goal of the program is to speed up the development process of the ORM by getting involved contributors from outside Xtensive LLC company and award them the eternal glory and of course, licenses.

Frankly speaking, we'd tried such an approach experimentally earlier. As a result, the PostgreSQL data provider was build by Ottó Havasvölgyi, and he gained the Ultimate license for that excellent work.
This winter another talented person, Csaba Beer, is participating in Firebird data provider development. And again, the Ultimate license is what he will definitely get in return.

As for now the scheme works well, we've decided to officially approve the approach and right now we are searching for volunteers to help implementing the following data providers:

• MySQL data provider
  
• SQLite data provider
  
• EffiProz-DB data provider
  

As you might noticed, there were several requests concerning MySQL & EffiProz-DB support. As for the least one, even developers from EffiProz Limited are ready to help with implementation and testing. The Contribution Program is not limited to data providers only, you might be get more interested in any other feature request, that are listed here.

To participate in the Contribution Program, please write to info@dataobjects.net.
Thanks.

DataObjects.Net 4.4 goes final

We are very excited to present the final version of DataObjects.Net 4.4. It took almost 5 months of intensive work for our small but brave team to accomplish this task. We tried to include the most awaited features, simplify the overall API and make DataObjects.Net more friendly for desktop application development.

Contents:
1. Changes comparing with DataObjects.Net 4.4 Beta 2
2. Changes comparing with DataObjects.Net 4.3
3. Download DataObjects.Net 4.4
4. What about the future versions?

Changes comparing with DataObjects.Net 4.4 Beta 2

There are 2 minor changes comparing with Beta 2 version.

Usability of GetProperty/SetProperty
Firstly, the usability of Persistent.GetProperty/SetProperty methods is extended. Both methods now support dot-like notation, for example:

string customerName = orderItem.GetProperty("Order.Customer.Name");

Moreover, both methods support not only publicly visible persistent properties, as it was in earlier versions of DataObjects.Net but all range of them: public, protected, internal and private.

Localization
Secondly, we've reworked the localization sample, updated and extracted common interfaces and types into separate assembly 'Xtensive.Practices.Localization'. This feature provides the ability to define localizable entities, localizable fields, describe backing fields for them and execute LINQ queries absolutely transparently.

Here is the example of localizable entity:

[HierarchyRoot]
public class Page : Entity, ILocalizable<PageLocalization>
{
 [Field, Key]
 public int Id { get; private set; }

 // Localizable field
 public string Title
 {
  get { return Localizations.Current.Title; }
  set { Localizations.Current.Title = value; }
 }

 // Here localizations are stored
 [Field]
 public LocalizationSet<PageLocalization> Localizations { get; private set; }
}

Current localization setting is managed via LocalizationScope or Thread.CurrentThread.CurrentCulture property.

// Editing localizable properties through localization scope
using (new LocalizationScope(new CultureInfo("en-US"))) {
        welcomePage.Title = "Welcome!";
}               

// The same action but through Thread.CurrentThread.CurrentCulture
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
welcomePage.Title = "Welcome!";

The most valuable part is the transparency of LINQ queries, you don't have to add or change anything. Special query preprocessor, located in 'Xtensive.Practices.Localization', is automatically attached to query processing pipeline and does all the work for you.

Thread.CurrentThread.CurrentCulture = new CultureInfo("es-ES");
using (var session = domain.OpenSession()) {
        using (var ts = session.OpenTransaction()) {

                var query = from p in session.Query.All()
                where p.Title=="Bienvenido!"
                select p;
                Assert.AreEqual(1, query.Count());

                ts.Complete();
        }
}

In order to add localization support to DataObjects.Net-based projects, follow the instructions in the corresponding chapter in DataObjects.Net 4.4 Release Notes.

Changes comparing with DataObjects.Net 4.3

Better WPF support
DataObjects.Net 4.4 development branch embodies an idea of ORM platform unification for usage in both server-side and client-side applications. Previous version of DataObjects.Net with thread-bound and automatically activated Sessions as well as transactional properties, methods, etc. fits well in server scenarios, but client application development, such as WPF-based ones, might cause difficulties, especially in multi-threaded environment model and delayed binding of windows controls to Entities.

Keeping this in mind, we decided to alter and extend Session behavior. First of all, we made 'Automatic Session activation' and 'Automatic Transaction opening' modes optional, moreover, they are switched off by default. Secondly, in this version we are introducing Session profile notion which represents a combination of predefined Session options for a particular scenario, for instance, WPF application or ASP.NET website.

For now there are three main profiles: Server profile, Client profile & Legacy profile.

1. Server profile is intended to be used in server scenarios, such as ASP.NET, ASP.NET MVC, WCF Data Services, etc. It doesn't include 'Automatic Session activation' and 'Automatic Transaction opening' modes, so several Session instances could be used within a thread and all actions with Entities, Structures & EntitySets require the presence of opened Transaction. This profile is the default one for DataObjects.Net 4.4.

2. Client profile is designed for WPF, Windows Forms, Console applications, whatever. It uses the new 'Disconnected' Session mode which means that Session encapsulates an instance of DisconnectedState and runs in occasionally connected conditions, logs modifications of Entities and applies them to a database on request. It doesn't include 'Automatic Session activation' either but has 'Automatic Transaction opening' option switched on (in this mode it uses local in-memory transactions, not database ones, in order to log Entity modifications).

3. To preserve compatibility with Session & Transaction behavior from previous version of DataObjects.Net we added special profile named Legacy, which has both 'Automatic Session activation' and 'Automatic Transaction opening' modes switched on.

PostgreSQL 9.0 support
Starting from version 4.4 Beta 2, DataObjects.Net provides support for recently released PostgreSQL 9.0. Note, that the 2.0.11 or higher version of Npgsqlprovider assembly is recommended for usage with this version of PostgreSQL.

Visual Basic support
Visual Basic is fully supported starting from DataObjects.Net 4.4. LINQ translator understand and translate properly the following Visual Basic's specific methods for String type: LTrim, RTrim, Len, Left, Right, Mid, UCase, LCase. Auto properties are supported as well. Here is an example model:

Imports Xtensive.Orm

Namespace Model
  Public Class NonPersistent
    Public Property Id As Integer
  End Class

  
  Public Class Author
    Inherits Entity
  
    Sub New()
      MyBase.New()
    End Sub


    
    Public Property Id As Integer

    
    Public Property Name As String

    
    Public Property Books As EntitySet(Of Book)

  End Class

F Sharp support
DataObjects.Net 4.4 declares FSharp support. Here is a simple model, written in FSharp. Unfortunately, FSharp doesn't support auto properties as C# & VisualBasic do, so you have to write the appropriate code to emulate them.

module Model
open Xtensive.Orm

[]
  type Person() =
  inherit Entity()

  []
  member this.Id
  with get() = this.GetFieldValue "Id"
  and private set(v: int) = this.SetFieldValue ("Id", v)

  []
  member this.Name
  with get() = this.GetFieldValue "Name"
  and set(v: string) = this.SetFieldValue ("Name", v)

Download DataObjects.Net 4.4

The final version is available for download on the official website.

What about the future versions of DataObjects.Net?

Starting from version 4.5 we decided to review our feature planning policy. Not developers or big bosses will decide what to implement first, but you, our dear customers. Especially for this initiative we've opened a forum on excellent UserVoice service to make the voting and suggestion process natural and agile. The forum already contains all suggestions made on support forum or former issue tracker, but you may add your own ideas as well.

For now, there are 2 features in DataObjects.Net 4.5 branch that were planned earlier:
1. Security System, which was requested by many of you.
2. Firebird data provider, which is almost implemented, owing to the considerable contribution of Csaba Beer.

In addition, we will try switching to the recently published PostSharp 2.1 CTP soon in order to check its declared performance boost and overall stability.

We would like to know your opinion on which features we should include into 4.5 branch. There is a possibility to additionally implement one or two big features (depending on their complexity), so make your choice.