Microsoft Technology Licensing, LLC

David McPherson

Paul J Leach

Mark Fishel Novak

Arun K Nanda

Vishal Agarwal

Nir Ben Zvi

Pranav Kukreja

Ming Tang

Ramaswamy Ranganathan

Andrey Popov

Tanmoy Dutta

Liqiang Zhu

Kevin T Damour

Jignesh Shah

Sunil P Gottumukkala

Karanbir Singh

Resource authorization policies and resource scopes may be defined separately, thereby decoupling a set of authorization rules from the scope of resources to which those rules apply. In one example, a resource includes anything that can be used in a computing environment (e.g., a file, a device, etc.). A scope describes a set of resources (e.g., all files in folder X, all files labeled 'Y', etc.). Policies describe what can be done with a resource (e.g., 'read-only,' &#x201c;read/write,&#x201d; &#x201c;delete, if requestor is a member of the admin group,&#x201d; etc.). When scopes and policies have been defined, they may be linked, thereby indicating that the policy applies to any resource within the scope. When a request for the resource is made, the request is evaluated against all policies associated with scopes that contain the resource. If the conditions specified in the policies apply, then the request may be granted.

Scoped resource authorization policies

A policy that governs access to a resource may be tested against real-world access requests before being used to control access to the resource. In one example, access to a resource is governed by a policy, referred to as an effective policy. When the policy is to be modified or replaced, the modification or replacement may become a test policy. When a request is made to access the resource, the request may be evaluated under both the effective policy and the test policy. Whether access is granted is determined under the effective policy, but the decision that would be made under the test policy is noted, and may be logged. If the test policy is determined to behave acceptably when confronted with real-world access requests, then the current effective policy may be replaced with the test policy.

Testing access policies

A context of a principal is built, at a target system controlling access to a resource, independently of the principal requesting access to the resource. An authorization policy is applied, at the target system, to the context to determine whether the principal is permitted to access the resource, and an indication of whether the principal is permitted to access the resource is provided (e.g., to an administrator). Modifications can be made to the context and the authorization re-applied to determine whether a principal having the modified context is permitted to access the resource.

Target-based access check independent of access request

Modern network communications often require a client application requesting data to authenticate itself to an application providing the data. Such authentication requests can be redundant, especially in the case of stateless network protocols. When a full authentication is performed, a conversation identifier and one or more encryption keys can be agreed upon. Subsequent authentication requests can be answered with a fast reconnect token comprising the conversation identifier and a cryptographically signed version of it using the one or more encryption keys. Should additional security be desirable, a sequence number can be established and incremented in a pre-determined or a random manner to enable detection of replayed fast reconnect tokens. If the recipient can verify the fast reconnect token, the provider can be considered to have been authenticated based on the prior authentication. If an aspect of the fast re-authentication should fail, recourse can be had to the original full authentication process.

Fast-reconnection of negotiable authentication network clients

Growing community of inventors

Bothell, WA, United States of America

David McPherson