Microsoft Technology Licensing, LLC

Microsoft Corporation

Zhigu Holdings Limited

Paul J Leach

Richard Bruce Ward

Peter Sewall Ford

Edward K Y Jung

Antony S Williams

Mark H Lucovsky

Craig Henry Wittenberg

Shaun Douglas Pierce

Holly Knight

Ye Gu

Daniel Ron Simon

Richard F Rashid

Butler W Lampson

Mark Fishel Novak

David Benson Cross

C Douglas Hodges

Srinivasa R Koppolu

Thomas C Jones

John E Brezak

Liqiang Zhu

Scott Field

Gregory Burns

Michael B Jones

Christopher G Kaler

Charles W Kaufman

John Peter Shewchuk

Stephen James Millet

Giovanni Moises Della-Libera

Bradford H Lovering

Praerit Garg

William Michael Zintel

Ravindra Pandya

Yi Zeng

Amar S Gandhi

Scott A Konersmann

Steven E Lucco

Balan Sethu Raman

Robert P Fitzgerald

Steven P Levi

Melissa Wood Dunn

Carl Melvin Ellison

George M Moore

Shyamalan Pather

Jeffrey C Schlimmer

Michael M Swift

Clifford P Van Dyke

Peter T Brundrett

Saurav Sinha

Jonathan D Pincus

Richard Powell Draves, Jr

Arthur Zwiegincew

Gopinathan Kannan

Josh D Benaloh

Robert George Atkinson

Cristian Marius Ilac

Tanmoy Dutta

Chris Weider

Arun K Nanda

Richard Douglas Hill

Murli D Satagopan

Alexander Thomas Weinert

Sameet Harishanker Agarwal

Pradyumna K Misra

Bhalchandra Pandit

Burra Gopal

Klaus U Schutz

Eric C Perlin

Vishal Agarwal

Shannon J Chan

Ferhan Elvanoglu

Lijiang Fang

Muthukrishnan Paramasivam

Samuel John George

Jay Christopher Jacobs

Jeffrey B Hamblin

Robert P Reichel

Jianrong Gu

Kenneth D Ray

Nir Nice

Chris J Guzak

William R Tipton

Costin Hagiu

John Eugene Neystadt

Sterling M Reasor

Anshul Rawat

Andrew M Herron

Jonathan D Schwartz

Arnold S Miller

Anil K Ruia

Roopesh C Battepati

Shaun David Cox

Eric R Flo

Daniel Oliver

John J Lambert

Kevin T Damour

John E Parsons

Krassimir Emilov Karamfilov

Anish Desai

Jonathan A Silvera

Keith R Vogel

This disclosure pertains generally to client authentication. One aspect of the disclosure relates to a first server for presenting evidence to a Domain Controller (DC) of a first authentication context being submitted from a client to the first server to obtain a delegable credential, wherein the credential can be used to request a second authentication context from that client to a second server. Another aspect relates to the first server providing a pass-thru with evidence to a DC. The evidence relates to a first authentication context being submitted from a client to the first server that it obtained a delegable credential. The pass-thru is used in combination with the credential to request a second authentication context from the client to a second server.

Pass-thru for client authentication

The subject disclosure pertains to systems and methods that facilitate managing access control utilizing certificates. The systems and methods described herein are directed to mapping an access policy as expressed in an access control list to a set of certificates. The set of certificates can be used to grant access to resources in the manner described by the ACL. The certificates can be distributed to entities for use in obtaining access to resources. Entities can present certificates to resources as evidence of their right to access the resources. The access logic of the sequential ACL can be transformed or mapped to a set of order independent certificates. In particular, each entry, position of the entry in the list and any preceding entries can be analyzed. The analysis can be used to generate order independent certificates that provide access in accordance with the access policy communicated in the ACL.

