About NetSqlAzMan

For all of you who already knows MS Authorization Manager (AzMan) or ADAM (Active Directory Application Mode) then you are in the right place … but you have to expect a lot of innovations.

Security within the applications

// When we talk about applicative security it’s possibile to write symbolically the following expression:
{ Security } = { Authentication } + { Authorization }

where for Authentication we mean the credentials phase (who are you?) and for Authorization, what a user is granted to do and what he isn’t (what can you do?). Generally, the authentication moment happens at first, and it’s enough to assess once the user credentials to avoid repeating every time (at run‐time) the same operation (think the “logon” moment on your pc).

The second phase supposes that the user credentials have already been verified and therefore the user identity is “assessed” and “well‐known”. At this point, the Authorization system is able to reply to a user request to execute a determined operation, for example, retrieving all the necessary informations from any data source (for example File System’s ACL ). To do an example, you can think when you go to the airport to take a flight.

When you are at the Check‐In, you are asked of an airplane ticket and an identity document so that you can have a security ticket back, the “boarding pass” (Authentication). At this point, and only after having got the boarding pass, you can go to the right exit of your flight. Once, inside the boarding zone, you aren’t authorized to take any flight but exclusively the one indicated on the boarding; such rule is completed at the boarding moment (Authorization) and only with the right “ticket”. I excuse myself if this example has turned out banal but it’s very important to do clarity, in order to understand in which context NetSqlAzMan is placed.

Well, NetSqlAzMan is just what stores and preserves the authorizations, giving us an answer like “yes, autorized” or “no, not authorized” to anyone that makes a request (applications).
NetSqlAzMan is leaned instead on MS Windows operating system in order to carry out the authentication phase (Kerberos / NTLM).
We try to understand with a concrete example, the mechanism of the authorizations in an applicative context. We imagine a managerial application of any Company. Inside this Company we can identify some “Business Roles”such as: the administrator, the leaders, the secretaries, the employers etc. and some “Applicative Roles” that is groups of persons that can do the same operations in that Application. Suppose that the application ,you are writing, has functions about business accounting management, warehouse management and so on.

This application has to work with different user levels. As example, consider the “view – end‐year budget” function, that lists in detail all the costs and revenues of an entire year of activity. It’s reasonable to say that such operation must be granted only to the company administrator and maybe to some leaders but not to the employers. Moreover it’s reasonable to think that the administrator or one of his leaders wants “to delegate” this operation to one of his secretaries, or grant (temporarly) the permission for such operations.

// Now, how it’s possibile to realize such an application, without “wire” the following instructions inside the source code:
If (user = “Jack” or user = “Michael”) then
(authorized)
Else
(not authorized)

First of all, we should separate the “single customer” from the “group of customer” idea, that is, a set of users to which an operation will be granted.
// At design time, we’ll decide which user will belong to which group:
If (user belongs to “Administrators” group) then
(authorized)
Else
(not authorized)

So we are introducing a too strong association between “groups” and what “they can do”.
What will happen if tomorrow we decide to move a function from one group to another?!

// Then we try to operate another process and say:
If (user has been authorized to do that X operation) then
(authorized)
Else
(not authorized)

You’re doing now the easiest thing , that is, to ask yourself if that user can or cannot do such function, without taking in consideration his name or his group/role. The only link aspect betweeen the application and the authorizations repository is the process name. All these names together defines “a contract” and, this is binding; if you change a process name in the application or in the repository, it’s necessary to change its name in the other part, too.

The unique user identification is provided by the Authentication system (Windows), while the Authorization system will answer “yes” or “no” to the “he has been authorized to do that X operation” question. It’s therefore necessary to have a table with the “process name” and the relative “yes” or “no” for each user/group in any repository. The NetSqlAzMan repository is called Storage and is hosted by a Sql Server database (the setup package contains the Sql Script 2000/2005/2008 version).

Andrea Ferendeles.

Last edited Oct 20, 2009 at 4:52 PM by aferende, version 1

Comments

No comments yet.