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!

Mapping from identity

The scope of an isolated storage data compartment is derived from the application domain identity, the code identity, and the mode of containment prescribed by the code. This mode of containment is the key to how the identities are combined, and deserves detailed description.

Data compartments are determined by identity, and the store that can be used for data is what constitutes the compartment. Data isolation is always per-machine, and can also be a combination of per-user, per-domain, per-publisher, per-strong-name (although not all possible mixes of these are supported). The value IsolatedStorageScope defines these isolation factors, and Boolean OR values represent combinations. Each valid combination is separately described below.

enum IsolatedStorageScope {
      User=1,
      Domain=2,
      Assembly=4,
      };

Access to an IsolatedStorage object via the constructors as described below constitutes “use of the store” for purposes of expiration accounting.

Mode: user + domain + assembly

Within an domain scope, signed assemblies can have their own isolated stores. First off, this gives assemblies a unique place to store data without having to worry about conflicting storage locations with other code. For third parties, the assembly has a separate store that is not accessible to other application code – ensuring clean software engineering isolation so that other code can’t conflict, plus a certain degree of privacy (see general discussion on limitations).

Note that signed assemblies by virtue of being included in the application domain can use the general domain scoped store as well. Assemblies may have some isolation from the rest of the application, but no “protection” in the other direction is possible.

The constructor API for the IsolatedStorage object based on assembly digitally signed identity within an domain, scoped per-user is as follows.

store = IsolatedStorageFile.GetUserStoreForDomain ();

The form above uses the public key identity of the signed code invoking the constructor. Only the code identity of the immediate caller is relevant. If the code is not signed (or signature is not valid) an ArgumentException results. (We could make it work like User|App but if code expects a signature identity we need to let it know.)

Successfully constructed object represents that assembly’s store – per domain – within which it can store its own data. Permission required to use this form of isolated storage is DomainIsolationByUser (or greater).

Mode: user + assembly

Independent of domain scope, signed assemblies can have their own isolated stores. This store allows code to access the same storage from any number of domains, and as such carries an increased security requirement for use.

The constructor API for the IsolatedStorage object based on assembly digitally signed identity only, scoped per-user is as follows.

store = IsolatedStorageFile.GetUserStoreForAssembly();

The form above uses the public key identity of the signed code invoking the constructor. Only the code identity of the immediate caller is relevant.

Successfully constructed object represents that assembly’s store – usable in any domain – within which it can store its own data. Permission required to use this form of isolated storage is AssemblyIsolationByUser (or greater).