ACL Based Authorization


This feature will be a way for the users of Digital Fortress to model their application´s business resources in a way that allows them to define ACL´s (AKA Security Sets) for each node or group of nodes. This is an hierarchical system, in that child nodes inherit ACL from parent ones (unless overriden).

The ACL Based Authorization will allow for dynamic nodes as well as static ones. Let´s take an example:
  • Customers (Type=DigitalFortress.Sample.Customer)
    • Orders (Type=DigitalFortress.Sample.Order, Customer.Id = Parent.Id)
  • Account Management (Static)
  • Administration (Static)

So as you can see we plan on enabling resource-based authorization, which is far more efficient than role-based authorization. The above tree at runtime could be evaluated to:
  • Customers
    • Customer A
      • Orders
        • Order 1
        • Order 2
        • Order 3
    • Customer B
      • Orders
        • Order 4
        • Order 5
  • Account Management (Static)
  • Administration (Static)

What does this mean? It means that you get to specify default security sets for each node, if you want to. Let´s say, for instance, that I set the default behavior of Customers to be Read-only for Everyone. Then I, on a per-customer basis, set write permissions to the account manager for that customer.

Security Sets (ACL)

A Security Set describes how to assert if a given user is allowed to use a given resource. The security set can include dynamic instructions such as {{Parent.Active = true}} (RW), for an order, if I want people to be able to modify only orders from Active customers, or {{UserId = Parent.Manager.Id}}(RW), if I want to enable the manager to modify and order, and him only.
Security Sets also allow for temporal security, in a way that you can specify start and end dates for it.

ORM Integration

Digital Fortress strives to be ORM independent when it comes to integrating into your domain model. The problem here is that we must use your domain model to retrieve the information for the security sets. So we´ll be using providers to each ORM, starting with Castle´s ActiveRecord.
The provider will be responsible for all the ORM-based operations, like retrieving domain types or retrieving data from the data store.

Last edited Aug 7, 2007 at 2:14 PM by Heynemann, version 1


No comments yet.