Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Role based security, permissions and the Authorization and Profile Authorization Block

The .NET Framework provides good support for role-based security. Once the user is authenticated, I can ask for IsInRole("Administrator") and do whatever I need to do.

The problem with this approach is that the way one assigns permissions to roles is usually dynamic, and hard-coding that in the application logic is not a good idea. For example, if I want to add a new role to my application, I need to go to every place and add logic to enable the role for the specific actions.

The solution to this problem is to define 'permissions', and then assign permissions to roles. Then you ask for the permission:

if (user.IsAuthorizedTo("AddCustomer"))

...

As far as I know there isn't a standard way to solve this with the .NET Framework. You need to roll your own solution.

When I saw the Authorization and Profile and Application Block, I assumed that one of the holes it will fill was this one, when I did a quick-read on the documentation it looks like it did. But it seems I was wrong.
 
In addition of providing roles, you have an 'scope' with 'operations' that you can give permissions to. Below is an example of one of the ways to define the permissions in an .xml file:

<user name="testuser">
  <roles>
    <role name="developer" />
    <role name="approver" />
  </roles>
  <scope name="http://localhost/AzManTestWebService/Math.asmx">
    <operation name="Add" hasAccess="true" />
    <operation name="Subtract" hasAccess="false" />
    <operation name="Multiply" hasAccess="false" />
    <operation name="Divide" hasAccess="true" />
  </scope>
</user>

Each user has roles, and it also has permissions to perform operations in a scope. Now you can do two things for checking for authorization. I can hard-code an IsInRole for the roles, as usual, or I ask is the user is authorized for one operation. But the operations permissions are assigned _per user_, not _per role_!. I don't see the reason to do it this way....

I would really prefer to use the following structure:

<?xml version="1.0" encoding="utf-8" ?>
<authorizationInformation>
  <roles>
    <role name="developer">
 <scope name="http://localhost/AzManTestWebService/Math.asmx">
           <operation name="Add" hasAccess="true" />
           <operation name="Subtract" hasAccess="false" />
           <operation name="Multiply" hasAccess="false" />
           <operation name="Divide" hasAccess="true" />
        </scope>
    </role>
  </roles>
  <users>
    <user name="testuser">
      <roles>
         <role name="developer" />
      </roles>
    </user>
  </users>
</authorizationInformation>

In this case the role has a set of permissions, and then I can ask for the permission in my code, add new roles and assign different permissions for this role.

Am I missing something? Is there any way to do this with the Authorization and Profile Authorization Block? A better way of doing it with the .NET BCL?

 

4 Comments

  • Well, from an ISV point of view -- both of these methods are pretty worthless. (often) The only thing an application can define and check are permissions. Roles are just an end-user convenience for grouping permissions and assigning them to users. So I'll be modifying the block to consume something like this:



    &lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot; ?&gt;

    &lt;authorizationInformation&gt;

    &lt;!-- define all possible permissions here--&gt;

    &lt;scope name=&quot;<a target="_new" href="<a target="_new" href="http://localhost/AzManTestWebService/Math.asmx&quot;&gt;">http://localhost/AzManTestWebService/Math.asmx&quot;&gt;"><a target="_new" href="http://localhost/AzManTestWebService/Math.asmx&quot;&gt;">http://localhost/AzManTestWebService/Math.asmx&quot;&gt;

    &lt;operation name=&quot;Add&quot; /&gt;

    &lt;operation name=&quot;Subtract&quot; /&gt;

    &lt;operation name=&quot;Multiply&quot; /&gt;

    &lt;operation name=&quot;Divide&quot; /&gt;

    &lt;/scope&gt;

    &lt;!-- end user defined roles to permission mappings / either list all w/ permission or specify a level --&gt;

    &lt;roles&gt;

    &lt;role name=&quot;developer&quot;&gt;

    &lt;scope name=&quot;<a target="_new" href="<a target="_new" href="http://localhost/AzManTestWebService/Math.asmx&quot;&gt;">http://localhost/AzManTestWebService/Math.asmx&quot;&gt;"><a target="_new" href="http://localhost/AzManTestWebService/Math.asmx&quot;&gt;">http://localhost/AzManTestWebService/Math.asmx&quot;&gt;

    &lt;operation name=&quot;Add&quot; /&gt;

    &lt;operation name=&quot;Subtract&quot; /&gt;

    &lt;/scope&gt;

    &lt;/role&gt;

    &lt;role name=&quot;admin&quot;&gt;

    &lt;scope name=&quot;<a target="_new" href="<a target="_new" href="http://localhost/AzManTestWebService/Math.asmx&quot;&gt;">http://localhost/AzManTestWebService/Math.asmx&quot;&gt;"><a target="_new" href="http://localhost/AzManTestWebService/Math.asmx&quot;&gt;">http://localhost/AzManTestWebService/Math.asmx&quot;&gt;

    &lt;operation name=&quot;Add&quot; /&gt;

    &lt;operation name=&quot;Subtract&quot; /&gt;

    &lt;operation name=&quot;Multiply&quot; /&gt;

    &lt;operation name=&quot;Divide&quot; /&gt;

    &lt;/scope&gt;

    &lt;/role&gt;

    &lt;/roles&gt;

    &lt;users&gt;

    &lt;user name=&quot;testuser&quot;&gt;

    &lt;roles&gt;

    &lt;role name=&quot;developer&quot; /&gt;

    &lt;/roles&gt;

    &lt;/user&gt;

    &lt;user name=&quot;testuser2&quot;&gt;

    &lt;roles&gt;

    &lt;role name=&quot;developer&quot; /&gt;

    &lt;role name=&quot;admin&quot; /&gt;

    &lt;/roles&gt;

    &lt;/user&gt;

    &lt;/users&gt;

    &lt;/authorizationInformation&gt;



  • sry about the formatting :/

  • Chadb,



    Yes, you are right. I was thinking in that approach but my XML was wrong ;)



    Thanks!

  • I'm not sure I understand the gap you see. The AuthPro block simply uses Authorization Manager (AzMan) behind the scenes (doesn't it?). If you open mmc.exe and add the Authorization Manager Add-In to your console, you'll have full control over the permission elements. In the basic view of things, you can add Roles to an Application, Tasks to a Role, and Operations to a Task. You can then associate Windows users or groups with Roles. There's also a lot of mix and match of the above.



    I find it to be pretty flexible. It allows the developer to test against Operations and lets the rest be configurable. I hope the AuthPro block doesn't somehow limit its flexibility.

Comments have been disabled for this content.