.NET SQL Authorization Manager

Picture 2

Moreover, the "Basic" Groups are constituted by Members and Not-Members that is users/groups/Store Groups that must be "considered" when creating the Store Group while the not-members are users/groups/Store Groups that must not be considered. In other words, the members list that get part of a Basic group is given by { Members } - { Not-Members}. Since that members/not-members can be, at its turn, others Store Group, it's possible to realize powerful and complex recursive groups. In pictures 3 and 4 we see the Members and Non-Members definition of one Basic group.

Picture 3:

The Store Groups have a restricted visibility at Store level, so to be visibile from all the Applications contained in the Store.

Picture 4:

The Store Group is the ideal in order to implement the concept of "Business Role" that is a grouping of persons in a Company who carry out one determined function with different rights from the rights that every role will have in every application; here some examples of business roles: "Managing", "Employees", "Responsible UO", etc....

Print 1:

LDAP query to include all the Active Directory users whose name begins with Andrea and Dial-In permissions.

(&(objectCategory=user)(cn=Andrea*)(msNPAllowDialin=TRUE))

For all of you interested to know more about the syntax and potentiality of LDAP queries can read this interesting Microsoft article about the LDAP queries syntax: http://www.microsoft.com/technet/prodtechnol/exchange/2003/insider/ldapquery.mspx.

Application and Application Group

For Application we mean that one that will request at run-time the NetSqlAzMan storage; here the definition is purely logical and so it doesn't require any association with the type or name of the real application. To avoid any confusion it's better to assign the same name and maybe writing a little description about what the application does in the appropriate gap as pictures 5 and 6 show.

Picture 5 :

An Application Group is identical to a Store Group except that its scoping (visibility) is restricted only for the Application where is defined; an Application Group may consider a Store Group among its members/not-members but the vice versa cannot never happen.

The Application Group is the ideal to represent "Applicative Roles".



Picture 6:

Item Definitions

Every Application contains the definition of Item. Item contains the types Role, Task and Operation

Logical meanings of items type are defined as follow:

• Role: is a group of "users" that can do the same operations;
  • A Role can have members type such as Role, Task, Operation.
  • Samples of Role are: "Administrator", "General Director", "Product Manager".
• Task: is a logical macro-functionality of the Application
  • A Task can have members type such as Task, Operation.
  • Samples of Task are: "Insert", "Update", "View Report".
• Operation: is a micro- functionality of the Application
  • An Operation can have only Operation members type.
  • Samples of Operation are: "Add new user", "Update user", "View Report 1".

It usually happens that doing a certain operation, it automatically implies doing other ones of a lower level, or this idea can be used to assign authorizations in a hierarchical way.

If we consider, just as an example, "Delete" and "Insert" operations and assume that a users group is authorized to "delete", another one can "insert" and other groups are authorized to both "delete" and "insert".

In this case is necessary to create a "Modify" Task and two "Insert" and "Delete" Operations therefore change the Task properties(from the console) and say that it's constituted by two Operations (members Item). This fact will be important when you'll assign authorizations to these Items, because the Task rights (container Item) wil be inherited from Operation (Item members) but the vice versa will not happen (towards bottom); the one that will be authorized to "modify" will be implicitly authorized to "insert" and "delete" too. In picture 7 there's a sample about this hierarchy.



Picture 7:

When we'll finish creating all the Operation and, aggregate in logical Task of the Application, we can finally say what each applicative Role can do. We create as many Role as they are indicated in the application analysis and we'll specify for each Role which Tasks are part of it.

Biz Rules

For each Item is possibile to define a Business Rule (Biz Rule, that is logical rule). A Biz Rule has to determine if the authorization, eventually assigned for a user that is doing access check (CheckAccess) has to be considered or not. In othe words, this is a way to determine the belongings to an Item or not at Run-Time.

To define a Biz Rule is sufficient to create an Item, therefore confirm the new added from the Snap-In, access the Item properties and press the "Biz Rule" botton.

At this point we can write the .NET source code in C#/VB directly in the rule definitions window, or you can (advised) choose a different language and click on "New Biz Rule", then copy the rule "template" and edit it in a more comfortable environment such as VS.NET 2005.

When we finish writing our source code (and without syntactic errors) you paste the Biz Rule code and press the "Reload Biz Rule" botton. In that moment NetSqlAzMan compiles the rule and generates a .NET assembly in full rule and copies its binary image inside the "BizRules" sql table.

At Run-Time ... the compiled assembly wil be read again from the db (and put it in cache for all the session time) and then executed. If you observe the Execute method firm, its return type is simply a boolean one that, when true makes CheckAccess method to continue otherwise it's interrupted (inside the Item hierarchy). The true difference between MS AzMan and NetSqlAzMan, about the Biz Rule, is the possibility to write Biz Rule in .NET code instead using Scripting (jscript/vbscript) and consequently a great increase of performance at run-time.

