NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Encapsulating Identity Information

In order to support application identity/role checks we need a way to expose this information to managed code. This requires there be managed objects representing this information. We use two concepts—Principal and Identity—when considering this information. A Principal represents the security context (role membership) under which the code is running while an Identity represents the identity of the user associated with that security context.

The IPrincipal Interface defines a property for accessing an associated Identity object and a method for checking whether the entity identified by the Identity object is a member of a given role. A Principal object is required to implement the IPrincipal Interface. The Principal object definer may implement additional properties or methods as desired.

The Identity of the principal is exposed via an Identity object, which implements the IIdentity Interface. This IIdentity interface defines properties for accessing a name and a “type”. Where the type information indicates the Authentication mechanism used to generate the identity information (i.e., NTLM, Kerberos V5, Basic Auth, ….).

The definer of an Identity object may implement additional properties or methods beyond those in IIdentity as desired. An example is the WindowsIdentity object that provides identity information based on a Windows NT token with methods to allow the impersonation/revert operations possible under NT.

In general, one will require authentication Credentials in order to determine the correct identity to use. Examples of Credentials include:

The appropriate Credentials will depend on the type of authentication supported in a given application environment. It should be noted that to avoid a potential security vulnerability, the Credential information is not stored as part of an Identity object.

As should be clear from the above discussion, there will always be an Identity object associated with any valid Principal object. Throughout the remainder of this document, references to a Principal object implies there is an Identity object accessible via the Principal.Identity property.

Relationship to an OS Account Token

The NGWS runtime makes no assumption about the relationship between an Identity object and the OS account on whose behalf a given process is running (i.e., process token). This is done to support scaling to heterogeneous environments and Internet distributed services in which no centrally administered trust environment is present.

It is possible the Identity object will reflect the same OS account as that associated with the process token. In practice, this means there is a WindowsIdentity object that maps to the NT process token. This is determined by the application being run and its associated authentication services.