Code is ignoring PrincipalPermission attribute?

Question

I have a Delete method on all my business objects that has the PrincipalPermission attribute on it.

Example:

[PrincipalPermission(SecurityAction.Demand, Role = "Vendor Manager")]
        public static bool Delete(Vendor myVendor)
        {

            //do work here
        }

The problem is that it appears to be completely ignoring my PrincipalPermission. It lets anyone through, no matter what role they may be part of.

Is there something else I've forgotten to do? I have added the following to my Application's global.asax in the Application Startup section:

AppDomain.CurrentDomain.SetPrincipalPolicy(System.Security.Principal.PrincipalPolicy.WindowsPrincipal);

But that doesn't make any difference either.

I also just tried the following:

public static bool Delete(Vendor myVendor)
        {
            PrincipalPermission iPerm = new PrincipalPermission(null, "Vendor Manager");
            iPerm.Demand();

            //do work here
        }

and wouldn't ya know, this works just fine!.... any ideas on why it works one way but not the other?

Steven · Accepted Answer · 2011-01-02T12:39:22.167

2

Did you get an answer for this? I just tested this in my own application and it works pretty well. I'm specifically NOT adding

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);

And, I'm using Forms Authentication (ASP.NET Membership), MVC 2, .NET 3.5.

I did however discover if I decorate my class with the following my method decorations do not work.

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]

edited Jan 02 '11 at 12:39

answered Jan 02 '11 at 03:22

Steven

860
6
24

1

Anyone know why method decorations don't work if you decorate the class with what @Steven notes? I'm experiencing the same. – JasonS Jan 24 '12 at 07:02
1

Here is the answer: http://connect.microsoft.com/VisualStudio/feedback/details/95127/nested-principalpermission-not-applied – JasonS Jan 24 '12 at 19:04
That answer is gone. Perhaps describe it in a comment? – Erick Smith Mar 25 '15 at 14:55

score 1 · Answer 2 · edited Oct 11 '12 at 06:48

1

Only one observation for any people that says that sample does not work. Check the name for the role according with your local culture. For example, if you resides in Mexico, you must to use: @"BUILTIN\Administradores" instead of @"BUILTIN\Administrators".

edited Oct 11 '12 at 06:48

Himanshu

31,810
31
111
133

answered Jul 04 '12 at 19:46

cfqueb

11
1

score 0 · Answer 3 · answered Nov 08 '10 at 21:42

0

Have you validated that the Windows principal doesn't happen to have the permission you're requiring? Something like this (modified from here) -- I would think -- should mimic that behavior and allow you to step through. It should indicate whether or not the permission is granted.

If this passes, then I would expect the attribute to pass on through as well. If this fails, but the attribute passes through, then I'm as stumped as you are.

static void Main(string[] args)
{
    AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
    PrincipalPermission principalPerm = new PrincipalPermission(null, "Vendor Manager");
    try
    {
        principalPerm.Demand();
        Console.WriteLine("Demand succeeded.");
    }
    catch (Exception secEx)
    {
        Console.WriteLine("Demand failed.");
    }
    Console.ReadLine();
}

answered Nov 08 '10 at 21:42

Steven

1,260
9
22

Ha.. I just tried this. I added code like this to the beginning of the Delete method and it properly validates the user when done that way. Hrmph! – Amanda Kitson Nov 08 '10 at 21:52
@Amanda -- Hm...that is frustrating. I tried to do what you (originally) did, and added a method with that attribute. It seemed to correctly "demand" the role for me; it took a while, but a Security Exception was eventually thrown when I tried to invoke a method that required the "Vendor Manager" role. I'm not sure why it's acting flakey for you (??) – Steven Nov 08 '10 at 22:16
Actually, I just noticed that you mentioned global.asax. I'm not real familiar with ASP.Net, but I wonder if that's the the discrepency. I've done all my testing in a Console application, and the attribute seems to work as expected in that environment. – Steven Nov 08 '10 at 22:21
Ya.. it works properly when I'm doing my unit testing. Just not when it's coming from my web application, which is in a separate project from the BLL layer (which is where this code is located). – Amanda Kitson Nov 09 '10 at 12:54

Code is ignoring PrincipalPermission attribute?

3 Answers3

Linked