IT:AD:Design:Investigations:Security:Authorisation:PBAC:Design

(UP)

Summary

Implementing a performant custom DACL is not trivial.

But, most importantly, it's probably not required. For enterprise solutions, consider using NETSqlAzman for an Operations based solution.

Unfortunately, for a general solution, you might have to implement it yourself though.

And as for Distributed systems…you still don't need it if Permission tokens are being issued with the data. Think of the client data as being on-loan data with rights already ascertained by the server. There is no need for the client to redo the work…

Security Descriptor:
ACL:
ACE:
- An entry in an ACL
*
Every File/Object has a Security Descriptor
Every Security Descriptor contains an ACL
Every ACL contains one or more ACE assigned to one or more User's or Groups.
- An ACE is a 32 bit mask of rights assigned to a User or Group

Group → User
Role → Tasks
Target
- Can define Type of Entity being secured (eg: 'Contact') [ID, PID, TargetType]
- When checking for a Target entry:
  - If non found, fallback to searching by Type.

Discretionary Action Control List: DACL

If [Target] has no ACL, access is allowed.
If ACL has no ACE, there are no permissions to access.

It is only in a FileSystem that there is inheritence: Db Records do not.
- In NTFS, Rights are granted to hierachical file objects.
- In SqlServer ACL's are attached to entities (GRANT READ on View|Table).
- Therefore recursion of Targets is not required in most cases.
  - It would only need to be implemented if one would implement a Db based File System.
    * Hierarchy of users/groups is always required.
Recursion in Databases is expensive.
- SqlServer 2008 has some tricks to help (better than 2005, and certainly better than 2000 where there were none).
  - Potentially less of an issue with object databases on mobile clients.
- Therefore, a threadsafe in-mem cache service is required.
  - Cleaning can be handled per item, or periodically cleansed by the service (although an expiration date, and keeping it even if stale,is memory expensive).
  - Cache would be on [User|Item]
    - TODO: How does it know when a Ancesctor Group has had changed Users?
      
      Naively clear cache?
      
      Get group's list of children users, clear cache for those users?
* Regarding Costs:
- It's not trivial:
- Each single record View/Edit/Update requires a hit to the Db for the record itself, and then the rights.
- Each Retrieve process gets a Page of data. Those Id's are then used to retrieve the rights.The cost is for 20 or so records.
- Initial access times need to be performant.
- Caching needs to be performant.
  - How does NTFS remain performant?

Permissions

Create
Retrieve
List
U

#### Schema

Principal: [PrincipalID, PrincipalType, ParentID, Name] PrincipalToRole [PrincipalID, RoleID] Role: [RoleID, Name] RoleToOperation [RoleID, OperationID] Operation [OperationID, Name] OperationToTarget [OpertionID, TargetID] Target [TargetID, ParentTargetID]

Naive:

SELECT O.Name FROM Operation AS O
INNER JOIN OperationToTarget AS OT ON OT.OperationID = O.OperationID  
INNER JOIN RoleToOperation AS RO ON O.OperationID=RO.OperationID
INNER JOIN PrincipalToRole AS PR  ON PR.RoleID = RO.RoleID
INNER JOIN Principal AS P ON P.PrincipalID = PR.PrincipalID  
WHERE P.Name = ?
AND OT.TargetID = ?

It's naive as:

it doesn't account for revocation, and therefore is not much better than Role authorisation.
it a heck of a honking Join that needs to be cached somehow.