Structure for permissioning documents operations per person

Aug 31, 2010 at 6:05 PM

Hi Andrea, I'm working on using .NetSqlAzMan to replace the security for an application that allow admins to upload documents and users or groups can do certain operations on these documents. For instance, see them in the list, view, print, save, copy, administer.  It sounds like these would be good candidates for operations and the Document securing application is another 'Application' in .NetSqlAzman console. I don't see any tasks for this application. Roles: I could have a precanned set of operations behind a role name like Document viewer, editor, administrator, etc.  I see I can add a person or group to an operation, but without the document dimension that would allow that user do that operation on all documents.  My question is how do you model access to resources like documents for individuals. Attributes? For example you have a 100 documents and perhaps 3-4 different people can access a document in different ways (perform operations). 

Doc1 - Joe can view, write, print

Doc1 - Andy can view, write, print, copy

Doc1 - Sally can view

Doc2 - Frank can view, write, print, copy, save

Doc2 - Sally can view, write


TIA, Steve

Aug 31, 2010 at 8:07 PM


I would make as many roles as there are possible combinations of operations (that make sense).

For example:

· Role: "Document Reader"

- Operations: "Read"

· Role: "Document Printer"

- Role members: "Document Reader"

- Operations: "Print"

· Role: "Document Owner"

- Role members: "Document Printer"

- Operations: Write, Save

and so on.

Then create a Role permission (Allow) for user Joe for the Role "Document Printer".

On this authorization add an attribute like this:

Attribute Key: "Documents"

Attribute Value: "c:\Document1.docx", "d:\path\otherDocument.doc" [and so on].

At runtime make a two phase Check Access.

In the First Phase make a classic NetSqlAzMan CheckAccess retrieving also the Attributes collections.

If the user is authorized (Allow or AllowWithDelegation) goto Phase 2.

In the Phase 2 get the attribute values and check of user is authorized for the specified document.

I hope this will help you.



Andrea Ferendeles
NetSqlAzMan Project Coordinator
E-mail Web

Sep 1, 2010 at 10:29 PM


Just wanted to share what we came up with.  We find we need greater depth and resolution in the Azman heirarchy. Currently there is store/app/roles/operations. If you have an application that allows users to view/edit/print/etc a resource where the permission for each of these operations needs to be configurable putting them in the attributes (whether all under one value or appending a 1,2,3 after the key name, i.e. doc1=my1stDoc.doc  doc2=my2ndDoc.doc doc3=my3thDoc.doc etc.) The problem with the first is attribute value is not scalable and could present an issue if the DB column length is reached, besides you have to scan the list. The 2nd approach leads to an issue where getting a list of the documents in the system first requires you to visit each operation then all people then their attributes to find the document names.

Instead of think of the azman application as a pure application name you might think of it as a resource like a document or printer. So we append a separator (/ for instance) then the resource name to the application name (instead of just the application)  appname = SecureResourceApp/<ResourceName>, where ResourceName could be any string representing the resource (my1stDoc.doc, printer, etc).

Call IAzManApplication[]  IAzManStore.GetApplications() to get resources for the SecureDocumentApp by doing a string compare or grep.  Managing operations and people doing operations on that resource are straight forward.