Picture 8:

Item Authorizations

Once we've defined all the Item (Role, Task, Operation) and created a right hierarchy among them, we should be worried about "to fill up" these containers with real users/groups and therefore "who ... can do ... what", indicating for everyone their permissions.

"Who" can be one of the following objects:

• A Windows user
• A Windows group
• A Store Group
• An Application Group

"Can do" can be one of the following authorizations:

• Allow with delegation
• Allow
• Deny
• Neutral

"What" will be one of the Item definined before:

• Role
• Task
• Operation

If the Item hierarchy has been correctly built , usually we sould be able to assign permissions only to Roles. When an application will ask NetSqlAzMan ... "can I do an X Operation ?", its run-time will verify whether that operation belongs to a Task , that in turn belongs to a Role of which the application user takes part.

Note 1: If in the NetSqlAzMan console you select one or more Application, or at least the entire Store, it's possible to view the Item hierarchy by clicking the right botton mouse and choosing the "Items Hierarchical View" menu (picture 11).

Picture 9:

We now try to give a meaning to these four available authorizations, just remember that in NetSqlAzMan knows the idea of "delegate", that is a user that delegates another one to do an operation originally allowed only for the first one.

In a particular way that user that has got the "Allow with delegation" authorization can surely do that operation and moreover he can delegate one or more users to do the same operation originally granted to him. This delegate mechanism , for security reasons , cannot be extended beyond the first level. That means that the delegated user cannot delegate another user to do the same operation (Allow with delegation doesn't propagate).

The Allow right grants the authorizations to do that determined Item without delegate right.

The Deny right denies,on the contrary, every authorization while a Neutral type authorization is ,indeed, neutral, that is neither "yes" or "not", but it's the higher level Item to decide about.

The Neutral authorizations exist with their administrative scope and allow to maintain the "who"-"what" association in the store without saying if "what" can or cannot be done . A typical use of a Neutral authorization and for that Item which permissions continually change, and therefore it would be tedious, repetitively, to add and delete authorization subjects from the Storage; it's better to leave it there and modify only the permission when necessary.

One last consideration about the Deny authorization type: if for an Item, a user is authorized to a Deny permission, this user cannot surely do such operation and not even one of the eventually subordinate operations (sons Item) even if one of these is authorized to Allow o Allow with delegation permisssion; as it happens for File System and Sql Server authorizations , the more restrictive permission is successful. Viceversa, if for an Item a user is authorized to both Allow and Allow with delegation permissions, the less restrictive permission is successful that is Allow with delegation.

Attention to this affirmation, that is true only for authorizations allowed on the same Item and doesn't for hierarchical Itemi; Allow with delegation doesn't propagate on sons Item.

In picture 10 the console view where you can set the authorizations.

Picture 10:

Database Users Custom-Authentication

From the NetSqlAzMan ver. 1.3.0.0 is possible to execute the check-access not only through Windows authentication but even through custom authentication for defined users in a MS Sql Server database.

This new functionality exists because of the dbo.GetDBUsers table-function, defined in the NetSqlAzMan storage Database storage. This table-function has to return a list of users defined through a value pair: CustomSid, Username (varbinary(85), varchar(255)).

It's very important to modify, before starting to use this functionality, the GetDBUsers table-function to correctly the list of users from any users table (even from a different Database), previously defined.

At run-time we find 2 methods to retrieve such list (or just a specific user) through the GetDbUsers/GetDBUser functions, defined in IAzManStorage, IAzManStore e IAzManApplication object type.

Finally , for the check-access you should use a specific overload of the CheckAccess function that accepts in input an IAzManDBUser object type, returned by the over cited methods.

In the following picture we see a screenshot that shows an added DB User to which assign the skilled authorizations.

Picture 11:

Finally a DB User, can be added to a Store Group, to an Application Group and directly as an authorization member in the Item Authorization.

NetSqlAzMan is Delegate-compliant

When an authorization is granted by the NetSqlAzMan Administrator, through the administrative console, we are talking properly about "Authorization". The same mechanism can be used during run-time by special users that allow other users to do a determined operation in their place. In this case we are talking about "Delegate".

In order to delegate, the delegant user must have the Allow with delegation permission directly on the Item and must belong to Sql Server: NetSqlAzMan_Users role. In the Sql Storage are present in fact 3 (three) different Database Roles:

• The Item (Role, Task, Operation) delegation object;
• Who is the "delegant" user;
• Who is the "delegated" user;
• The validity time of the "delegation" (from ... to);
• The authorization type to assign (Allow or Deny).

all informations to pass to the NetSqlAzMan.SqlAzManItem.CreateDelegateAuthorization(...) method.

From the first NetSqlAzManStorage class, we can "navigate" in the NetSqlAzMan DOM using the GetXXX() accessories methods or simplier using an indexer, as shown in prints 3 and 4.

Print 3:

C#