Question

I’ve implemented the following action attribute in my MVC solution.

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class AuthorizeADAttribute : AuthorizeAttribute
{
    public string[] Groups { get; set; }      

      protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        if (base.AuthorizeCore(httpContext))
        {
            /* Return true immediately if the authorization is not 
            locked down to any particular AD group */
            if (Groups == null)
                return true;

            foreach (var group in Groups)
                if (httpContext.User.IsInRole(group))
                    return true;

        }
        return false;
    }
}

And invoked it like this:

 public const string Admin = "MY_DOMAIN\\Admins";
 public const string Users = "MY_DOMAIN\\Users";
 public const string AddUser = "MY_DOMAIN\\AddUser";


 [AuthorizeAD(Groups = new string[] { Admin, Users })]
 public ActionResult GridData(...)
 { ... }

 [AuthorizeAD(Groups = new string[] { Admin, Users, AddUser })]
 public ActionResult Add(...)
 { ... }

It seemed like it was working fine so far (locally without a problem), until someone noticed (on another question I posted), that I’ve been receiving 401 errors on the deployed instance.

I think my AuthorizeADAttribute need to be reworked, unless anyone has an idea of what the issue could be on the host environment. The idea is that a user must be in the admin or user group on the active directory to access the site, and if he/she is assigned to the user role, they need to belong to one other group as well, eg: Add, Delete, Update, etc…

So far I’m pretty much stumped :/

Answer 1

It seemed like it was working fine so far (locally without a problem),
until someone noticed (on another question I posted), that I’ve been
receiving 401 errors on the deployed instance

That’s perfectly normal and it is how NTLM authentication works. It’s a challenge-response authentication protocol meaning that the server challenges the client by sending a 401 page to which the client responds, … So the 401s you are seeing are parts of the challenge that the server sent to the client to authenticate himself. You see that in the end the client successfully responded to the challenge and was authenticated with a 200 success.

I don’t think that you should be reworking anything with your custom authorize attribute. It’s just that you probably don’t need it as you could achieve similar functionality with the default Authorize attribute:

[Authorize(Roles = "MY_DOMAIN\\Admins,MY_DOMAIN\\Users" })]
public ActionResult GridData(...)