Custom CodeAccessSecurityAttribute That Takes Many Roles

Question

I'm working on some Role-based security for our app and I essentially want to do customized verison MVC's AuthorizeAttribute - but only at the business logic layer, where we don't link to MVC.

I've looked at PrincipalPermissionAttribute but it seems it doesn't have a way to customize it as it's sealed. I just want to create a custom version where I can check for membership in any of a list of roles without using multiple attributes, and also define where to look for the role membership.

Is there anything like this in .Net that I'm missing? Or does anybody have some insight on how to do this without reimplementing ASP.Net's AuthorizeAttribute/RoleProvider/etc?

EDIT

I currently have a imperative version running, but I'd rather have a declarative-attribute version, as it's easier to see it above the method/class.

Right now I have the following in an abstract base class for my business layer:

protected void EnsureEditorLevelAccess()
{
    var allowedRoles = new[]
                            {
                                Roles.Administrator,
                                Roles.Editor,
                            };

    var roles = GetAccountRoles(GetCurrentUsername());

    if (roles.Any(role => allowedRoles.Contains(role)))
    {
        return;
    }

    throw new SecurityException("You do not have sufficient privileges for this operation.");
}

I like being able to use Roles.Administrator etc because the role names are hideous (Active Directory group based...), so I was thinking of wrapping those details up in the constructor of a custom attribute that I can just plop on top of classes/methods.

GetAccountRoles is just a facade over an injectable role-provider property, which I can set to use either AD or a testing version that uses the database.

I could subclass Attribute, but not sure how it would kick off the security check.

Nicole Calinoiu · Accepted Answer · 2011-12-02T18:58:14.183

You can create a new attribute that uses the existing PrincipalPermission if that would be sufficient for your needs. If your existing imperative implementation uses PrincipalPermission, then this should be the case. However, if your imperative version does something else, you may need to consider implementing both a custom permission and a corresponding attribute. If you're not sure whether this is necessary, perhaps you could share some details regarding your current imperative approach...

After question update...

It's actually possible to use "any" logic with PrincipalPermission, although it requires unioning of multiple instances, which is not particularly practical to work with in an attribute. This makes it much more reasonable to create a custom attribute, which might look something like the following:

[Serializable]
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple = true, Inherited = false)]
public sealed class AnyRolePermissionAttribute : CodeAccessSecurityAttribute
{
    public AnyRolePermissionAttribute(SecurityAction action)
        : base(action)
    {
    }

    public string Roles { get; set; }

    public override IPermission CreatePermission()
    {
        IList<string> roles = (this.Roles ?? string.Empty).Split(',', ';')
                                .Select(s => s.Trim())
                                .Where(s => s.Length > 0)
                                .Distinct()
                                .ToList();

        IPermission result;
        if (roles.Count == 0)
        {
            result = new PrincipalPermission(null, null, true);
        }
        else
        {
            result = new PrincipalPermission(null, roles[0]);
            for (int i = 1; i < roles.Count; i++)
            {
                result = result.Union(new PrincipalPermission(null, roles[i]));
            }
        }

        return result;
    }
}

Unfortunately, you can't use arrays in security attributes, so the role list has to be represented as a string. e.g.:

[AnyRolePermission(SecurityAction.Demand, Roles = "Foo, Bar")]

You could use it with your constants via design-time concatenation. e.g.:

[AnyRolePermission(SecurityAction.Demand, Roles = Roles.Administrator + ", " + Roles.Editor)]

As for your custom role provider, the appropriate place to use it is in the thread principal, not the permission or attribute. For example, if you're currently using a GenericPrincipal, you could replace it with a custom principal that uses your custom role provider to retrieve the target identity's roles.

@JeffN825: You can't use an array because the CLR mechanism that handles permission attributes does not support it. This is just one of quite a few peculiarities of permission attributes that is not included in the MSDN docs. — Nicole Calinoiu, Dec 05 '11 at 15:54
Thanks...interesting...doesn't the value of the array get compiled into the assembly though? Any idea why/how the CLR doesn't support it? — Jeff, Dec 05 '11 at 16:04
@JeffN825: The underlying "why" is probably because array properties on an attribute are not CLS-compliant, so the CLR team probably decided that it wasn't worth the bother. (It would be extra work because the security attributes aren't represented the same way as standard attributes in the assembly metadata. See http://blogs.msdn.com/b/shawnfa/archive/2010/04/21/declarative-security-and-reflection.aspx for more details.) — Nicole Calinoiu, Dec 05 '11 at 16:32

score 0 · Answer 2 · answered Dec 02 '11 at 15:44

0

You could derive your own CodeAccessSecurityAttribute and implement your logic around the Thread.CurrentPrincipal (http://msdn.microsoft.com/en-us/library/system.security.permissions.codeaccesssecurityattribute.aspx).

essentially, you'd want to verify allowedRoles.Any(r => Thread.CurrentPrincipal.IsInRole(r))

answered Dec 02 '11 at 15:44

Jeff

35,755
15
108
220

Yes, this sounds exactly what I want to do, but not sure how I override the mechanic of "verify this permission" to the above "verify we have one of these permissions". – Alex Moore Dec 02 '11 at 17:26

Custom CodeAccessSecurityAttribute That Takes Many Roles

2 Answers2