IT:AD:NETSqlAzMan:HowTo:Configure

(UP)

Summary

NetSqlAzMan is a Permission's Based Authorisation Service (PBAC), so configuration is done by assigning Permissions to Users.

It is not assigning Roles to Users, as in a Role Based Authorisation Control (RBAC) system.

It is not assigning Permissions to Objects (as in a Discretionary Authorisation Control (DAC).

Note:

N

ETSqlAzman only sums up Operations – you can't assign a Role to a User, and remove one or more Operations from it.

Configuration is done as follows:

* Once created, find the custom MMC:

Open the MMC.

Note:

A

Store is just a logical partition.
Think of it as a group of Settings appropriate for a whole Business, or other group, that would contain one or more Applications.
Most scenarios only require one Store.

First time you open the MMC it will be empty (nothing in the Db yet), so you have to create a new Store:

Within the Store, you will have n Applications.
- Let’s just start off with one: App1:

It's important to stop for a second and understand the following before continuing.

There is one MMC, with one tree in it, but there are two distinct groups of settings that need to be configured independently:
* One is the Groups/Users (whether specific to an Application or a company Store)

*

The other is the Roles, Tasks, Operations that are associated to these Groups/Users.

>

![05b](https://dl.dropbox.com/u/11851202/PUBLIC/SKYS/Posted/IT/About/NetSQLAzman:HowTo:General/NETSqlAzman_Intro_05b.png)

Once the above is understood, we can continue onwards.

Configuring Groups and Users is straightforward: just create Groups and assign Users and/or nested Groups to them.

Create a Group within the scope of the Application:

>Note that there are two levels at which you can create `Groups`:

* at the `Store` level, so that the `Group` is available to all Apps in the store (eg: `Administration`, `Accounting`, `TechSupport`),* at the `Application` level, so that the `Group` specific to a single App (eg: `App1Users`).

Once the Groups are created you can add Users to them from either:

the registered local machine Windows identities, or
Active Directory domain Windows identities, or
override the method in the script that allows for it to get smart.

Read the manual for that…(or bottom of this:http://bit.ly/fxuF93)

Once you have Users and Groups, you create and assign Permissions to each user.

It is is important to notice that under an `Application` there are *two* distinct nodes to do with `Roles`, `Tasks`, `Operations`.
This is because the first step is used to *define* the permissions, whereas the second step is for *assigning* roles to a user:

Define Roles, Tasks, and Operations.

As mentioned here (http://bit.ly/h7e1ow) Operations are low level and developed by the application developer, which are then mapped to Tasks in order to be understood by the BA.

They can be nested:
- Roles (eg: Accountant) can contain other Roles, Tasks, and Operations
- Tasks (eg: WriteInvoices) can contain other Tasks, and Operations (but not parent roles)
- Operations (eg: CreateInvoice, RetrieveInvoice, UpdateInvoice, DeleteInvoice) can contain only other Operations:

The point is that our software is going to be checking Operations, which are key fine grain elements we have to work with on a daily basis.

But its tedious assigning at such a fine grain level (too many of them), so we group them as Tasks, and group Tasks as Roles, which we assign to Groups.

Roles:

Tasks:

Operations:

So that any person who is in the Role App1Admin, will be able to do the Operations associated to Task1, which are CreateInvoice, RetrieveInvoice, UpdateInvoice – but not DeleteInvoice.

So at this point, you have two halfs…on one side of things you have groups/users…and on the other you have Roles, Tasks, Operations…but you havn’t assigned anything to anyone.

To do that, switch to the second node – the authorization node: