views:

37

answers:

0

Hi,

I'm currently developing a member administration for a local association here and I'm developing the database schema at the moment. I'd like to share it with you to improve it and give other an example of a Role Based Access Model (RBAC). I'd appreciate any constructive criticism especially about the relationships I used between the tables.

Link to highres: http://i.imgur.com/WG3Vz.png

Heres the schema: DB Schema

How it works:

I'm mapping existing clients (actually members of the association) from an external application into my administration application. (clients table)

The association is structured in Division, Subdivisions, etc. (intern_structures table). Every client can be a member in multiple Division, Subdivisions, Sections etc.

Every client can have one or multiple roles in such memberships (divisions,...) like President, Actuary, Treasurer etc. and each role has certain privileges which the owner of the role can apply on others in his Division,Subdivision,Section etc.

A credential is connected to a certain action of an application. The owner of the credential may execute this action on other members in his scope. There can be multiple "standalone" applications but they all share the same authentication/authorization system.

An application is structured in Modules/Submodules/Actions etc. An example could be a "Personal Details" module and this module contains a submodule called "Picture" and you could apply the actions "view,delete,edit" on this picture. But you can't delete any picture unless the person whose picture you try to delete is in a division/section where you have the adequate role to do so.

The internal and application structure are both trees, implemented as adjacency list and nested set. The adjacency list ensures the integrity and the nested set allows me to traverse the tree quickly.

An exception is that you can give someone certain credentials directly (client_credentials). This is needed if someone needs to perform certain actions on somebody who isn't in his divsion/section.

So, someone can be a member in multiple divsions/sections and obtain multiple roles in every division/section he's a member of. I'm going to merge all credentials someone has through his multiple roles. And credentials are always positive, means restrictive credentials are not possible.