Transformation of sequential access control lists utilizing certificates

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 client can communicate with a middle tier, which can then, in turn, communicate with a back end tier to access information and resources on behalf of the client within the context of a system that can scale well. Each individual back end can establish a policy that defines which computing device can delegate to that back end. That policy can be enforced by a domain controller within the same administrative domain as the particular back end. When a middle tier requests to delegate to a back end, the domain controller to which that request was directed can either apply the policy, or, if the domain controller is in a different domain than the targeted back end, it can direct the middle tier to a domain controller in a different domain and can sign relevant information that the middle tier can utilize when communicating with that different domain controller.

Back-end constrained delegation model

A distributed system in which time-dependent credentials are supplied by controllers that operate according to different local times. Errors that might arise from the controllers generating inconsistent credentials because of time skew are avoided by identifying credentials generated during transition intervals in which different ones of the controllers may generate different credentials at the same absolute time. During a transition interval, controllers and other devices may use credentials differentially based on the nature of the authentication function. Each controller may periodically renew its credentials based on self-scheduled renewals or based on requests from other devices, such that renewal times are offset by random delays to avoid excessive network traffic. Controllers may determine which credential is valid for any given time, based on a cryptographically secure key associated with that time and information identifying the entity that is associated with that credential.

Distributed computer systems with time-dependent credentials

The method of delegating authentication, within a chain of entities, relies upon a recording of at least a portion of a TLS handshake between a gateway device and user, in which the user needs access to a desired server. The method then relies upon re-verification of cryptographic evidence in the recorded portion of the TLS handshake, which is forwarded either (1) to the server to which access is desired, in which case the server re-verifies the recorded portion to confirm authentication, or, (2) to a third party entity, in which case the third party entity confirms authentication and provides credentials to the gateway server which then uses the credentials to authenticate to the server as the user.

Authentication delegation based on re-verification of cryptographic evidence

Computer-executable instructions that are directed to the performance of consequential actions and automatically elevate to execute at a higher privilege level to do so can perform such consequential actions only after user notification. Doing so can enable monitoring processes to avoid presenting duplicative user notification upon detection of such auto-elevation. In addition, prior to presenting user notification, input from the execution environment can be ignored and access to DLLs for performing consequential actions can be avoided. A static analyzer can identify non-conforming computer-executable instructions. A wrapper can be utilized to provide compliance by otherwise unknown or non-conforming computer-executable instructions.

Unobtrusive assurance of authentic user intent

A scope hierarchy corresponding to a resource to which a type of access is requested is identified, the scope hierarchy including multiple scope levels each of which has an associated access control list. An access control list associated with a lower scope level can further restrict access permitted to the resource by an access control list associated with a higher scope level. Based at least in part on one or more of the access control lists associated with the multiple scope levels, a determination is made as to whether the requested type of access to the resource is permitted.

Resource access based on multiple scope levels

The reputation of an executable computer program is checked when a user input to a computing device initiates a program launch, thus triggering a check of a local cache of reputation information. If the local cache confirms that the program is safe, it is permitted to launch, typically without notifying the user that a reputation check has been made. If the local cache cannot confirm the safety of the program, a reputation check is made by accessing a reputation service in the cloud. If the reputation service identifies the program as safe, it returns an indication to the computing device and the program is permitted to be launched, again without notifying the user that a reputation check has been made. If the reputation service identifies the program as unsafe or potentially unsafe, or does not recognize it at all, a warning is displayed to the user.

Reputation checking of executable programs

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 file system is configured for use with files protected by digital rights management (DRM) content controls and to interact both with applications that are, and are not, DRM aware. The file system may be configured for use by two applications, in a manner that may provide the second application with protected files if the first application was previously allowed access. In one example, a user context cache of DRM-protected files is created. The files in the cache may have been decrypted in response to a request(s) from the first application. Subsequent requests from the second application may be received for files within the user context cache of DRM-protected files. At least one of the files within the user context cache of DRM-protected files may be provided to the second application if the second application has a joint user context with the first application.

File system operation and digital rights management (DRM)

PassThru for client authentication

Growing community of inventors

Seattle, WA, United States of America

Paul J Leach