|Publication number||US7774830 B2|
|Application number||US 11/080,806|
|Publication date||Aug 10, 2010|
|Filing date||Mar 14, 2005|
|Priority date||Mar 14, 2005|
|Also published as||US20060206931|
|Publication number||080806, 11080806, US 7774830 B2, US 7774830B2, US-B2-7774830, US7774830 B2, US7774830B2|
|Inventors||Blair Brewster Dillaway, John L. Manferdelli, Shawn Martin Woods|
|Original Assignee||Microsoft Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (5), Referenced by (44), Classifications (11), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates to an access management system whereby access to a resource such as digital content or a digital service is provided only in accordance with a corresponding grant of access as expressed in a digital security token accompanying the request. More particularly, the invention relates to such an access management system with an access control policy engine that can accept any of multiple received types of security tokens, containing requestor identity and attribute information and/or authorization information, and that can convert the information in the received token into a common format.
Access management is highly desirable in connection with granting access to a digital resource such as a digital service or digital content, which may include digital audio, digital video, digital text, digital data, digital multimedia, etc. The resource can be the aforementioned content or the like, a server or the like having a library of content or the like, or any other or digital repository of information that a user might wish to access such as for example an electronic mail server, a gaming server, a network access server or point, etc. Likewise, the resource can be a service, such as a printer, a compiler, a renderer, or the like.
Typically, in an access management context, a requestor is granted access to a resource upon presenting a request with a security token identifying the requestor where this identity information allows one to determine the rights the requestor has with respect to the resource based on local authorization policy, among other things. In other systems, the security token may include an authorization expression directly which determines the rights the requestor has with respect to the resource, among other things. For example, the security token may comprise a digital certificate issued to and identifying the requestor and the rights thereof. In any event, the security token is typically issued to the requestor by an issuer that is known to and trusted by the resource. For example, within the context of an organization, the resource may be a data server, and the issuer may be an identity server set up by an administrator to provide an identifying security token to each member of the organization. Note, though, that the issuer may also be an identity server external to the organization and acceptable to the resource.
Typically, the resource includes or is accessed by way of an access control policy engine or the like that initially receives the request with the security token and decides based on the security token and perhaps other information whether the requestor is entitled to access to the requested resource. Upon satisfying itself that the requestor is in fact so entitled, the access control policy engine forwards the request to the resource for response thereby. For example, if the request is for a data file from the resource, the resource provides such data file, and if the request is to review information available from the resource, the resource allows the requestor to in fact review such information.
Notably, in at least some instances the resource provides data to the requestor. If so, the resource may choose to encrypt the data according to a format that allows the requestor to decrypt same, but not others. For example, it may be that the presented security token of the requestor is a digital certificate that includes a public key associated therewith, and the resource encrypts the provided data according to the public key of the presented security token. Thus, the requestor may apply a corresponding private key associated with the digital certificate to the encrypted data to reveal same.
Also notably, the resource may choose to attach terms and conditions to the encrypted data that the requestor must abide by. If so, and again presuming that the presented security token of the requestor is a digital certificate that includes a public key associated therewith, the resource may encrypt the provided data according to a selected symmetric key, encrypt the symmetric key according to the public key of the presented security token, and place the encrypted symmetric key and the terms and conditions in a digital license. Thus, the requestor may apply the corresponding private key associated with the digital certificate to the encrypted symmetric key of the license to reveal same, and then apply the decrypted symmetric key to the encrypted data to reveal same, presuming of course that the terms and conditions in the license so allow.
The security token accompanying a request for access to a resource may take any of several forms, especially if the resource is being accessed by a diverse group of requestors. Thus, the security token as received by an access control policy engine for the resource may be any of several types, such as for example an X.509 certificate, a Kerberos ticket, an XML-based digital certificate, a SAML token, an ISO MPEG REL license, or the like. The security token may indeed be simply a username with a corresponding password.
At any rate, the access control policy engine (access control policy engine) for a resource should be able to handle any of a plurality of types of received security tokens and be able to process same. Of course, dealing with multiple types of security tokens adds complexity to the access control policy engine, especially if the access control policy engine does not operate based on account-based information but instead must judge whether to grant access in connection with a request based primarily on the content of the security token or tokens accompanying such request.
That is, with the continued evolution to a globally interconnected world and complex distributed applications, account-based access is not considered adequate. As may be appreciated, in such account-based access, a requestor would create an account with or available to the access control policy engine prior to issuing a request to same, and the access control policy engine in deciding whether to grant access based on a request would refer to such account. Instead of account-based access, then, an access control policy engine may need to grant access based on a request from a requestor with which the access control policy engine has no prior established relationship, relying only on the security token proffered with the request from such requestor and identifying same. Presumably, then, the security token includes therewith at least some information that the access control policy engine may employ in deciding whether to grant access based on the request on a variety of identifying information in making these decisions. To deal with these realities, a variety of security tokens types are now commonly in use. Notably, the aforementioned, X.509 certificate, the SAML token, and the ISO MPEG REL license are examples of security tokens that can be used when a requestor and the resource with the access control policy engine may not have a prior established relationship.
Unfortunately, each type of security token format evolved as an independent standard, designed to address specific types of problems and having a disparate encoding format, information carrying capabilities, and semantics. In addition, each type of security token was introduced into computing environments in an incremental fashion. Thus, rather than being able to deal with only a single type of security token, an access control policy engine must instead have an interface for manipulating each type of security token to expose and employ the information contained with such type of security token. As may be appreciated, then, adapting an access control policy engine to accept a new type of security token is costly and difficult. Alternatively, and perhaps worse, an access control policy engine must assume that requestors will be using a specific type of security token.
Of course, either situation creates difficulties in adapting to new business models, evolving to support new relationships between organizations and individuals, handling dynamic relationships, taking into account richer information about a requestor in making an access decision, and providing seamless scalability. For example, an access control policy engine originally designed assuming enterprise account-based security tokens cannot easily adapt to handle security tokens for requestors outside the enterprise. Similarly, an access control policy engine designed to use X.509 security tokens cannot easily move to support Kerberos, SAML or REL security tokens.
Existing approaches to addressing such problems have had limited success. The most common approach has been for the access control policy engine to force all security tokens to map to locally managed accounts, where the access control policy engine then makes each access control decision based solely on a corresponding local account. However, it is to be appreciated that it is costly for an access control policy engine to maintain local accounts for external entities, often with transient business relationships. Moreover, relying on local accounts means that any rich semantics or data encoded in a security token are lost in doing the translation to the corresponding local account. It also fails to provide support for evolving business needs in which an administrative entity determines the allowed access for a requestor and encodes that information directly into a security token which is presented to the access control policy engine. At any rate, forcing semantics not intended for accounts, such as mapping application or organization identify to a user account, creates semantics problems that can affect manageability.
Another approach has been for the access control policy engine to include multiple paths, each which handles a specific security token format. In such a situation, however, only a single type of security token can be handled per request and any unification across types is based on application specific logic. The net result is duplicative effort and lack of a common unification paradigm that supports common access control policies.
Accordingly, a need exists for a new type of access control policy engine that can control access to a resource based on any of multiple received types of security tokens, and without the need for local accounts or multiple paths. In particular, a need exists for such an access control policy engine that maps the information in each of one or more types of security token received with a request to a common access-decision format, and that then decided whether to grant access based on the commonly formatted access-decision information. Further, a need exists for such an access control policy engine that handles mapping each type of security token based on a corresponding mapping module, whereby the access control policy engine can accommodate a new type of security token based on a corresponding new mapping module.
The aforementioned needs are satisfied at least in part by the present invention in which a method is provided in connection with a requestor submitting a request to access a digital resource. The request includes at least one security token associated with the requestor, where each security token of the request contains access decision information useful for determining whether to allow the request, and where each security token has one of a plurality of types. In the method, an access control policy engine associated with the resource determines whether to allow the request. Such access control policy engine receives the request with each security token thereof, retrieves each security token from the request, and processes each retrieved security token by determining the type of such retrieved security token and mapping the access decision information in the retrieved security token to the common format as at least one security claim setting forth sufficient information for the access control policy engine to determine the rights of the requestor with respect to the desired resource.
Thus, the access control policy engine has a set of security claims relating to the request after having processed the retrieved tokens. Thereafter, the engine retrieves a set of rules for accessing the resource, applies the retrieved set of rules to the set of security claims to determine whether to allow the request from the requestor, and if the request from the requestor is to be allowed, provides the requestor access to the resource, via an associated resource manager, in accordance with the request and the attributes and rights of the requestor as set forth within the set of security claims.
The foregoing summary, as well as the following detailed description of the embodiments of the present invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings embodiments which are presently preferred. As should be understood, however, the invention is not limited to the precise arrangements and instrumentalities shown. In the drawings:
Although not required, the invention can be implemented via an application programming interface (API), for use by a developer, and/or included within the network browsing software which will be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers, such as client workstations, servers, or other devices. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations. Other well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers (PCs), automated teller machines, server computers, hand-held or laptop devices, multi-processor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. A graphics interface 182, such as Northbridge, may also be connected to the system bus 121. Northbridge is a chipset that communicates with the CPU, or host processing unit 120, and assumes responsibility for accelerated graphics port (AGP) communications. One or more graphics processing units (GPUs) 184 may communicate with graphics interface 182. In this regard, GPUs 184 generally include on-chip memory storage, such as register storage and GPUs 184 communicate with a video memory 186. GPUs 184, however, are but one example of a coprocessor and thus a variety of co-processing devices may be included in computer 110. A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190, which may in turn communicate with video memory 186. In addition to monitor 191, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195.
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
One of ordinary skill in the art can appreciate that a computer 110 or other client device can be deployed as part of a computer network. In this regard, the present invention pertains to any computer system having any number of memory or storage units, and any number of applications and processes occurring across any number of storage units or volumes. The present invention may apply to an environment with server computers and client computers deployed in a network environment, having remote or local storage. The present invention may also apply to a standalone computing device, having programming language functionality, interpretation and execution capabilities.
Distributed computing facilitates sharing of computer resources and services by direct exchange between computing devices and systems. These resources and services include the exchange of information, cache storage, and disk storage for files. Distributed computing takes advantage of network connectivity, allowing clients to leverage their collective power to benefit the entire enterprise. In this regard, a variety of devices may have applications, objects or resources that may interact to implicate authentication techniques of the present invention for trusted graphics pipeline(s).
It can also be appreciated that an object, such as 110 c, may be hosted on another computing device 10 or 110. Thus, although the physical environment depicted may show the connected devices as computers, such illustration is merely exemplary and the physical environment may alternatively be depicted or described comprising various digital devices such as PDAs, televisions, MP3 players, etc., software objects such as interfaces, COM objects and the like.
There are a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems may be connected together by wireline or wireless systems, by local networks or widely distributed networks. Currently, many of the networks are coupled to the Internet, which provides the infrastructure for widely distributed computing and encompasses many different networks.
In home networking environments, there are at least four disparate network transport media that may each support a unique protocol such as Power line, data (both wireless and wired), voice (e.g., telephone) and entertainment media. Most home control devices such as light switches and appliances may use power line for connectivity. Data Services may enter the home as broadband (e.g., either DSL or Cable modem) and are accessible within the home using either wireless (e.g., HomeRF or 802.11b) or wired (e.g., Home PNA, Cat 5, even power line) connectivity. Voice traffic may enter the home either as wired (e.g., Cat 3) or wireless (e.g., cell phones) and may be distributed within the home using Cat 3 wiring. Entertainment media may enter the home either through satellite or cable and is typically distributed in the home using coaxial cable. IEEE 1394 and DVI are also emerging as digital interconnects for clusters of media devices. All of these network environments and others that may emerge as protocol standards may be interconnected to form an intranet that may be connected to the outside world by way of the Internet. In short, a variety of disparate sources exist for the storage and transmission of data, and consequently, moving forward, computing devices will require ways of protecting content at all portions of the data processing pipeline.
The ‘Internet’ commonly refers to the collection of networks and gateways that utilize the TCP/IP suite of protocols, which are well-known in the art of computer networking. TCP/IP is an acronym for “Transport Control Protocol/Interface Program.” The Internet can be described as a system of geographically distributed remote computer networks interconnected by computers executing networking protocols that allow users to interact and share information over the networks. Because of such wide-spread information sharing, remote networks such as the Internet have thus far generally evolved into an open system for which developers can design software applications for performing specialized operations or services, essentially without restriction.
Thus, the network infrastructure enables a host of network topologies such as client/server, peer-to-peer, or hybrid architectures. The “client” is a member of a class or group that uses the services of another class or group to which it is not related. Thus, in computing, a client is a process, i.e., roughly a set of instructions or tasks, that requests a service provided by another program. The client process utilizes the requested service without having to “know” any working details about the other program or the service itself. In a client/server architecture, particularly a networked system, a client is usually a computer that accesses shared network resources provided by another computer e.g., a server. In the example of
A server is typically a remote computer system accessible over a remote network such as the Internet. The client process may be active in a first computer system, and the server process may be active in a second computer system, communicating with one another over a communications medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information-gathering capabilities of the server.
Client and server communicate with one another utilizing the functionality provided by a protocol layer. For example, Hypertext-Transfer Protocol (HTTP) is a common protocol that is used in conjunction with the World Wide Web (WWW). Typically, a computer network address such as a Universal Resource Locator (URL) or an Internet Protocol (IP) address is used to identify the server or client computers to each other. The network address can be referred to as a Universal Resource Locator address. For example, communication can be provided over a communications medium. In particular, the client and server may be coupled to one another via TCP/IP connections for high-capacity communication.
In a network environment in which the communications network/bus 14 is the Internet, for example, the servers 10 can be Web servers with which the clients 110 a, 110 b, 110 c, 110 d, 110 e, etc. communicate via any of a number of known protocols such as HTTP. Servers 10 may also serve as clients 110, as may be characteristic of a distributed computing environment. Communications may be wired or wireless, where appropriate. Client devices 110 may or may not communicate via communications network/bus 14, and may have independent communications associated therewith. For example, in the case of a TV or VCR, there may or may not be a networked aspect to the control thereof. Each client computer 110 and server computer 10 may be equipped with various application program modules or objects 135 and with connections or access to various types of storage elements or objects, across which files may be stored or to which portion(s) of files may be downloaded or migrated. Thus, the present invention can be utilized in a computer network environment having client computers 110 a, 110 b, etc. that can access and interact with a computer network/bus 14 and server computers 10 a, 10 b, etc. that may interact with client computers 110 a, 110 b, etc. and other devices 111 and databases 20.
Access Management Overview
As is known, and referring now to
As may be appreciated, the organization 10 may be any appropriate type of organization without departing from the spirit and scope of the present invention. For example, the organization 10 may be a public corporation, a private company, a governmental body, a non-profit charity, a research foundation, an on-line store, a public source of on-line information, a private source of information, a highly secure database, a low-security index, etc. As may also be appreciated, the requestor 12 interior to or exterior from the organization 10 may be any appropriate requestor, also without departing from the spirit and scope of the present invention. For example, the requestor 12 may be any employee, a director, a supervisor, an officer, a server, a computing device, etc.
Generally, the resource 14 receives requests for access to digital information or services by way of the access control policy engine 18 and the access control policy engine 18 provides such access according to pre-defined rules. Such digital information may include digital content or data or the like, and such digital services may include printing services, rendering services, data transformation services, or the like. Thus, such resource 14 and such digital information may be any appropriate digital resource and digital information without departing from the spirit and scope of the present invention.
The pre-defined rules that the access control policy engine 18 follows in providing access to a requestor 12 may be any rules without departing from the spirit and scope of the present invention. Within the context of the present invention, such rules at least implicitly require that the requestor 12 present the security token 16 to the access control policy engine 18 along with the request for access to the resource 12, and may also require that the requestor 12 have a minimum level of position if interior to the organization 10 or a minimum security level if exterior to the organization 10, as might also be set forth with the security token 16, that the requestor have the right to access the resource 14, as might be set forth within the security token 16, and the like. Such rules might for example also require that the request from the requestor 12 be received at a particular time of day, that the requestor 12 be requesting access to the resource 14 by way of a particular type of connection, etc.
The security token 16 as presented by and representing the requestor 12 maybe any appropriate security token without departing from the spirit and scope of the present invention. For example, the security token 16 may be a digital certificate as issued to the requestor 12 by an administrator 18 of the organization 10 that is trusted by the access control policy engine 18. Likewise, the security token 16 could be a Kerberos ticket or some other form of token such as a REL license or an XML-based token, or some other form of identifying indicia. Although not necessary for purposes of the present invention, it may be the case that the security token 16 includes information therein as is appropriate for identifying the requestor 12. For example, the digital certificate 16 may include the name of the requestor 12, the position of the requestor 12 if interior to the organization. At a minimum, though, the security token 16 should include some sort of information adequate to allow the access control policy engine to determine the rights of the requestor 12 with respect to accessing the resource 14. Such information may include identifying information for the requestor, attributes of the requestor, or an expression of the rights of the requestor for the resource as determined by some administrative authority. In at least some instances, the security token 16 is signed based on the contents thereof and according to a private key of a public-private key pair, and may be validated according to an attached chain of certificates including the corresponding public key.
The security token 16 may itself have an associated public-private key pair, with the public key in the certificate 16. Thus, the resource 14 may respond to a requestor 12 with data encrypted either directly or indirectly according to the public key of the certificate 16 of such requestor 12. Accordingly, the requestor 12 may access such data by appropriate application of the corresponding private key of the security token 16.
The access control policy engine 18 may be instantiated on a server or the like, and may be any appropriate access control policy engine that is trusted to make decisions on access to the resource 14 without departing from the spirit and scope of the present invention, presuming of course that the administrator 18 is capable of processing multiple types of security tokens 16 in the manner set forth herein. Presumably, the rules of the access control policy engine 18 require that any request from any requestor 12 be accompanied by a security token 16, and that the security token 16 satisfy some minimum set of criteria. Such criteria are known or should be apparent to the relevant public, and therefore need not be set forth herein in any detail. For example, the security token 16 itself should be valid and any validity period set forth therein should be current. Likewise, if the security token 16 specifies particular rights and conditions, such rights and conditions should be checked to determine that the rights allow the access sought and that the conditions are satisfied.
Controlling Access to Resource 14 Based on Mapped Security Token 16
In one embodiment of the present invention, in order for the access control policy engine 18 to accept any of multiple types of security token 18 from a requestor 12 in the course of such requestor 12 requesting access to a resource 14, the access control policy Engine 18 maps the access decision information in the security token 18 of the requestor 12 to a common format, and then applies the rules thereof in conjunction with a local access control policy to decide whether to grant access based on the commonly formatted access-decision information. The common format employed by the access control policy engine 18 is thus a uniform mechanism for handling a variety of types of security tokens 16, providing a semantically consistent representation of the information regardless of type and allowing access decisions to be made by the access control policy engine 18 in a manner independent of the security token 16. As a result, the rules employed by the access control policy engine 16 can be set forth in a generic manner that is inherently adaptable to almost any type of security token 16 that may be provided by a requestor 12.
Moreover, and also in one embodiment of the present invention, rather than including mapping procedures for every type of security token 16, such mapping procedures for each of at least some types of security tokens 16 are stored in a corresponding mapping module 20, as seen in
In one embodiment of the present invention, the common format employed by the access control policy engine 18 is characterized by including the following elements:
P a principal identifier that identifies the requestor 12, either as an individual or a member of some group, for example;
R a right possessed by P with respect to some target T (see below) and expressing the relationship between P and T, if T is an attribute or property of the requestor the right to ‘possess’ T is interpreted as asserting P has that attribute. If T is a resource known to the access control policy engine, then R may express the rights of P to operate on the resource 14, such as the right to ‘read’ a file, as determined by the security token issuing authority;
T a target identifier that identifies the target of a right, can refer to a property, an attribute, a device such as a resource 14, a data structure, etc.;
C any condition on the right R with respect to the target T that the access control policy engine 18 is to evaluate to true or false and can state any computation returning a Boolean value using any data available to the access control policy engine 18, such as for example a temporal constraint, a required revocation check, or the existence of other conditions; and
I an issuer identifier that identifies an entity that issued the security token 16 and is asserting the right R which the principal P has to the target T and the corresponding conditions C.
Together, P, R, T, C, and I allow most any type of security token 16 to be mapped by the access control policy engine 18 into the common format by way of a corresponding mapping module 20. Thus, the common format allows most any security token 16 to be viewed as encoding a collection of security claims. For each type of security token 16, a transform is defined that maps from the security token 16 encoding to a collection of security claims using a shared dictionary of P, R, T, C, and I types. The dictionary is finite but extensible and spans the set of assertions defined by standards relating to the types of security tokens 16 and interoperability profiles presently in use. By mapping to a security claims representation, the access control policy engine 18 is provided with a complete and uniform statement of the relevant information about the requestor 12 regardless of the type of security token 16 employed to represent same.
Following are examples of a number of types of security tokens 16 as mapped to security claims:
Kerberos Ticket—A Kerberos ticket has a symmetric key associated with the requestor 12 and a collection of security identifiers (SIDs) representing the domain account and groups of the requestor 12. The symmetric key may thus be viewed as P and the SID values as T possessed by P. The Kerberos Key Distribution Center (KDC) is the issuer I, and presuming the token has no relevant conditions, a number of security claims may be expressed based on the token in a (P, R, T, C, I) form as:
(keyHolder S1, possess, SID=“S-1-5-12 . . . ”, null, KDC)
(keyHolder S1, possess, SID=“S-1-7-34 . . . ”, null, KDC)
X.509 Certificate—An X.509 certificate has a public key value associated with a subject name and optional attributes such as an alternate subject name which could include an email address. The issuer is the holder of another public-private key pair. Again presuming the certificate has no relevant conditions, a number of security claims may be expressed based on the certificate in a (P, R, T, C, I) form as:
(keyHolder K1, possess, SubjectName=“CN=Bob O=MyOrg”, null, keyHolder K2)
(keyHolder K1, possess, eMailName=“firstname.lastname@example.org”, null, keyHolder K2)
MPEG REL License—An MPEG REL license is constructed according to an eXtensible Markup Language (XML) that defines the MPEG Rights Expression Language (REL) as approved by the International Organization for Standardization (ISO). As may be appreciated, an MPEG REL license can have grants of various rights for a principal or principals and is issued by some other principal holding cryptographic keys. Once again presuming the license has no relevant conditions, such license with two property grants and a capability grant could be expressed as security claims in a (P, R, T, C, I) form as:
(keyHolder K1, possess, Role=“administrator”, null, keyHolder K3)
(keyHolder K1, possess, eMailName=“email@example.com”, null, keyHolder K3)
(keyHolder K1, read/write, file=\\amachine\public\foo.txt, null, keyHolder K3)
Here, the types ‘keyHolder’, ‘Role’, ‘eMailName’, etc are defined in a shared dictionary, ensuring a semantically consistent expression of the information and allowing one to compare whether two principals, rights, resources, or conditions are the same. Access control policy (i.e., the rules employed by the access control policy engine 18) may thus be written in terms of the dictionary terms and therefore evaluate a given access request by evaluating the policy and requestor claims rather than the specific encoding of any given type of security token 16.
With the common format as set forth herein, then, and turning now to
At any rate, the request from the requestor 12 presumably includes some sort of security token 16 and may in fact include multiple security tokens 16, and the access control policy engine 16 thus for each security token 16 in the request retrieves same (step 403) and determines the type of such retrieved security token 16 (step 405). Determining the type of security token 16 may be performed in any appropriate manner without departing from the spirit and scope of the present invention. For example, it may be the case that the security token 16 includes a predefined type field, or it may be the case that the access control policy engine 18 includes a typer that is constructed to determine the type based on extant characteristics. If the latter, the typer may be provided with such extant characteristics for each type of security token 16 from a corresponding mapping module 20 associated with and available to the access control policy engine 18. In such a situation, then, a type of security token 16 is recognized by the access control policy engine 16 only if the corresponding mapping module 20 is available to the access control policy engine 16.
Based on the determined type of the retrieved security token 16, then, the access control policy engine 18 applies such retrieved security token 16 to the corresponding mapping module 20 to map the information in the retrieved security token 16 to the common format as one or more security claims (step 407), and stores each security claim in an appropriate location (step 409). Once all security tokens 16 from a request are processed, and as should be appreciated, the access control policy engine 18 should have a set of security claims relating to the request (step 411), and thus may retrieve a set of rules for accessing the resource 14 from an appropriate location (step 413) and apply the retrieved set of rules for accessing the resource 14 to such set of security claims (step 415).
Although the rules may be any appropriate rules without departing from the spirit and scope of the present invention and thus need not be set forth herein in any detail, it is to be appreciated that such rules should be written to take advantage of the common format of the security claims. Thus, upon applying the rules to the security claims as at step 415, the access control policy engine 18 may conclude with a determination based on such application regarding whether the request from the requestor 12 is to be honored (step 417).
If the request from the requestor 12 is to be honored as at step 417, the access control policy engine 18 provides access to the requestor 12 in accordance with the request and the rights of the requestor 12 as set forth within the security claims (step 419). Thus, it may be that the request is passed to the resource 14 and the resource 14 returns some sort of data to the requestor 12, or that the requestor is allowed to browse data stored at the resource 14, or that the requestor is allowed to employ the resource 14 to perform a service, for example.
If however the request from the requestor 12 is not to be honored as at step 417, the access control policy engine 18 may itself return some sort of notice of denial to the requestor 12, perhaps with an explanation if deemed advisable. Such explanation may for example suggest a different type of request, the need for a different type of security token 16, a reason why the request was denied, or the like.
It is to be appreciated that while the present disclosure speaks in terms of a resource 14 performing certain actions, it may in fact be the case that a resource manager is performing such actions on behalf of the resource 14. As may be appreciated, it is in fact oftentimes the case that a resource manager manages a resource 14 and enforces access control decisions for the resource 14. Nevertheless, unless otherwise necessary, a resource 14 performing an action can be considered the equivalent of a resource manager performing the action on behalf of the resource 14, and vice versa.
The programming necessary to effectuate the processes performed in connection with the present invention is relatively straight-forward and should be apparent to the relevant programming public. Accordingly, such programming is not attached hereto. Any particular programming, then, may be employed to effectuate the present invention without departing from the spirit and scope thereof.
In the present invention, a method and mechanism are provided by which an access control policy engine 18 can control access to a resource 14 based on any of multiple received types of security tokens 16, and without the need for local accounts or multiple policy evaluation paths. The access control policy engine 18 maps the information in each of one or more types of security token 16 received with a request to one or more security claims having a common access-decision format, and then decides whether to grant access based on all of the mapped security claims. The access control policy engine 18 maps each type of security token 16 based on a corresponding mapping module 20, whereby the access control policy engine 18 can accommodate a new type of security token 16 based on a corresponding new mapping module 20.
It should be appreciated that changes could be made to the embodiments described above without departing from the inventive concepts thereof. It should be understood, therefore, that this invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6675296 *||Jun 28, 1999||Jan 6, 2004||Entrust Technologies Limited||Information certificate format converter apparatus and method|
|US7313692 *||May 21, 2001||Dec 25, 2007||Intertrust Technologies Corp.||Trust management systems and methods|
|US20040148514 *||Nov 10, 2003||Jul 29, 2004||Fee Gregory D||Evidence-based application security|
|US20060195690 *||Feb 28, 2005||Aug 31, 2006||Microsoft Corporation||Extendable data-driven system and method for issuing certificates|
|US20060206707 *||Mar 11, 2005||Sep 14, 2006||Microsoft Corporation||Format-agnostic system and method for issuing certificates|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7882547 *||Dec 12, 2005||Feb 1, 2011||Microsoft Corporation||Securely calling web services from macros|
|US8539558 *||Aug 15, 2011||Sep 17, 2013||Bank Of America Corporation||Method and apparatus for token-based token termination|
|US8572686 *||May 24, 2012||Oct 29, 2013||Bank Of America Corporation||Method and apparatus for object transaction session validation|
|US8572687||May 24, 2012||Oct 29, 2013||Bank Of America Corporation||Apparatus and method for performing session validation|
|US8572688||May 24, 2012||Oct 29, 2013||Bank Of America Corporation||Method and apparatus for session validation to access third party resources|
|US8572689 *||May 24, 2012||Oct 29, 2013||Bank Of America Corporation||Apparatus and method for making access decision using exceptions|
|US8572690 *||May 24, 2012||Oct 29, 2013||Bank Of America Corporation||Apparatus and method for performing session validation to access confidential resources|
|US8572714||May 24, 2012||Oct 29, 2013||Bank Of America Corporation||Apparatus and method for determining subject assurance level|
|US8572724||May 24, 2012||Oct 29, 2013||Bank Of America Corporation||Method and apparatus for network session validation|
|US8584201 *||May 24, 2012||Nov 12, 2013||Bank Of America Corporation||Method and apparatus for session validation to access from uncontrolled devices|
|US8584202 *||May 24, 2012||Nov 12, 2013||Bank Of America Corporation||Apparatus and method for determining environment integrity levels|
|US8601541 *||May 24, 2012||Dec 3, 2013||Bank Of America Corporation||Method and apparatus for session validation to access mainframe resources|
|US8621557 *||Feb 12, 2010||Dec 31, 2013||Nec Corporation||Information processing system judging whether manipulation is possible or not based on access control policy and method of operation thereof|
|US8632003||Jan 27, 2009||Jan 21, 2014||Novell, Inc.||Multiple persona information cards|
|US8689004 *||Dec 15, 2010||Apr 1, 2014||Microsoft Corporation||Pluggable claim providers|
|US8726339||May 24, 2012||May 13, 2014||Bank Of America Corporation||Method and apparatus for emergency session validation|
|US8726340||May 24, 2012||May 13, 2014||Bank Of America Corporation||Apparatus and method for expert decisioning|
|US8726341||May 24, 2012||May 13, 2014||Bank Of America Corporation||Apparatus and method for determining resource trust levels|
|US8752124||May 24, 2012||Jun 10, 2014||Bank Of America Corporation||Apparatus and method for performing real-time authentication using subject token combinations|
|US8752157||May 24, 2012||Jun 10, 2014||Bank Of America Corporation||Method and apparatus for third party session validation|
|US8789143||Aug 15, 2011||Jul 22, 2014||Bank Of America Corporation||Method and apparatus for token-based conditioning|
|US8789162||Aug 15, 2011||Jul 22, 2014||Bank Of America Corporation||Method and apparatus for making token-based access decisions|
|US8806602||May 24, 2012||Aug 12, 2014||Bank Of America Corporation||Apparatus and method for performing end-to-end encryption|
|US8850515||May 24, 2012||Sep 30, 2014||Bank Of America Corporation||Method and apparatus for subject recognition session validation|
|US8950002||Aug 15, 2011||Feb 3, 2015||Bank Of America Corporation||Method and apparatus for token-based access of related resources|
|US8990896||Jun 24, 2008||Mar 24, 2015||Microsoft Technology Licensing, Llc||Extensible mechanism for securing objects using claims|
|US9159065||May 24, 2012||Oct 13, 2015||Bank Of America Corporation||Method and apparatus for object security session validation|
|US9396343||Oct 20, 2014||Jul 19, 2016||International Business Machines Corporation||Policy access control lists attached to resources|
|US9521167||Jan 20, 2015||Dec 13, 2016||Cisco Technology, Inc.||Generalized security policy user interface|
|US9531757||Jan 20, 2015||Dec 27, 2016||Cisco Technology, Inc.||Management of security policies across multiple security products|
|US9571524||Jan 20, 2015||Feb 14, 2017||Cisco Technology, Inc.||Creation of security policy templates and security policies based on the templates|
|US20070150741 *||Dec 12, 2005||Jun 28, 2007||Microsoft Corporation||Securely calling Web services from macros|
|US20090077627 *||Nov 25, 2008||Mar 19, 2009||Novell, Inc.||Information card federation point tracking and management|
|US20090320103 *||Jun 24, 2008||Dec 24, 2009||Microsoft Corporation||Extensible mechanism for securing objects using claims|
|US20110321121 *||Feb 12, 2010||Dec 29, 2011||Nec Corporation||Information processing system and operation method of information processing system|
|US20120084244 *||Sep 30, 2010||Apr 5, 2012||Microsoft Corporation||Claims issuance rule generation pipeline|
|US20120117609 *||Dec 15, 2010||May 10, 2012||Microsoft Corporation||Pluggable Claim Providers|
|US20130046696 *||May 24, 2012||Feb 21, 2013||Bank Of America Corporation||Method and Apparatus for Object Transaction Session Validation|
|US20130047205 *||May 24, 2012||Feb 21, 2013||Bank Of America Corporation||Apparatus and Method for Making Access Decision Using Exceptions|
|US20130047206 *||May 24, 2012||Feb 21, 2013||Bank Of America Corporation||Method and Apparatus for Session Validation to Access from Uncontrolled Devices|
|US20130047207 *||May 24, 2012||Feb 21, 2013||Bank Of America Corporation||Method and apparatus for session validation to access mainframe resources|
|US20130047213 *||Aug 15, 2011||Feb 21, 2013||Bank Of America Corporation||Method And Apparatus For Token-Based Token Termination|
|US20130047245 *||May 24, 2012||Feb 21, 2013||Bank Of America Corporation||Apparatus and Method for Performing Session Validation to Access Confidential Resources|
|US20130047246 *||May 24, 2012||Feb 21, 2013||Bank Of America Corporation||Apparatus and method for determining environment integrity levels|
|U.S. Classification||726/9, 713/172, 713/175, 726/28|
|Cooperative Classification||H04L63/0823, G06F21/6218, H04L63/102|
|European Classification||G06F21/62B, H04L63/08C, H04L63/10B|
|Jan 17, 2006||AS||Assignment|
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DILLAWAY, BLAIR BREWSTER;MANFERDELLI, JOHN L.;WOODS, SHAWN MARTIN;REEL/FRAME:017024/0236;SIGNING DATES FROM 20050304 TO 20050313
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DILLAWAY, BLAIR BREWSTER;MANFERDELLI, JOHN L.;WOODS, SHAWN MARTIN;SIGNING DATES FROM 20050304 TO 20050313;REEL/FRAME:017024/0236
|Jan 28, 2014||FPAY||Fee payment|
Year of fee payment: 4
|Dec 9, 2014||AS||Assignment|
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034543/0001
Effective date: 20141014