Question

I have defined a custom IPrincipal and custom IIdentity based on a website that defines both valid identities and their permissions. Both these classes are for use in a assembly used in a windows forms application.

The question is, when using the declarative PrincipalPermission attribute on top of my assembly classes, how to enforce that my custom IPrincipal and IIdentity classes are in use and not some other IPrincipal/IIdentity that might be Authenticated.

[PrincipalPermission(SecurityAction.Demand, Authenticated = true, Role = "limited")]
public class RequiresAuthentication
{ }

Answer 1

Security-aware code is split into two parts: the Identifying Party (IP), which authenticates users and generates IIdentity and IPrincipal objects, and the Relying Party (RP), which makes use of them.

In the RP, you don’t care where the IPrincipal came from, as long as it’s valid.

You control where the permissions come from by writing the IP yourself. That way, you ensure that you only ever generate your custom IIdentity and IPrincipal objects.

If you call someone else’s IP, you are by definition not caring what sort of IPrincipal is generated.

EDIT:

Having said that, however, there is the additional problem that a role called "limited" may be generated by several different IPs and mean different things to each one. The way to solve that problem is to use a claims-based principal rather than a role-based principal. A claim is not a simple string, but a generic data value that is digitally signed and identified by a namespace URI. That way, you still don’t care which IPrincipal is being given to you, but you can guarantee that the claim is the correct one even if its name clashes with some other claim from some other IP.

Have a look at the new Windows Identity Foundation (formerly called Geneva, formerly called Zermatt) for claims-based security.