Abstract: An evidence-based policy manager generates a permission grant set for a code assembly received from a resource location. The policy manager executes in a computer system (e.g., a Web client or server) in combination with the verification module and class loader of the run-time environment. The permission grant set generated for a code assembly is applied in the run-time call stack to help the system determine whether a given system operation by the code assembly is authorized. The policy manager may determine a subset of the permission grant set based on a subset of the received code assembly's evidence, in order to expedite processing of the code assembly. When the evidence subset does not yield the desired permission subset, the policy manager may then perform an evaluation of all evidence received.

Abstract: Access to a resource by sandboxed code is dynamically authorized by a client security system based on a resource based policy. A sandboxed application running on a client is granted access to a resource based on a resource based policy despite denial of the access based on a static policy associated with the client security system. The granting of access coincides with the determination that the threat to a user or the user's information is not increased should the access be granted.

Abstract: The present application describes a framework for a process oriented message driven workflow programming model where a complex process can be modeled by breaking down the complex process into a coarse grained series of atomic processes that interact through messages. A process is represented as a data structure that includes typed properties and one or more actions. The typed properties are used to associate a process with an incoming message, and the actions are steps that are executed when certain conditions are met by message properties and process data structure properties. A process action may add one or more properties to the process and/or modify an existing property. Processes are invoked and communicate solely through messages. When a process is executed, results of the execution are communicated to one or more other processes or external applications with messages that include any new and/or modified properties.

Abstract: In a matching system one or more related techniques use correlators to match entities and to look up metadata. Correlators are names that enable the matching system to associate entities with other entities. Attributes comprised of name/value pairs are used by the matching system to determine if two entities match. When two entities match, a process associated with an entity may be executed using the data associated with one or both of the matching entities. If the matching system is unable to determine a best match, all matching entities are provided to another process or human for further review. The matching system provides for the injection of new entities or correlators, to dynamically change the behavior of the system. Entities can be defined using a hierarchy, so that some of the entity properties are defined through an inheritance relationship with parent entities.

Abstract: A security policy manager generates a permission grant set for a code assembly received from a resource location. The policy manager can execute in a computer system (e.g., a Web client) in combination with the verification module and class loader of the run-time environment. The permission grant set generated for a code assembly is applied in the run-time call stack to help the system determine whether a given system operation by the code assembly is authorized. A permission request set may also be received in association with the code assembly. The permission request set may include a minimum request set, specifying permissions required by the code assembly to run properly. The permission request set may also include an optional request set, specifying permissions requested by the code assembly to provide an alternative level of functionality. In addition, the permission request set may include a refuse request set, specifying permissions that are not to be granted to the code assembly.

Abstract: A system and method that allows developers to debug a component while it is restricted by any arbitrary set of specific permissions, or restricted by an existing permission set associated with a security “zone.” A security sandbox is mimicked within the development environment so that developers can study how applications perform inside the sandbox. Developers are able create any sandbox and debug inside it, where violating any bound of the artificial sandbox will throw a security exception and drop the user out on the exact line of code which generated the error, as well as provide helpful information about how to correct the error.

Abstract: A security policy manager generates a permission grant set for a code assembly received from a resource location. The policy manager can execute in a computer system (e.g., a Web client) in combination with the verification module and class loader of the run-time environment. The permission grant set generated for a code assembly is applied in the run-time call stack to help the system determine whether a given system operation by the code assembly is authorized. A permission request set may also be received in association with the code assembly. The permission request set may include a minimum request set, specifying permissions required by the code assembly to run properly. The permission request set may also include an optional request set, specifying permissions requested by the code assembly to provide an alternative level of functionality. In addition, the permission request set may include a refuse request set, specifying permissions that are not to be granted to the code assembly.

Abstract: An application program interface (API) provides a set of functions, including a set of base classes and types that are used in substantially all applications accessing the API, for application developers who build Web applications on Microsoft Corporation's .NET™ platform.

Abstract: All execution paths of one or more assemblies in managed code are simulated to find the permissions for each execution path. The managed code can correspond to a managed shared library or a managed application. Each call in each execution path has a corresponding permissions set. When the library or application has permissions to execute that are not less than the required permission sets for the execution paths, any dynamic execution of the library or application will not trigger a security exception The simulated execution provides a tool that can be used to ensure that code being written will not exceed a maximum security permission for the code. A permission set can be determined by the tool for each assembly corresponding to an application and for each entry point corresponding to a shared library.

Abstract: A host intercepts calls between two executables and determines whether the calls are permissible according to the host's security model which can be identify based, such as user identity based—for instance, mapping access rights within a specific data base user context to database object access. Such an identity security model differs from a common language runtime security model where managed code uses Code Access Security to prevent managed assemblies from performing certain operations. Managed assemblies registered with the host are host objects from the host's perspective for which access rights can be defined via security rules, such as are defined for individual user identities. A host can decide access between managed executables based on the host's identity based access rules by trapping any cross assembly calls and deciding whether such calls should proceed or be blocked from taking place based on the corresponding identity security settings.

Abstract: A host operating in a managed environment intercepts a call from a managed caller to a particular callee and determines whether the call is permissible according to the host's prior configuration of a plurality of callees. The particular callee, which provides access to a resource that the host can be protecting, can have been previously configured by the host to always allow the call to be made, to never allow the call to be made, or to allow the call to be made based upon the degree to which the host trusts the managed caller.