I have a class which is decorated with a ClaimsPrincipalPermissionsAttribute
. The class has a method that is also decorated with a ClaimsPrincipalPermissionsAttribute
. What I expected was:
First, when I instantiate the class, I get a call to my custom ClaimsAuthorizationManager
. This works as expected.
Second, when I call the method, I get two calls to my ClaimsAuthorizationManager
. One with the Resource and Operation from the class level attribute and one from the method level attribute. This does not work. Instead, I get a SecurityException
thrown when I call the method. The exception message is:
Failure decoding embedded permission set object.
To try to see what was happening, I created a custom attribute by copying the code from ClaimsPrincipalPermissionsAttribute
. I can see that CreatePermission()
method is called on my attribute and it returns a ClaimsPrincipalPermission successfully, but the exception is thrown before my ClaimsAuthorizationManager
is called.
My code looks like this:
using System;
using System.IdentityModel.Services;
using System.Security.Permissions;
namespace ConsoleApplication5
{
class Program
{
static void Main(string[] args)
{
var test = new SecuredClass();
test.MethodLevelSecuredMethod();
Console.ReadKey();
}
}
[ClaimsPrincipalPermission(SecurityAction.Demand, Resource = "SecuredClass", Operation = "GeneralAccess")]
class SecuredClass
{
[ClaimsPrincipalPermission(SecurityAction.Demand, Resource = "MethodLevelSecuredMethod", Operation = "Call")]
public void MethodLevelSecuredMethod()
{
Console.WriteLine("Called MethodLevelSecuredMethod");
}
}
}
What am I doing wrong? Is it possible to declare the attribute at both the class and method level?
I am using .Net 4.5.
The problem is occurring because ClaimsPrincipalPermission
does not implement a public constructor that takes a PermissionState
argument. (The need for this is documented at http://msdn.microsoft.com/en-us/library/vstudio/yaah0wb2.aspx, albeit hidden in the middle of the text.)
This is essentially a bug in the framework, which should probably be reported at https://connect.microsoft.com/visualstudio/feedback. If you do so, you might want to add that an FxCop rule to check for the presence of this constructor might be a good idea as well.
Pending a bug fix, your only real option is to re-implement both ClaimsPrincipalPermission
and ClaimsPrincipalPermissionAttribute
if you want to use a declarative approach for claims-based authorization.