We are using a custom principal and identity type (ProdigyPrincipal/ProdigyIdentity) because we need extra information within our programs and services. In the program we set th
WCF has a more standard way of achieving the same goal, via a ServiceAuthorizationBehavior.
If you set its PrincipalPermissionMode property to "Custom", it allows you to provide a custom IAuthorizationPolicy
via which you can make a custom IPrincipal
available to the WCF ServiceSecurityContext. The DispatchRuntime will assign this (your custom) IPrincipal to Thread.CurrentPrincipal - which is what you're after, right?
This is a sample IAuthorizationPolicy implementation:
public class DemoAuthorizationPolicy : IAuthorizationPolicy
{
private readonly string id = Guid.NewGuid().ToString();
public string Id { get { return this.id; } }
public ClaimSet Issuer { get { return ClaimSet.System; } }
public bool Evaluate(EvaluationContext context, ref object state)
{
// Here, create your custom principal
IIdentity customIdentity = new GenericIdentity("myUserName", "myCustomAuthenticationType");
IPrincipal customPrincipal = new GenericPrincipal(customIdentity, new[] { "user", "powerUser" });
// Set EvaluationContext properties
context.Properties["Identities"] = new List { customIdentity };
context.Properties["Principal"] = customPrincipal;
return true;
}
}
And this is how you declare the ServiceAuthorizationBehavior in the Web.config:
Inside your service you can then leverage declarative security via the [PrincipalPermission]
attribute, you can get the custom IPrincipal from Thread.CurrentPrincipal
, and (alternatively) you can also get the custom IIdentity from ServiceSecurityContext.Current.PrimaryIdentity
.
Hope that solves your issue!