Generally, the present invention relates to computing environments involving access to sensitive materials. Particularly, it relates to authoring and accessing redacted content based on user roles. Various features relate to computer software products, systems for same and methods. Access indicia, monitored connections, user-interfaces, and logging, to name a few, are other noteworthy features.
Current security around sensitive documents (e.g., spreadsheets, PDFs, Word documents, etc.) centers on basic password protection. Typically there exists a single password for a document and it unlocks the document in all-or-nothing fashion. Somewhat less typically, an application like the Adobe Acrobat application (the full version—not the Reader version) supports two levels of passwording, for roles of both a user and a system administrator. The roles differ in that whereas a user can use their password to open the document (but not necessarily print it or edit it), an administrator can open the document as well as reset passwords and override global properties such as read/write status, print protection, and copy/paste enablement, for instance.
While two-level support is better than a single-level, there are still many drawbacks. First, the level of role support in the prior art is coarse. That is, there are at best two roles, but the rights for each role apply globally across all of a document's content (without regard to individual sections). Second, roles are not actually calculated against the identities of the accessing party. A password is all that is needed, regardless of whether the provider of the password is actually the person corresponding to it. It is assumed that if the user has the correct password, he/she must be in the correct role. But this has various problems in that: 1) the user's role may have changed between the time the password was granted and the time it was used; 2) the user's identity is not checked against the asserted role; and 3) as stated before, the scope of the password is for the document-as-a-whole, not interior portions of content. It is also hard, in general, to bring access to redacted content under policy control in a governance sense, because “governance events” tend to occur at the level of resource access (document or folder access), not at the level of access to particular data items within documents.
Third, many techniques used to appropriately promulgate sensitive materials consists of providing many versions of the same content, with only the appropriate party having access to their appropriately-authorized portion. This creates multiple versions of a document for multiple audiences, which complicates security.
In view of these various problems which are not adequately addressed by current art, there is need in the art of sensitive materials to feasibly control access to various interior portions of a document. There is a further need to allow access on just-in-time calculations of user entitlements through a mechanism, including the ability to log and monitor such events. Reducing the number of versions of a document that need to be created and circulated, and also eliminating complex dynamic content-filtering schemes per different users, in which complex, highly tailored documents must be pulled together on the fly, is another noteworthy objective. While no document technology exists that can guarantee that sensitive content, once unlocked, will not be misused by humans, it remains desirable in today's world to show that reasonable precautions have been taken, in the design of software, to deter content theft, mitigate harmul outcomes related thereto, etc. Thus, governance and audit-trail or “chain of custody” notions are other notions to be considered. Naturally, any improvements along such lines should further contemplate good engineering practices, such as relative inexpensiveness, stability, ease of implementation, low complexity, flexibility, etc.
The above-mentioned and other problems become solved by applying the principles and teachings associated with the hereinafter-described role-based access to redacted content. In a basic sense, the invention provides techniques for implementing role-based access control over redacted sections of documents (or other material, such as images, video, etc. (collectively, content)), on a per-role/per-section basis, while also allowing such access to be monitored and controlled in real time in an identity infrastructure. Redactions are seen as unlockable chunks that can be viewed/manipulated in unencrypted form only if a user has appropriate role-based privileges.
Example: Bob, Mary, and Mitchell all need access to a particular document (which could be a word processing document, a PDF document, a spreadsheet, or some other kind of document). The document might contain a patient's medical information. Mary, as the primary care physician, needs access to the medical history portion of the document but is not entitled to see annotations having to do with the patient's payment history or financial status. Bob, as the hospital's CFO, is entitled to see the payment-history info but is not entitled to see the medical history. Mitchell is the patient. He is entitled to see everything in this document.
Sensitive areas of the document are blacked-out or obscured (redacted). The content is present in the document in encrypted form. Such areas can be unlocked if the person attempting to view the content has appropriate rights. The invention provides mechanisms whereby users with different rights can unlock and see just the portions of a document they are entitled to see based on their role (and do it in a way that can be monitored, logged, and audited in a highly govemanced environment).
In terms of security, a basic assumption exists that a user who has a legitimate right to gain access to a document, or to a portion of a document, is not malicious and will not misuse his or her privileges. Nevertheless, the invention is mindful of the desirability of discouraging and/or monitoring the unauthorized use of unlocked content, and certain features are designed with that in mind.
In a representative embodiment of usage, an author designates portions of content as to-be-redacted. The author establishes various users roles able to access it and defines attributes or time constraints affecting the viewing/using. Upon electronically saving the content, the to-be-redacted portion is encrypted. An intermediary, such as a keytable service, mediates access between later users and the content. Upon identification of a role of a user attempting to interact with the content, and matching the role to one of the author-established roles, the encrypted redacted portion is decrypted. Otherwise, access to the encrypted redacted portions are prevented but not the remainder of the content. In this manner, users gain access to content based only on their role and adds robustness heretofore unavailable. The surrounding events are also loggable, traceable, and verifiable.
In another usage example, a first user of a software program, in the form of (for example) a spreadsheet software application, has the title or identity of president in an organization and therefore has need of knowing the final budgets of departments under his command, and is (by virtue of role) duly entitled to know such information. Each department head of the organization, e.g., second, third, fourth, etc. users of the spreadsheet software application, need not know (and may in fact be forbidden, by formal organization policy, from knowing) the budget totals of other departments. Thus, the president has need of a software product calculating and showing totals of all rows, columns, etc. of the organization, whereas an individual department head only has need of calculating and showing totals of all rows and columns, etc. for his (and only his) department. Thus, the same software program (e.g., the spreadsheet software application) has different users with different needs and entitlements (the needs/entitlements being defined by policies of the organization that require the president to have an all access pass while each department head only has a limited access view). Being able to control access to the spreadsheet software application with different capabilities or features per each of the different users, per policy, and in recognition of a given individual's role, then has usefulness not afforded by the prior art. It is further an aspect to allow this control according to the authoring stage of the content.
In a computing system environment, the invention may be practiced with a first computing device interacting with a computer program product that allows an author to designate portions of the content as redacted, with the product including allowing the author to establish access indicia to the redacted portions by way of various user roles and according to any attributes or time constraints. A mediation computing device, different than the first computing device, but connected to the first computing device, interacts with a user of the redacted content to identifying a role of a user attempting to interact with the content. If the role of the user matches one of the author-established user roles, the mediation computing device decrypts the encrypted redacted portions. Otherwise, the mediation computing device prevents access to the encrypted redacted portions, but still allows the user to view/use the unencrypted portions. Either the first or mediation computing device are configured to encrypt the redacted portions upon an indication by the author to electronically save the content. A third computing device, the same or different as the first computing device, interacts with the mediation computing device in a monitored connection (including or nor a heartbeat message) that only allows access to the redacted content to occur upon timely transmissions and receipts by the two devices, e.g., a time-responsive manner.
Computer program products are also disclosed. For instance, a product available as a download or on a computer readable medium has: 1) a document space for display on a monitor for an author to visually see content created in the document space; 2) a visual interface for display on the monitor for the author to designate a portion of the content created in the document space as redacted and to designate various users roles able to access the redacted portion; 3) a saving component causing local or remote encryption of the redacted content upon receipt of an indication from the author to electronically save the content; and 4) a displaying component to visually show the user, attempting to interact with the content, the redacted portion in encrypted form if the role of the user does not match one of the designated various user roles. Among other things, this overcomes the prior art's document unlocking in all-or-nothing fashion.
These and other embodiments of the present invention will be set forth in the description which follows, and in part will become apparent to those of ordinary skill in the art by reference to the following description of the invention and referenced drawings or by practice of the invention. The claims, however, indicate the particularities of the invention.
The accompanying drawings incorporated in and forming a part of the specification, illustrate several aspects of the present invention, and together with the description serve to explain the principles of the invention. In the drawings:
In the following detailed description of the illustrated embodiments, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention and like numerals represent like details in the various figures. Also, it is to be understood that other embodiments may be utilized and that process, mechanical, electrical, arrangement, software and/or other changes may be made without departing from the scope of the present invention. In accordance with the present invention, methods and apparatus for accessing redacted content per user roles are hereinafter described.
With reference to
In either, storage devices are contemplated and may be remote or local. While the line is not well defined, local storage generally has a relatively quick access time and is used to store frequently accessed data, while remote storage has a much longer access time and is used to store data that is accessed less frequently. The capacity of remote storage is also typically an order of magnitude larger than the capacity of local storage. Regardless, storage is representatively provided for aspects of the invention contemplative of computer executable instructions, e.g., software, as part of computer program products on readable media, e.g., disk 14 for insertion in a drive of computer 17. Computer executable instructions may also be available as a download or reside in hardware, firmware or combinations in any or all of the depicted devices 15 or 15′.
When described in the context of computer program products, it is denoted that items thereof, such as modules, routines, programs, objects, components, data structures, etc., perform particular tasks or implement particular abstract data types within various structures of the computing system which cause a certain function or group of functions. In form, the computer product can be a download or any available media, such as RAM, ROM, EEPROM, CD-ROM, DVD, or other optical disk storage devices, magnetic disk storage devices, floppy disks, or any other medium which can be used to store the items thereof and which can be assessed in the environment.
In network, the computing devices communicate with one another via wired, wireless or combined connections 12 that are either direct 12a or indirect 12b. If direct, they typify connections within physical or network proximity (e.g., intranet). If indirect, they typify connections such as those found with the internet, satellites, radio transmissions, or the like, and are given nebulously as element 13. In this regard, other contemplated items include servers, routers, peer devices, modems, T1 lines, satellites, microwave relays or the like. The connections may also be local area networks (LAN) and/or wide area networks (WAN) that are presented by way of example and not limitation. The topology is also any of a variety, such as ring, star, bridged, cascaded, meshed, or other known or hereinafter invented arrangement.
With the foregoing representative computing environment as backdrop, the invention can be implemented in any conventional desktop application that allows document authoring and using or viewing (word processing applications, spreadsheet applications, and so forth). It is common for such applications to support an online mode in which a connection is made to remote server, for example to register a product, check for updates, check for license expiration, etc. The invention leverages this connectivity to apply SOA-friendly techniques to the management of access to redacted content, such as by way of the mediation service.
With reference to
At step 32, upon a user attempting to interact with the content, their role is identified. As will be seen below, the identification may occur by way of a mediation service, or by way of an active portion of the content itself. The role of the user could be varied. Representatively, it could be that as found in an corporate organization, such as an officer, manager, accountant, salesman, secretary, etc., in a government entity, such as judge, clerk, mayor, police officer, etc., in a sporting team, such as pitcher, catcher, or a more informal identity as would be found in a club, such as singer, dancer, etc. Of course, skilled artisans can contemplate others.
At step 34, if the user's role is an appropriate role for accessing redacted content after the apportionment, access to the redacted portion is allowed at step 36. Otherwise, access is prevented at step 38. However, access to the un-redacted portion of the content is still viewable/usable by the viewer. In this manner, users gain access to content based only on their role and adds robustness heretofore unavailable. It overcomes the prior art's document unlocking in all-or-nothing fashion. The surrounding events are also loggable, traceable, and verifiable.
With more detail,
In still a more detailed version of authoring (
Regardless of how indicated, the establishment of access indicia to the content occurs at step 64 (seen as dashed line,
Turning back to
With reference to
Recapping, however, the following is general about the authoring functionalities:
1. Ability for an author of a document to select a section of the document and designate it as “redacted.” (When the document is later saved, any areas so designated will be encrypted, following mechanisms described further below.)
2. Ability for the author to select a redacted area and apply role constraints to it. For example, the author can choose to apply one or more organizational roles to a selection, meaning that only a person acting in one of those roles can view the redacted text. (It will be appreciated that although the word “text” of a “document” is used here, and elsewhere, the area in question can actually be an image, an audio annotation, a form control, an attachment, or any other kind of content that can exist in a given document; or a combination of such content types treated as a group.)
3. Ability for the author to set attribute values (for things like write permission, print permission, and copy/paste permission) on the redacted area, on a per-role basis. So in other words, through an appropriate UI mechanism, the author of the document will be able to specify that a person in the role of Security Officer is able to print an unlocked piece of the document whereas no one in any other role can print the unlocked text. The same redacted content may very well be accessible to, say, a Manager for viewing, but not for printing. To a non-Manager who is also not a Security Officer, the redacted area will either be blacked out, or it will be invisible so that the user doesn't even know that the redaction exists.
4. Ability for the author to specify a session-based time-to-live value for redacted content during a viewing session. For example, the author may decide that a given piece of redacted content, once unlocked, should remain unlocked for no more than 30 minutes at a time, such that if the viewer of the document leaves his desk (to go to lunch, say) without closing the document, the restricted content “times out” and reverts to its fully redacted appearance.
5. The ability to specify a URL or other address to which requests involving access to redacted content may be delegated. (This might actually be under the control of a system administrator, who sets the URL in a configuration parameter somewhere, eliminating the need for the user to specify it directly.)
6. A service, whose endpoint is the URL just mentioned, hereafter called the keytable service, for example. The responsibilities of this service will be discussed in detail further below.
7. Program logic (either incorporated into the core program or one of its library modules, or as a plug-in, etc.) that accomplishes the following: When the author of a redacted document issues the Save command, the program will (as part of the Save) establish a secure connection to the keytable service mentioned previously. In one embodiment, the authoring program calculates a passkey for each role associated with each piece of redacted content; and that key, along with a role identifier for it, and the document ID (and/or other metadata), are sent to the keytable service for storage. Hashed versions of the role-based passkey(s) are stored in the document itself, and redacted regions of content are encrypted using the various hashes. In another embodiment, the authoring program merely sends (for each redacted region) a role identifier and document ID (and/or other metadata) to the remote keytable service. The service, in turn, calculates a passkey for each role and sends the hashed value(s) back to the authoring program for storage in the document. Every redacted piece of content is encrypted using the appropriate hash, then the document is finally saved. The keytable service stores the unhashed version of each passkey for later retrieval, each key being associated with a role, and the entire collection of keys and roles being associated with the document ID so that the collection can be looked up by document-ID later.
Turning to
As in representative
In another type of embodiment,
In sum, it can be appreciated that calculation of the user's role can happen transparently, if the user has previously authenticated to a single-signon infrastructure in which the components of the invention are federated; or can happen through a challenge; said challenge can occur at the time of document opening, or at the time a redaction is clicked; and the actual role calculation can take place on a (real or virtual) server that is not necessarily the same one that hosts the keytable service. The important thing is that the user will, at some point, undergo a role-sufficiency check before being allowed to view restricted content.
With reference to
In various embodiments, the foregoing makes certain assumptions. For instance, it is assumed that all keys are stored and managed at one endpoint (the keytable service URL). It can be appreciated, however, that multiple unique authorization endpoints could be specified for the various redactions in a document, and also that one or more of these endpoints could trigger a workflow or other process, and that the workflow so triggered could involve human intervention, such that the human proprietor of restricted content could be contacted in real time in order to get permission to view the content. For example, a medical document may contain information, in certain form fields, that only the patient can dispense. The viewing physician (who might not be the primary doctor but a consultant on the case, miles away) clicks on a redacted form field; a service endpoint is contacted, which in turn dials the patient's cell phone number; and the patient hears a message and enters a code to authorize the unlocking of the redaction.
Certain advantages and benefits of the invention over the prior art should now be readily apparent. For example, but not limited to, the invention: 1) allows role-based access control to be applied to individual pieces of content within a larger document, rather than (or possibly in addition to) exercising access control at the document level, thereby giving fine-grained access control; 2) contemplates being able to federate role-restricted redactions into a SSO environment; 3) enables unlocking role-differentiated content in real time, in response to user actions, while the user is actually viewing a document; 4) allows revoking user privileges on role-restricted content in real time; 5) automatically “times out” in accordance with a set TTL value (as a security precaution to limit unnecessary exposure of sensitive content) and enables specifying TTLs on a redaction-by-redaction basis; 6) enables the notion of applying role-tailored attribute constraints (with respect to printing, editing, saving, copying, pasting, etc.) to a viewing program, under realtime control of a remote service (which could be a policy service); 7) contemplates cases where attempting to access a piece of content that is redacted triggers a workflow (which could in turn trigger anything from a text message by cell phone, an audio phone call, an IM ping, an e-mail transmission, or almost anything) involving human intervention by a content proprietor; 8) contemplates application to sub-regions of images in larger images created using Illustrator or Photoshop or a like program. Of course, these are only a few of the many advantages of the invention and skilled artisans will immediately recognize others. In still other embodiments, the practice of the invention could be adapted to web pages or other online content by applying a role-based view to content through access to WebDAV annotations. The uses for this, however, would probably be of a slightly different type than for the word-processing and other offline document scenarios described mostly above.
Finally, one of ordinary skill in the art will recognize that additional embodiments are also possible without departing from the teachings of the present invention. This detailed description, and particularly the specific details of the exemplary embodiments disclosed herein, is given primarily for clarity of understanding, and no unnecessary limitations are to be implied, for modifications will become obvious to those skilled in the art upon reading this disclosure and may be made without departing from the spirit or scope of the invention. Relatively apparent modifications, of course, include combining the various features of one or more figures with the features of one or more of other figures.