Unexpected behavior PrincipalPermissionAttribute

[Guest]

Hello,

We have encountered some obscure and unexpected behavior of
PrincipalPermissionAttribute, if applied to both a class as well as a method
in this class. The class permission seems to form an inclusive or with the
method permission.

We have a different scenario ourselves, but we will take an example of MS:
http://weblogs.asp.net/scottgu/arch...yers-using-PrincipalPermissionAttributes.aspx

<quote>

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
public class EmployeeManager
{
[PrincipalPermission(SecurityAction.Demand, Role = "Manager")]
public Employee LookupEmployee(int employeeID)
{
return null;
}

[PrincipalPermission(SecurityAction.Demand, Role = "HR")]
public void AddEmployee(Employee e)
{
// todo
}
}

In the above example, I have added a PrincipalPermission attribute to the
"EmployeeManager" class. By adding it I am requiring that a user must be
authenticated (logged-in) before this class can be instantiated during a web
request (the Authenticated=true demand enforces this). I have also then
added two additional security demands on the "LookupEmployee" and
"AddEmployee" methods. With the LookupEmployee method I am requiring that
the authenticated user for the request is within the "Manager" role in order
for the method to be invoked. With the AddEmployee method I am requiring
that the authenticated user for the request is within the "HR" role in order
for this method to be invoked and have a new Employee added to the
system.</quote>

Unfortunately this does not seem to work. Access to LookupEmployee is now
provided to ALL USERS WHO ARE AUTHENTICATED.

See testcode below.

My question:

- Am I missing something here? And, if not:
-> Is this by design? If so, this may be reconsidered because many people
are missing the point here
-> Is there a workaround. In our case, we want to provide access to class C
if the user is a member of role A or B. Moreover we only want to provide
access to method RequireB if the user is a member of role B. Hence, if the
user is in role A but not in B, it can access the class but not the method
RequireB. How could this be achieved declaratively [using standard framework
objects, because otherwise we are required to deploy our custom permission in
the GAC]

Regards,
Martijn Kaag




Testcode. Call Submit2MSDN.Test() to reproduce:

class Submit2MSDN
{
public static void Test1()
{
try
{
System.Threading.Thread.CurrentPrincipal = new
GenericPrincipal(new GenericIdentity("Not A Manager"), new string[] { "HR"});
EmployeeManagerNew man = new EmployeeManagerNew ();
man.LookupEmployee(1);
throw new InvalidOperationException("Test 1 failed.");
}
catch (SecurityException)
{
// as expected
}
}

public static void Test2()
{
try
{
System.Threading.Thread.CurrentPrincipal = new
GenericPrincipal(new GenericIdentity("Not A Manager"), new string[] { "HR" });
EmployeeManager man = new EmployeeManager();
man.LookupEmployee(1);
throw new InvalidOperationException("Test 2 failed.");
}
catch (SecurityException)
{
// as expected
}
}

public static void Test()
{
Test1(); // Succeeds
Test2(); // Fails!!!!!!!!!!
}
}

public class Employee { }

// No permission here
public class EmployeeManagerNew
{
[PrincipalPermission(SecurityAction.Demand, Role = "Manager")]
public Employee LookupEmployee(int employeeID)
{
return null;
}
}

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
public class EmployeeManager
{
[PrincipalPermission(SecurityAction.Demand, Role = "Manager")]
public Employee LookupEmployee(int employeeID)
{
return null;
}

[PrincipalPermission(SecurityAction.Demand, Role = "HR")]
public void AddEmployee(Employee e)
{
// todo
}
}

 

[Walter Wang [MSFT]]

Hi Martijn,

This issue is documented here:

#Feedback: Nested PrincipalPermission not applied
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba
ckID=95127


The cause is that in .NET 2.0, the behavior is unioning the
PrincipalPermissionAttribute applied to the class level and method level.
At a first glance, this behavior does looks counter-intuitive, please refer
to the feedback above to see why the product team made this decision. I'm
sorry for any inconvenience it caused.

One workaround for your scenario would be to have the method level
principal demands be imperative demands instead of declarative. This will
mean that the current principal would have to satisfy both class-level and
method-level demands. The method-level imperative demand will not replace
the class-level declarative demand.

Another workaround will involve subclassing. You could inherit from the
class that has a class-level demand and stick method-level demands on the
inherited class. Calling the method on the inherited class will invoke a
demand for exactly what's on the method-level, as long as the inherited
class does not have class-level demands.

Sincerely,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Hi Walker,

Thanks for your response.

I fully agree with the comments made by rob in the link you send me. I
believe this is a poor design choice that might have opened up quite a few
unnoticed security holes at MS customers.

However we will proceed using just method level permissions and remove all
our class permissions to avoid confusion and mistakes. Where needed, we will
(and do) implement imperative security demands.

Regards,
Martijn Kaag

______________________________
www.VECOZO.nl