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!

IsolatedStorageContainment Enumeration

Isolated storage uses evidence to specify a unique storage area for use by an application or component. Isolated storage provides true isolation in that the identity of an application uniquely determines the root of a virtual file system that only that application can access. Thus, rather than many applications and components sharing a common resource like the file system or registry, each has its own file area inherently assigned to it that is fully isolated from other applications making it essentially private.

Three basic kinds of identity are used in scoping isolated storage

User- authenticated user identity, or a unique "anonymous" user if none.

Domain- domain isolation is based on evidence associated with the application domain. Web application identity is derived from the site's URL (e.g.

[Visual Basic]
Public Enum IsolatedStorageContainment
[C#]
public enum IsolatedStorageContainment
[C++]
public enum IsolatedStorageContainment

[JScript] In JScript, you can use the enumerations in the NGWS frameworks, but you cannot define your own.

Members

Member Name Description
AdministerIsolatedStorageByUser Limited administration ability for the isolated storage data store. Allows browsing and deletion of entire user store, but not read access other than own domain/assembly identity.
AssemblyIsolationByUser Storage is isolated first by user and then by code assembly.

This provides a data store for the assembly that is accessible in any domain context. The per-assembly data compartment requires additional trust as it potentially provides a "tunnel" between applications that could compromise the data isolation of applications, in particular web sites. Typical usage would be for user data that applies across multiple applications- for example, license information, user's personal information (name, authentication credentials, etc.) that is independent of application.

DomainIsolationByUser Storage is isolated first by user and then by domain.

Typical use includes storing user parameters such as preferences of user data for use by a specific application. Data can only be accessed within the context of the same application and only when run by the same user. For example, an application might store user's identifying information, save the state from the last time the application was run, use the store to record an audit trail of past application usage, and save preferences for options of the application.

Also allows isolation by user, domain, and assembly.

This second usage is helpful when a third-party assembly wants to keep a private data store. The assembly is private in the sense that only code in that assembly may access the data, yet the data store is also scoped by the application it runs in so that the assembly does not represent a potential leak by exposing data to other applications. In particular, this addresses the web site isolation requirement of a web browser, where (without special trust) data of one site should never be leaked to another at the client. The scenario for this feature is similar to the above, with the third party code having its own container within the scope of the application in which it is being used.

None Use of isolated storage is not allowed.
UnrestrictedIsolatedStorage Use of isolated storage is allowed without restriction. Code has full access to any store of the user store, regardless of identity of the domain/assembly itself (includes ability to enumerate contents of the isolated storage data store).

Requirements

Namespace: System.Security.Permissions

Assembly: mscorlib.dll

See Also

System.Security.Permissions Namespace