Source: https://patents.google.com/patent/US9038168B2/en
Timestamp: 2018-06-20 10:22:22
Document Index: 541180489

Matched Legal Cases: ['Application No. 201080052356', 'Application No. 201080052356', 'Application No. 10831970', 'Application No. 2012', 'Application No. 201080052356', 'Application No. 201080052356']

US9038168B2 - Controlling resource access based on resource properties - Google Patents
Controlling resource access based on resource properties Download PDF
US9038168B2
US9038168B2 US12622441 US62244109A US9038168B2 US 9038168 B2 US9038168 B2 US 9038168B2 US 12622441 US12622441 US 12622441 US 62244109 A US62244109 A US 62244109A US 9038168 B2 US9038168 B2 US 9038168B2
US12622441
US20110126281A1 (en )
In a typical enterprise environment, the amount of data that is maintained and processed is enormous and rapidly increasing. Information technology (IT) departments to have to deal with many millions or even billions of files, in dozens of formats. Moreover, the existing number tends to grow at a significant (e.g., double-digit yearly growth) rate.
With such data size and growth, a number of complex scenarios need to be considered by IT departments, including with respect to compliance, security, and storage. These scenarios are relevant for unstructured data (e.g., files), semi-structured data (e.g., files with property repositories) and structured data (e.g., databases). Often these data are not actively managed, and are kept in unstructured form in file shares.
To manage access to resources (objects) such as files, present security models are based on having access control policies on the objects that allow legitimate users to have access while restricting the access of unauthorized users. However, in addition to securing access based on business policy via an access control list (ACL) on the resource containing the data, enterprises also are looking to secure data based on content sensitivity.
By way of example, consider a file with a security policy that grants read access to several hundred users in a security group. If at some time the file contents are inadvertently updated such that the file exposes customer record data, a company may no longer want to provide such access to the entire security group. However there is no automatic mechanism for detecting the content change and then revising the security policy.
Changed content in a file may have other implications on how a company would like data to be handled. For example, a company may want a change in content that adds sensitive data to alter how the data may be distributed, such as to prevent a file containing the data from being attached in an email, or copied onto a portable storage device (e.g., a USB device) in clear text.
Preventing access and/or distribution as a result of changed content is not possible with existing security models. This results in unintended information leakage and insider breach of data, and is a significant issue facing a number of enterprises and the like, including in regulated industries and in the public sector.
Briefly, various aspects of the subject matter described herein are directed towards a technology by which access to a resource is determined based on policy for evaluating a resource label associated with the resource against a user claim associated with an access request to that resource. In one implementation, the policy is decoupled from the resource, and maintained separately/independently from the resource, providing a way to apply the same policy to multiple resources.
The resource may be a file, and the resource label may be obtained by classifying the file into classification properties. In this manner, for example, a content change to the file leads to a reclassification which may change its resource label, thereby changing which users have access to the file according to their respective user claim or claims.
The access may be determined from policy, which may specify access based solely on the resource label versus user claim evaluation, or in combination with one or more other evaluation results. For example, an access control list versus user token evaluation may further be used in determining whether to grant or deny access. Thus, for example, policy may specify that a user be both a member of a user group (ACL-based evaluation) and have a sufficient clearance level versus a resource sensitivity level (resource label-based evaluation) to obtain access. In another example, policy may specify that a user either be a member of a user group (ACL-based evaluation) or be identified as a member of a certain project (resource label-based evaluation) to obtain access.
FIG. 1 is a block diagram representing example components in a computing environment for controlling resource access based on resource labels versus user claims.
FIG. 2 is a flow diagram representing steps that may be taken by a security authority in granting access to a resource.
Various aspects of the technology described herein are generally directed towards applying an access policy to a resource based on a classification property set (one or more classification properties) that is obtained by classifying the resource. This is based upon obtaining at least part of the classification property set by processing the resource's current content.
A classification property associated with a resource that is used for determining access to the resource is referred to as resource label. As described below, an entity requesting access to the resource provides one or more user claims that are evaluated against the resource label (or labels) to determine whether to grant or deny an access-related operation. Thus, for example, if a file's contents change, that file is reclassified whereby its resource may label change, thereby preventing access to users that do not have the appropriate user claim or claims for that changed resource label. As a more particular example, if a file is changed such that it now contains sensitive data, the file is reclassified producing a modified resource label that prevents access to those users who do not have a user claim allowing them access to such sensitive data.
It should be understood that any of the examples herein are non-limiting. Indeed, for purposes of explanation, access to resources in the form of files is generally described herein, however a file is only one type of resource; other resources may include any set of data such as parts of files, database rows and/or columns and the like, as well as physical entities such as computers and peripherals, and/or virtual entities such as application roles. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing and resource access in general.
FIG. 1 shows an example computing environment in which a resource 102, presently associated with an access control list (ACL) 104, is classified by a classifier 106 to obtain a classification property set including at least one resource label 108. Note that classification may result in obtaining a property set comprising many classification properties that are associated with the resource, and the property set may include more than one resource label, however for purposes of brevity/explanation only one resource label is shown in FIG. 1. For a file resource, the resource and ACL are maintained in a storage 110, which also may be used to cache the classification properties including the resource label 108.
Classification, which may include processing content of a data item, is further described in U.S. patent application Ser. No. 12/427,755, hereby incorporated by reference. This technology is implemented in Microsoft Corporation's Windows® Server 2008 R2 as the File Classification Infrastructure (FCI) for defining and assigning classification properties to files and specifying actions to apply to files on file servers based on these properties, and is available as part of the file server resource manager (FSRM) server role.
The resource label 108 is associated with the resource in some way, such as by a declarative classification rule that automatically assigns resource labels to documents according to some rules, by a reference pointer to a cache of classification properties, and/or by storing the resource label in an alternate data stream of a file resource, as described in U.S. patent application Ser. No. 12/605,451, entitled “Alternate Data Stream Cache for File Classification” hereby incorporated by reference. Note that resource labels may be inferred from classification rules, and are not necessarily stored,
In general, the resource label 108 contains information that can be used in conjunction with user claims to apply policy. However, the cached resource label may be out-of-date or otherwise invalid. For example, there are a number of ways in which a cached resource label may be out-of-date, including if the file is modified or moved (thereby making the properties out-of-date); this thus includes content changes, and/or if the file is renamed or moved to another location within the file system (which may result in a classification change based on the new location). Another way a cached resource label becomes invalid is if the classification rules (described in the aforementioned U.S. patent application Ser. No. 12/427,755) used in the previous classification have since been modified, and/or if the internal state or configuration of modules that determine classification is modified. For example, even if the classification rules are unchanged, the ordering and/or way of combining two or more classification rules may change, and any such state change may result in a different file property classification result and thereby an invalid cached resource label.
Thus, before evaluating the resource label against the user claims, the cache resource label's validity and up-to-date- state is checked to determine whether reclassification is needed. If so, reclassification is performed, as described in the aforementioned U.S. patent applications. Note that part or all of the cached property set may be checked for validity and/or part or all of the resource reclassified to update the cached property set.
Turning to the application of policy by a resource label-aware security model, when an access request 112 for the resource 102 is received by a security authorization engine 114 (e.g., built into an operating system), the authorization engine 114 processes the request to see whether the access-related operation identified in the access request 112 is allowed. In one implementation, the access request 112 is associated with a conventional access token 116 that, depending on the policy or policies 118, may be evaluated against the resource's ACL 104.
As is known, conventional ACL-based security compares a resource's ACL against the token 116. However, ACL-based policy is basically static, and does not change according to the contents (e.g., the sensitivity of data) in the document. It is possible to have an external agent watch for content changes and appropriately change the ACL, however, this is impractical as it involves significant management complexity; e.g., such an agent has to watch and possibly change the policy for hundreds/thousands of files in case of any policy changes.
In contrast, as described herein, a resource label 108 versus user claims 120 evaluation provides a separation between the state of the document (e.g., its sensitivity, the project to which the file belongs, and so forth) and the policy 118 handling these labels. A policy change can be made centrally while maintaining the labels on the file.
Thus, as described herein, depending on the policy (or policies) 118, the user claims 120 may be evaluated against the resource label 108, which is based upon a current state of the resource, to determine whether the access-related operation is allowed. As represented in FIG. 1, a policy evaluation mechanism 122 (exemplified below with reference to FIG. 2) of the authorization engine 114 performs the security check, which may include evaluating the ACL 104 and/or the resource label 108 against the access token 116 including the user claims 120. The policy evaluation mechanism 122 grants or denies access in this example.
Shown for completeness in FIG. 1 is a policy combiner 124. In general, there may be many policy components for resource access, such as global policies, domain-specific policies, local policies, directory policies and so forth as defined across the organization and/or by the business owners. As is generally known in policy applications, concepts such as inheritance, override, blocking and so forth may be used to establish a combined policy for a resource. Nevertheless, while policies may thus be as complex as desired, as little as a single, straightforward policy may be used with the technology described herein, e.g., to grant access if the resource label and the ACL are met by the access token/user claims. At the same time, such a policy is easy to change, as the policy is separate from the individual resources.
In one implementation, the authorization engine 114 is based on Microsoft Corporation's Windows® 7 enhanced authorization runtime. The Windows® 7 runtime supports a conditional expressions language to specify complex policies using claims-based (name-value pairs-based) identities.
By way of example, the below policy (which can be rewritten into security descriptor definition language, or SDDL) states that XYZ company full-time employees can approve for approval amounts less than 10000 (dollars):
(XA;;APPROVE;;;WD;(member_of {SG_XYZ,SG_FTE} AND ApprovalAmount<10000)).
As an example of how policy is applied via labels and user claims as described herein, consider a company that wants to allow read access to documents carrying sensitive customer data by personnel (represented by membership in a security group) cleared to access sensitive customer data in the particular environment, such as the business unit hosting the files. This type of policy evaluates ‘necessity’ but not ‘sufficiency’ because the intent is not to allow the cleared personnel access to all sensitive customer data in the environment; rather access is only allowed when there is a business need to do so. This sufficiency policy is dictated by the ACL which is set according to the business needs of the document.
This kind of restriction is desired or required by government regulations in regulated industries such as Finance, Health care, Public sector and the like to prevent leakage of financial information, customer data and business critical data. As described above, policy enforcement using the current ACL model is not practical. The technology herein enforces policy without physically attaching the policy to the resource, thereby making it highly resilient, easily enforceable, and distributed across one or more collections of computers carrying business-sensitive data.
Continuing with the example of a company that wants to enforce access to specific user groups based on the resource label, to specify that only members of the group “SG_ClearedPrnl” can read files that carry a “customerData” claim, but otherwise anyone (with otherwise proper tokens for the resource's ACL) can read files without such data, the following may be set as the policy:
(XA;;GR;;;WD;(resource.Exists(customerData) AND member_of{SG_ClearedPrnl} OR NOT(resource.Exists(customerData)))
As can be seen, if a file contains customer data, read access is granted only to those users who are a member of the SG_ClearedPrnl group. If the file did not previously contain the customer data, but then was modified to include it, the file will be reclassified (due to the content change) and a resource label associated with that file that indicates that customer data exists in that file. Thus, the access changes based upon whether customer data exists in the file or not.
As another example, resource labels and user claims can be assigned levels, which may then be used in a comparative way to allow or disallow access to resource based on its classified level:
(XA;;GR;;;WD;(user.clearanceLevel>=resource.sensitivityLevel)
Another example allows access to files for a user's projects, even if that user is not part of a security group that can access the file. For example an non-employee such as a consultant can be give access to a file that is otherwise only accessible to employees by the following policy (which can be rewritten in an appropriate language):
(XA;;GR;;;WD;(user.projects OVERLAP resource.projects))
Note that the above provides for evaluating compound conditions that include user claims and resource labels that allow for late binding resolution. One example is “User.Projects any_of Resource.Projects” or the like.
FIG. 2 shows a simplified example of how policy may be used to determine access to a resource based upon an ACL and/or resource label versus user claims. In FIG. 2, there are two possible policies exemplified for using the ACL and resource label, namely whether both the ACL and the resource label are needed for access (that is, an AND logical combination, such as being a member in a user group AND having sufficient clearance), or whether either one grants access (that is, OR logical combination, such as a being member in a user group OR being identified as associated with a project). Policy sets how the logic is applied to a given resource, and as can be readily appreciated, more complex logical combinations (NOT, XOR and so forth) are feasible. For example, a resource label can require user membership in multiple groups (compound principals) to obtain access. Other examples include conditions such as making a resource accessible only to proper users at certain times of day, in certain amounts (as logged elsewhere), and so forth.
Step 202 represents determining whether for a given resource the resource label is cached, that is, whether classification has previously been performed. If so, step 204 evaluates whether the resource label is valid and up-to-date or whether reclassification is needed, as generally described in the aforementioned Alternate Data Stream Cache for File Classification” patent application. If initial classification (step 202) or reclassification (step 204) is needed, step 206 is executed to classify/reclassify the resource. Step 208 represents caching the classification properties, including the resource label or labels, for subsequent use.
Step 210 represents evaluating the user's access token versus the resource's ACL, that is, performing the conventional access check. If access would be granted, step 212 evaluates whether that is sufficient by itself (the policy states ACL access OR resource label access) in this simplified example; if so, access is granted as represented by step 220. This corresponds to the “project” example, e.g., a user may gain access by user group claim (versus ACL) OR having a project user claim (versus resource label).
The other way to obtain access in the “project” example is if the ACL does not grant access at step 210, but the policy is “OR resource label” at step 214. If so, step 216 evaluates user access via the user claims versus the resource label at step 216. If the resource label allows access, step 216 branches to step 220 to allow access, else access is denied via step 218.
As set forth above, the logic of FIG. 2 also handles an “AND” combination, such as needing to be in a security group AND having clearance for sensitive data. As can be readily appreciated by following the “AND” branches of steps 212 and/or 214, access requires both the ACL check be passed and the resource label be passed. Note that classification can set a resource label for a file such that step 216 is automatically passed (unless later reclassified differently), e.g., the sensitivity level is zero so that everyone has clearance until otherwise reclassified.
Note that the requested access-related operation for a resource may be more than simple read or write (or execute) access. Using one of the above examples, a user may be requesting file access to copy the file in clear text to a portable storage device (e.g., directly or via a clipboard). Although read access may be allowed when within the boundary of the access policy (e.g., on a domain machine), copying in clear text may or may not be allowed depending on the current file contents as reflected in the resource label versus the requestor's user claims. In the other example, another requested access-related operation may be to attach a piece of data to an email message, which will also depend on the resource label versus the requestor's user claims. Such policies may be specified, and may be implemented in a suitably-equipped authorization engine/operating system.
Moreover, the access policy may move with a file, such as in a file's alternate data stream. For example, based on the nature of a file's content, it may be desirable to package the access policy along with the file when it moves out of the boundary of the access policy, so that policy is applied if the file is copied back again into a device that respects the access policy. To enforce this operation the file is protected (e.g., encrypted) when beyond the boundary of the access policy.
Other scenarios for access based on resource properties include maintaining access policy across repositories. When a file moves between different machines and repositories (e.g., move from a file server to SharePoint®), as long as the file maintains its labels, and as long as the file stays in the same policy domain where the classification label is referenced to the same access policy, the access policy is maintained.
As can be seen, there is provided the ability to enforce access policy that is based on user claims versus resource labels, including for applying access policy to a file based on classification properties of that file. The user claims and resource labels may be used in sophisticated condition sets such as clearance/sensitivity levels, and/or other logical combinations. This facilitates flexible and complex policies, including for compound principals and other conditions, which are not presently available in known systems.
determining, by at least one processing unit, access to a resource based on policy decoupled from the resource, including by determining whether a resource label associated with the resource is cached, and if not, classifying the resource and caching the resource label, and if so, evaluating whether the resource label is valid or whether reclassification is needed, and evaluating the resource label associated with the resource against a user claim associated with an access request, wherein the resource label comprises a classification property associated with the resource that is used to determine access to the resource, and wherein the access request identifies the resource requested by the user claim;
responsive to a determination that the resource label is not valid, prompting reclassification of the resource to obtain a valid resource label;
responsive to a determination that the policy grants access to the resource based on the evaluation of the resource label and the user claim, allowing access to the resource; and
responsive to a determination that the policy does not grant access to the resource based on the evaluation of the resource label and the user claim, denying access to the resource.
determining whether granting access requires both access control list verification and resource label verification or if only one of the access control list verification or the resource label verification is sufficient for access to the resource.
4. The method of claim 1 wherein the resource is a file, and further comprising:
performing reclassification of the resource to update the resource label based upon at least one of a change to content of the file, a change to one or more labels of the file, a change to other attributes of the file, a change to a location of the file, a change to a classification rule, or a state change to one or more classification rules.
further determining the access based on an access control list coupled to the resource.
evaluating one or more access-related operations corresponding to the access request and determining whether each of the one or more access-related operations is allowed based on at least one of the resource label and an access control list.
an authorization engine configured to be executed by the one or more processors to determine access to a resource based upon a policy, the authorization engine configured to evaluate a resource label associated with the resource against a user claim associated with an access request using information in the policy, including to determine whether the resource label is valid or whether reclassification is needed to obtain an updated resource label, wherein the resource label comprises a classification property associated with the resource that is used to determine access to the resource, and wherein the access request identifies the resource requested by the user claim.
10. The system of claim 9 wherein the authorization engine is incorporated into a security model of an operating system.
a classifier configured to provide one or more resource labels for the resource, the resource including a file, and the classifier further configured to provide the one or more resource labels by classifying the contents of the file, including a sensitivity level associated with the contents of the file.
14. The system of claim 9 wherein the resource is associated with an access control list, and wherein the authorization engine configured to evaluate the resource label against the user claim is further configured to evaluate the access control list against an access token to determine the access to the resource.
16. One or more computer storage devices having computer-executable instructions stored thereon, which in response to execution by a computer, cause the computer to perform steps comprising:
processing an access request to grant or deny access to a resource, including evaluating one or more access-related operations corresponding to the access request, obtaining a policy that is decoupled from the resource, and using the policy to determine whether to grant or deny each of the one or more access-related operations, including by evaluating a resource label associated with the resource against a user claim associated with the access request, wherein the resource label comprises a classification property associated with the resource that is used to determine access to the resource, and wherein the access request identifies the resource requested by the user claim.
17. The one or more computer storage devices of claim 16 wherein the resource is a file, and having further computer-executable instructions comprising, classifying the file into classification properties, including a classification property corresponding to the resource label.
18. The one or more computer storage devices of claim 16 wherein the resource is a file, wherein the resource label is cached in association with the file, and having further computer-executable instructions comprising:
determining whether the resource label is valid and up-to-date;
responsive to a determination that the resource label is not valid and up-to-date, obtaining a valid and up-to-date resource label; and
caching the valid and up-to-date resource label in association with the file.
19. The one or more computer storage devices of claim 16 wherein a plurality of policies are applicable, and wherein using the policy to determine whether to grant or deny the access-related operation further comprises logically combining a result of evaluating a resource label associated with the resource against a user claim with a result of at least one other policy evaluation.
20. The one or more computer storage devices of claim 19 wherein a result of at least one other policy evaluation comprises an access control list-based evaluation result.
US12622441 2009-11-20 2009-11-20 Controlling resource access based on resource properties Active 2031-11-27 US9038168B2 (en)
US12622441 US9038168B2 (en) 2009-11-20 2009-11-20 Controlling resource access based on resource properties
EP20100831970 EP2502144B1 (en) 2009-11-20 2010-10-29 Controlling resource access based on resource properties
PCT/US2010/054722 WO2011062743A3 (en) 2009-11-20 2010-10-29 Controlling resource access based on resource properties
KR20127012954A KR101751088B1 (en) 2009-11-20 2010-10-29 Controlling resource access based on resource properties
CN 201080052356 CN102667719B (en) 2009-11-20 2010-10-29 Based on the resource property resource access control
JP2012539924A JP5722337B2 (en) 2009-11-20 2010-10-29 Resource access control based on the resource properties
US20110126281A1 true US20110126281A1 (en) 2011-05-26
US9038168B2 true US9038168B2 (en) 2015-05-19
ID=44060263
US12622441 Active 2031-11-27 US9038168B2 (en) 2009-11-20 2009-11-20 Controlling resource access based on resource properties
US (1) US9038168B2 (en)
EP (1) EP2502144B1 (en)
JP (1) JP5722337B2 (en)
KR (1) KR101751088B1 (en)
CN (1) CN102667719B (en)
WO (1) WO2011062743A3 (en)
EP2696303B1 (en) 2012-08-03 2017-05-10 Alcatel Lucent Mandatory access control (MAC) in virtual machines
CN104796290A (en) * 2015-04-24 2015-07-22 广东电网有限责任公司信息中心 Data security control method and data security control platform
CN104809405A (en) * 2015-04-24 2015-07-29 广东电网有限责任公司信息中心 Structural data asset leakage prevention method based on hierarchical classification
CN104866780B (en) * 2015-04-24 2018-01-05 广东电网有限责任公司信息中心 Unstructured data assets leakage prevention method based on a hierarchical classification
CN1782943A (en) 2004-10-01 2006-06-07 微软公司 Integrated access authorization
JP2007293630A (en) 2006-04-25 2007-11-08 Toshiba Corp Access control method and database system using the same
CN101114295A (en) 2007-08-11 2008-01-30 腾讯科技（深圳）有限公司 Method for searching on-line advertisement resource and device thereof
US20080034438A1 (en) 2006-08-07 2008-02-07 International Business Machines Corporation Multiple hierarchy access control method
CN101448002A (en) 2008-12-12 2009-06-03 北京大学;北大方正集团有限公司;北京方正电子政务信息科技有限公司 Method and device for accessing digital resources
"Fifth Office Action and Search Report Issued in Chinese Patent Application No. 201080052356.X", Mailed Date: Dec. 15, 2014, 14 Pages.
"Fourth Office Action and Search Report Issued in Chinese Patent Application No. 201080052356.X", Mailed Date: Jul. 8, 2014, 15 Pages.
"International Search Report", Mailed: Jun. 23, 2011, Application No. PCT/US2010/054722, Filed Date: Oct. 29, 2011.
"Logical Access Control", retrieved at <<http://csrc.nist.gov/publications/nistpubs/800-12/800-12-html/chapter17.html>> Jul. 6, 2007, pp. 14.
"Logical Access Control", retrieved at > Jul. 6, 2007, pp. 14.
"Mandatory, Discretionary, Role and Rule Based Access Control", Retrieved at <<http://www.techotopia.com/index.php/Mandatory,-Discretionary,-Role-and-Rule-Based-Access-Control>> Oct. 12, 2009, pp. 4.
"Mandatory, Discretionary, Role and Rule Based Access Control", Retrieved at <<http://www.techotopia.com/index.php/Mandatory,—Discretionary,—Role—and—Rule—Based—Access—Control>> Oct. 12, 2009, pp. 4.
"Office Action Received for European Patent Application No. 10831970.8", Mailed Date: May 30, 2014, Filed Date: Oct. 29, 2010, 4 Pages.
"Office Action Received for Japan Patent Application No. 2012-539924", Mailed Date: Apr. 15, 2014, Filed Date: Oct. 29, 2010, 11 Pages.
"Second Office Action Received for China Patent Application No. 201080052356.X", Mailed Date: Sep. 23, 2013, Filed Date: Oct. 29, 2010, 13 Pages.
"Third Office Action Received for China Patent Application No. 201080052356.X", Mailed Date: Jan. 30, 2014, Filed Date: Oct. 29, 2010, 8 Pages.
"What is the Windows Integrity Mechanism?", Retrieved at <<http://msdn.microsoft.com/en-us/library/bb625957.aspx>> Oct. 13, 2009, pp. 3.
"What is the Windows Integrity Mechanism?", Retrieved at > Oct. 13, 2009, pp. 3.
"What's New in File Server Resource Manager in Windows Server 2008 R2", Retrieved at <<http://technet.microsoft.com/en-us/library/dd464014.aspx>> Feb. 7, 2009, pp. 2.
"What's New in File Server Resource Manager in Windows Server 2008 R2", Retrieved at > Feb. 7, 2009, pp. 2.
Burnside, et al., "Access-Controlled Resource Discovery", Retrieved at <<http://csg.csail.mit.edu/pubs/reports/search3.pdf>> MIT Laboratory for Computer Science, Mar. 2002, pp. 137-138.
Burnside, et al., "Access-Controlled Resource Discovery", Retrieved at > MIT Laboratory for Computer Science, Mar. 2002, pp. 137-138.
Hart, et al., "More Content-Less Control: Access Control in the Web 2.0", In IEEE Symposium on Security and Privacy Workshop on Web 2.0 Security, Jan. 1, 2007, pp. 1-3.
Hart, et al., "More Content—Less Control: Access Control in the Web 2.0", In IEEE Symposium on Security and Privacy Workshop on Web 2.0 Security, Jan. 1, 2007, pp. 1-3.
KR20120117018A (en) 2012-10-23 application
EP2502144B1 (en) 2016-04-20 grant
JP5722337B2 (en) 2015-05-20 grant
CN102667719B (en) 2015-08-26 grant
CN102667719A (en) 2012-09-12 application
KR101751088B1 (en) 2017-06-26 grant
EP2502144A4 (en) 2013-05-22 application
US20110126281A1 (en) 2011-05-26 application
WO2011062743A2 (en) 2011-05-26 application
WO2011062743A3 (en) 2011-08-18 application
EP2502144A2 (en) 2012-09-26 application
JP2013511770A (en) 2013-04-04 application
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BEN-ZVI, NIR;KALACH, RAN;WOLLNIK, MATTHIAS H.;AND OTHERS;SIGNING DATES FROM 20091112 TO 20091118;REEL/FRAME:023548/0023