Application Scope equivalent?

Oct 30, 2009 at 5:57 PM

Our security needs include the ability to have the same sets of rights applied to different locations.  Using AzMan I have been able to create an application and associate all the operations, tasks, and roles with only the 'top' level application.  Then I create scopes for each location and just create role assignments.  Is there similar functionality in NetSqlAzMan and if so how does it work?

Thanks!

Coordinator
Nov 2, 2009 at 9:16 PM

Hi,

NetSqlAzMan replace “Scope” concept using Authorization Attributes (Key/Value).
Attributes are simply a List of Key Value pair (string/string) that are returned when you perform a check access.

You can use it to “scope” an authorization.

I.E.:

Key: “Customer

Value: “ALFKI”

To allow an operation to a Customer only.

For further information see Attributes inside the NetSqlAzMan Guide.pdf (download section).


Regards,

Andrea.

__________________________________
Andrea Ferendeles
NetSqlAzMan Project Coordinator  
E-mail aferende@hotmail.com Web http://netsqlazman.codeplex.com

Nov 3, 2009 at 3:11 PM

Could you elaborate a little more on how this can be accomplished using Attributes? 

I have an application currently defined in AzMan with a set of operations, tasks, and roles.  I have also created three role assignments (SuperUser, Authorizer 1 and Authorize 2) at the main application level.  The only AD accounts to be added at the application level will be into the SuperUser role since their rights apply across all scopes.  Then there will be a scope definition for each of our 17 properties.  Role assignments will be duplicated for each role except SuperUser.  Then AD accounts can just be added to the scope role assignment where they belong (this can be a single scope or multiple scopes for multi-property access).

The only way I can see this being accomplished with attributes is to assign an AD account to a Roles Authorization, then go into that user and manually add attributes that correspond to the properties they have rights to (any combination of 17 properties).  This would then be repeated for every user.  Is this correct?  I hope not because it would be a pain to manage and could easily allow for mistakes during user setup.

Thanks for the info!

Coordinator
Nov 13, 2009 at 5:04 AM

Hi,

Consider this example:

MS AzMan:

Scope 1

-> Role 1

  -> Operation 1

   -> User A is authorized on Operation 1 (scope 1)

-> Role 2

  -> Operation 2

   -> User B is authorized on Operation 2 (scope 1)

Scope 2

-> Role 1

  -> Operation 1

   -> User C is authorized on Operation 1 (scope 2)

-> Role 2

  -> Operation 2

   -> User D is authorized on Operation 2 (scope 2)

NetSqlAzMan equivalent (but better J)

-> Role 1

  -> Operation 1

   -> User A is authorized on Operation 1

    -> User A has an attribute on this authorization (key: ScopeName: Value: Scope 1)

   -> User B is authorized on Operation 2

    -> User B has an attribute on this authorization (key: ScopeName: Value: Scope 1)

-> Role 2

  -> Operation 2

   -> User C is authorized on Operation 1

    -> User C has an attribute on this authorization (key: ScopeName: Value: Scope 2)

   -> User D is authorized on Operation 2

    -> User D has an attribute on this authorization (key: ScopeName: Value: Scope 2)

At run time ... when you perform a CheckAccess ...

List<KeyValuePair<string, string>> authorizationAttributes;

bool isAuthorized = storage.CheckAccess(storeName, AppName, "Operation 1", "User A", ... out authorizationAttributes);

//NetSqlAzMan LINQ query … to retrieve Authorization Attributes

string[] authorizedScopes  = (from t in authorizationAttributes.Keys where t.Key == "ScopeName" select t.Value).ToArray(); //All authorized scopes

Regards,

Andrea.

__________________________________
Andrea Ferendeles
NetSqlAzMan Project Coordinator  
E-mail aferende@hotmail.com Web http://netsqlazman.codeplex.com

Mar 3, 2010 at 8:58 PM

A couple questions:

1) Is there a way to build this out at other levels other than the User level and still have it work the same?

I'd like to be able to place attributes at the Role level that'll work as you stated on the user level. So here's the scenario:

All roles allowed to call a common Operation named "opCreate":

Scope A

Role - A Enterprise Admin (Scope A & Scope B Attributes)

-- Role - A Plant Admin

---- Role - A Data Entry

Scope B

Role - B Enterprise Admin (Scope B Attribute Only)

-- Role - B Plant Admin

---- Role - B Data Entry

From my testing, having added the scope attributes shown to Role A and Role B Enterprise Admins, a "User 1" in the "Role - B Data Entry" role had Scope A access, even though the Scope A attribute wasn't on their role or the user ID. This is a showstopper at the Role level (any level other than User). So though it works at the user level, that would mean a ton of maintenance in having to make sure a particular user has specific scope-level attributes every time their name is added anywhere. So I'm hoping I'm missing something, but I'd love for this to work at the Role level and other levels so I can truly have more of an original AzMan resemblance of Scope with little overhead in maintenance of those scopes.

2) Is there a way to nest the attributes so a Scope A can contain a Scope B and thereby anyone with any level of permission within Scope A automatically has permission to Scope B?

This would obviously be similar to the fact that Roles can contain other Roles. It would, however, be specific to Scopes in their definition. Currently, the only way I can see to do this using your Attribute model is to have the scopes live as siblings on an entity in the list vs. one scope actually being a parent over the other.

Thank you for any help you're able to lend!!!

Boyd

Coordinator
Mar 3, 2010 at 9:37 PM

Hi Boyd,

1) NetSqlAzMan allows to define attributes at:

a. User Authorization level (when you authorize a User U1 on a Role R1, you can add an attribute on the user authorization)

b. Item (Role/Task/Operation) level (when you define an Item (R/T/O) you can “attach” an attribute A1 on this Item R1. This means that two users belonging the same Role R1… will have same the same attribute A1

In general:

- MS AzMan scopes means … item definition redundancy to allow different authorizations

- NetSqlAzMan attributes means same authorizations with different aims..

2) The best way to define a hierarchical attributes (Key/Vakue) is to define a hierarchical value using an xml value.

i.e.:

               Key: “My Family Attribute”

Value:

<grandFather name=”Sam”>

<father name=”John”>

                <son name=”Alan” age=”18” />

                <…>

</father>

<grandFather>

Regards,

Andrea.

__________________________________
Andrea Ferendeles
NetSqlAzMan Project Coordinator  
E-mail aferende@hotmail.com Web http://netsqlazman.codeplex.com