What is really a Principal in .NET?

Question

When talking about identity in .NET we have the idea of Principal. There's the interface IPrincipal and together with it the implementation ClaimsPrincipal. We can even access one instance of an implementation of that interface any time using Thread.CurrentPrincipal.

Now, I never understood what this principal really is. Indeed, at first I thought it was something representing the identity of the current user. But it's not, in fact there's another interface IIdentity together with implementation ClaimsIdentity for that. Searching a little I found the following on MSDN:

A principal object represents the security context of the user on whose behalf the code is running, including that user's identity (IIdentity) and any roles to which they belong.

But what this security context of the user on whose behalf the code is running really means? I think I didn't get yet what this is supposed to represent.

Answer 1

When authorizing access to a resource or the ability to run some code, it is not sufficient merely to know which user is authorizing the action, but under what role they are authorizing it.

Think of this as being roughly equivalent to when you elevate a shell: the shell is now running under a different principal (with more privileges), even though the identity of the principal is still the same (your user account).

The IIdentity type is focused around issues of authentication, i.e. establishing that an identity known to the system actually belongs to an agent that wants to act under that identity. This is a necessary prerequisite for authorizing anything, but is not the whole story.

Answer 2

A principal is an abstract thing that encapsulates an identity and a role, and thus it's the security context under which the code is running. This can be a Windows identity (i.e. a Windows or Active Directory user account) and a Windows "role", a.k.a. "group", or it can be an identity/role that is independent of Windows users and roles but is still available across multiple applications. Thirdly, it can also be a custom notion of an identity and role that is defined solely within your application.

The security context is not a static thing; it can be changed by adjusting the principal's role and therefore affording greater or fewer privileges to the identity (user) and the application running under the security context.

Here is a good place to start for learning more about this: https://msdn.microsoft.com/en-us/library/z164t8hs.aspx