Dynamic runtime field-level access control using a hierarchical permission context structure

This disclosure provides for a system, method, and machine-readable medium for performing dynamic runtime field-level access control using a hierarchical permission context structure. The hierarchical permission context structure includes various levels of roles, where each role is assigned one or more permissions. The one or more permissions assigned to the one or more roles indicate the amount of control a given user has over data displayable in an electronic document. The electronic document includes one or more fields having corresponding records in one or more databases. A record includes metadata about the data for a corresponding field. When an electronic document is requested, the fields of the electronic document are generated from the data stored in their corresponding records. An evaluation is performed that determines whether the user requesting the electronic document is authorized to view the data for one or more of the fields based on their corresponding metadata.

TECHNICAL FIELD

The subject matter disclosed herein generally relates to systems and methods for controlling access to one or more fields displayable in an electronic document and, in particular, to systems and methods for dynamic runtime field-level access control using a hierarchical permission context structure.

BACKGROUND

Information systems often allow one or more users access to an electronic document, such as a HyperText Markup Language (“HTML”) document. More particularly, such information systems allow these users to access documents that are generated from information stored in one or more electronic databases. The information may be stored as a record in the one or more electronic databases such that, when the electronic document is generated, the records are retrieved from the one or more electronic databases and the electronic document is generated in real time or near real time.

However, in some circumstances, these electronic documents will be generated from sensitive data. In addition, not every user will have the same permissions to access or view data marked as sensitive. Typical solutions to prohibit the accessing or viewing of the sensitive data prevent complete access to the electronic document or to deny unauthorized users from viewing or displaying the electronic document. These solutions are untenable because they prevent information sharing and collaboration as there is a lack of data transparency. In some instances, for regulatory, business, or other reasons, users may have need to see as much data as possible at a field or attribute level.

DETAILED DESCRIPTION

Example methods and systems are directed to controlling access to one or more fields displayable in an electronic document and, in particular, to systems and methods for dynamic runtime field-level access control using a hierarchical permission context structure. In one embodiment, the hierarchical permission context structure includes various levels of roles, where each role is assigned one or more permissions. Roles may include, but are not limited to, administrator, data owner, data creator, and general user. Furthermore, roles may be assigned arbitrarily determined names where the names indicate an organization, department, committee, or other organizational structure. In one embodiment, the hierarchical permission context structure is defined as a tree structure where a node of the tree structure may have one or more parent nodes and/or one or more child nodes. A node of the tree structure may correspond with a defined role such that a parent node may represent a role having more permissions than a given role and a child node may represent a role having less permissions than the given role.

In one embodiment, each level of the hierarchical permission context structure is assigned one or more permissions. Starting with the root node, this node may have the most amount of permissions (e.g., the least number of restrictions) whereas the bottommost leaves of the structure may have the least amount of questions (e.g., the most number of restrictions). Alternatively or in addition, each role (e.g., each node) may be associated with one or more permissions. The one or more permissions assigned to the one or more roles indicate the amount of control a given user has over data displayable by an application server. For example, the one or more permissions may indicate whether a user can edit the data, view the data, delete the data, or otherwise manipulate or modify the data. Thus, roles that are assigned to nodes located at lower levels of the hierarchical permission context structure may have more restrictions whereas roles are assigned to nodes located at higher levels of the hierarchical permission kind of structure may have less restrictions. As an example, an “administrator” will have more permissions than a “general user.”

An application server provides access to electronic documents that are generated from data stored in one or more electronic databases. In one embodiment, an electronic document includes one or more fields where a selected field has a corresponding record in the one or more electronic databases. Furthermore, and in one embodiment, a given record includes metadata about the data for the selected field (e.g., the data stored in the record), such as the type of data represented by the record, the user that created the record, a label indicating what type of data the data represents, a unique identifier that identifies the record, whether the data is generally viewable, any classified level associated with the data, and the data itself (e.g., the value of the record). When the application server is accessed by a user and an electronic document is requested, the application server generates the electronic document from the data stored in the record and evaluates whether the user requesting the data is authorized to view the data in view of the metadata corresponding to the requested data. In one embodiment, where the user is not authorized to view the value of the requested data, the disclosed systems and methods permit the user to know that the data exists, but not the value of the data.

As the determination of whether the user is permitted to view the requested data is performed at or about the time the data is requested, the system can generate the requested electronic documents in near real-time (e.g., at or about the time the electronic document is requested). Furthermore, as the time determination for the requested data is performed on a field-level basis (e.g., the individual fields of the electronic document are evaluated), the disclosed systems and methods can selectively determine those fields that the user is permitted to view the corresponding data and those fields that the user is prohibited from viewing. In this manner, the disclosed systems and methods provide a technical benefit over prior art solutions in that requested electronic documents are customized for each requesting user, and that the determination of whether a user can view the data associated with a given field is made more efficient through the hierarchical permission context structure.

With reference toFIG. 1, an example embodiment of a high-level client-server-based network architecture102is shown. An application server112provides server-side functionality via a network114(e.g., the Internet or wide area network (WAN)) to one or more client devices104.FIG. 1illustrates, for example, a web client106(e.g., a browser, such as the Internet Explorer® browser developed by Microsoft® Corporation of Redmond, Wash. State), an application108, and a programmatic client110executing on client device104. The application server112is further communicatively coupled with one or more database servers124that provide access to one or more databases118-120.

The client device104may comprise, but is not limited to, a mobile phone, desktop computer, laptop, portable digital assistants (PDAs), smart phones, tablets, ultra books, netbooks, laptops, multi-processor systems, microprocessor-based or programmable consumer electronics, or any other communication device that a user122may utilize to access the application server112. In some embodiments, the client device104may comprise a display module (not shown) to display information (e.g., in the form of user interfaces). In further embodiments, the client device104may comprise one or more of a touch screens, accelerometers, gyroscopes, cameras, microphones, global positioning system (GPS) devices, and so forth. The client device104may be a device of a user122that is used to perform one or more searches for user profiles accessible to, or maintained by, the social networking server112.

In one embodiment, the application server112is a network-based appliance that responds to initialization requests or search queries from the client device104. One or more users122may be a person, a machine, or other means of interacting with client device104. In various embodiments, the user122is not part of the network architecture102, but may interact with the network architecture102via the client device104or another means. For example, one or more portions of network114may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a wireless network, a WiFi network, a WiMax network, another type of network, or a combination of two or more such networks.

The client device104may include one or more applications (also referred to as “apps”) such as, but not limited to, a web browser, messaging application, electronic mail (email) application, an application access client, and the like. In some embodiments, if the application access client is included in the client device104, then this application access client is configured to locally provide the user interface and at least some of the functionalities with the application configured to communicate with the application server112, on an as needed basis, for data and/or processing capabilities not locally available (e.g., access to a member profile, to authenticate a user122, to verify a user's permissions, etc.). Conversely if the application access client is not included in the client device104, the client device104may use its web browser to access the initialization and/or search functionalities of the application server112.

One or more users122may be a person, a machine, or other means of interacting with the client device104. In example embodiments, the user122is not part of the network architecture102, but may interact with the network architecture102via the client device104or other means. For instance, the user122provides input (e.g., touch screen input or alphanumeric input) to the client device104and the input is communicated to the networked system102via the network114. In this instance, the application server112, in response to receiving the input from the user122, communicates information to the client device104via the network114to be presented to the user122. In this way, the user122can interact with the application server112using the client device104.

Further, while the client-server-based network architecture102shown inFIG. 1employs a client-server architecture, the present subject matter is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, architecture system, for example.

In addition to the client device104, the application server112communicates with other one or more database server(s)124and/or database(s)118-120. In one embodiment, the application server112is communicatively coupled to an application database118and an authentication database120. The databases118-120may be implemented as one or more types of databases including, but not limited to, a hierarchical database, a relational database, an object-oriented database, one or more flat files, or combinations thereof. Examples of commercially available databases that may be used as the databases118-120include Oracle Database 12c and MySQL, which are both available from the Oracle Corporation.

The application server112provides access to one or more electronic documents displayable by the client device104. The electronic documents are dynamically generated by the application server112using data stored in the application database118. As discussed below with reference toFIG. 2, the application server112, in various embodiments, includes a server-side interpreter that generates the electronic documents according to a computer-programming language and/or computer-scripting language. The one or more electronic documents may have one or more defined fields which correspond to one or more records stored in the application database118. Accordingly, and in one embodiment, the application database118stores one or more records for data retrieval by the application server112. As discussed below with reference toFIG. 5, the one or more records may include one or more fields that describe the data corresponding to a given record. As electronic documents are requested by the client device104, the application server112determines whether the data stored in a given record corresponding to a field in a given electronic document is displayable by the client device104. As explained further below, this determination may be performed by comparing the user permissions associated with a given record with the user permissions associated with the user of the client device104requesting the electronic document.

In addition to the application database118, the application server112is communicatively coupled to an authentication database120. In one embodiment, the authentication database120includes one or more records corresponding to users of the application server112. Each record may include one or more fields that identify the roles assigned to a corresponding user. As discussed below with reference toFIG. 4, the authentication database120may store a hierarchical permission context structure that defines the permissions a role has with respect to the data stored in the application database118. In one embodiment, the hierarchical permission context structure is representable as a tree structure, where the tree structure includes one or more nodes connected by one or more edges. The root node may correspond to an administrative role, with the administrative role has the most permissions with respect to the data stored in the application database118. With this role, such permissions may include, but are not limited to, creating new records, defining and/or modifying fields within each record, modifying or otherwise manipulating the data stored within the fields for each record, and other such permissions. As the depth level for the tree increases, the nodes at a given depth level may have fewer permissions (e.g., more restrictions) than the nodes closer to the root node. For example, the restricted permissions may include being able to only read data, being able to read only certain types of data, having a specified classified level that determines which data is viewable to the role corresponding to the record, and other such permissions. In addition, for each record in the authentication database120, and in one embodiment, the record includes a field that stores and node identifier that identifies the node corresponding to the given record. The record may further include other node identifiers, such as a parent node identifier, one or more child node identifiers, and other such node identifiers.

When a user is defined within the authentication database120(e.g., a new record is created for the corresponding user) the new record may include an identifier that identifies the role (e.g., the node within the hierarchical permission context structure) to which the user belongs. In this manner, an administrator simply defines the role for a given user to identify the fields of an electronic document that a user may manipulate rather than having to define the permissions with respect to each field of the electronic document.

In one embodiment, the application server112communicates with the various databases118-120through one or more database server(s)124. In this regard, the database server(s)124provide one or more interfaces and/or services for providing content to, modifying content, removing content from, or otherwise interacting with the databases118-120. For example, and without limitation, such interfaces and/or services may include one or more Application Programming Interfaces (APIs), one or more services provided via a Service-Oriented Architecture (“SOA”), one or more services provided via a REST-Oriented Architecture (“ROA”), or combinations thereof. In an alternative embodiment, the application server112communicates with the databases118-120and includes a database client, engine, and/or module, for providing data to, modifying data stored within, and/or retrieving data from, the one or more databases118-120.

While the database server(s)124are shown to include the application server112, one of ordinary skill in the art will recognize that other servers may also be included in the database server(s)124. For example, database server(s)124may include, but are not limited to, a Microsoft® Exchange Server, a Microsoft® Sharepoint® Server, a Lightweight Directory Access Protocol (“LDAP”) server, any other server configured to provide information, or combinations thereof. Accordingly, and in one embodiment, the servers implemented by the organization and configured to access the application database118and/or the authentication database120are further configured to communicate with the application server112.

FIG. 2illustrates the application server112ofFIG. 1in accordance with an example embodiment. In one embodiment, the application server112includes one or more processor(s)204, one or more communication interface(s)202, and a machine-readable medium206that stores computer-executable instructions for one or more modules(s)208and data210used to support one or more functionalities of the modules208.

The various functional components of the application server112may reside on a single device or may be distributed across several computers in various arrangements. The various components of the application server112may, furthermore, access one or more databases (e.g., databases118-120or any of data210), and each of the various components of the application server112may be in communication with one another. Further, while the components ofFIG. 2are discussed in the singular sense, it will be appreciated that in other embodiments multiple instances of the components may be employed.

The one or more processors204may be any type of commercially available processor, such as processors available from the Intel Corporation, Advanced Micro Devices, Texas Instruments, or other such processors. Further still, the one or more processors204may include one or more special-purpose processors, such as a Field-Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC). The one or more processors204may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. Thus, once configured by such software, the one or more processors204become specific machines (or specific components of a machine) uniquely tailored to perform the configured functions and are no longer general-purpose processors.

The one or more communication interfaces202are configured to facilitate communications between the application server112, the client device104, and one or more of the database server(s)124and/or database(s)118-120. The one or more communication interfaces202may include one or more wired interfaces (e.g., an Ethernet interface, Universal Serial Bus (“USB”) interface, a Thunderbolt® interface, etc.), one or more wireless interfaces (e.g., an IEEE 802.11b/g/n interface, a Bluetooth® interface, an IEEE 802.16 interface, etc.), or combination of such wired and wireless interfaces.

The machine-readable medium206includes various modules208and data210for implementing the organizational directory server112. The machine-readable medium206includes one or more devices configured to store instructions and data temporarily or permanently and may include, but is not be limited to, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., Erasable Programmable Read-Only Memory (EEPROM)) and/or any suitable combination thereof. The term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store the modules208and the data210. Accordingly, the machine-readable medium206may be implemented as a single storage apparatus or device, or, alternatively and/or additionally, as a “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices. As shown inFIG. 2, the machine-readable medium206excludes signals per se.

In one embodiment, the modules208are written in a computer-programming and/or scripting language. Examples of such languages include, but are not limited to, C, C++, C#, Java, JavaScript, Perl, PHP, Python, or any other computer programming and/or scripting language now known or later developed.

With reference toFIG. 2, the modules208of the social networking server112include, but are not limited to, a user interface module212, an application module214, an authentication module216, a transformation module218, and interpreter module220. The data210supporting these modules208include, but is not limited to, one or more application documents222(e.g., one or more electronic documents), user credentials224, document metadata226, one or more transformed electronic documents228, the hierarchal permission context structure230, and field specific metadata232.

The user interface module212is configured to provide access to, and interactions with, the application server112. In one embodiment, the user interface module212provides one or more graphical user interfaces, which may be provided using the Hypertext Transfer Protocol (HTTP). The graphical user interfaces are displayable by the client device104and accept input from the user122for interacting with the application server112. Further still, the user interface module212may be configured to provide such interfaces to one or more client applications displayable by the client device104, such as the web client106, one or more client applications108, or the programmatic client110. By interacting with the user interface module212, the user122can cause the application server112to retrieve data from, and push data to, one or more of the databases118-120. In one embodiment, the user interface module212communicates with the application module214and the interpreter module220to provide requested electronic documents to the client device104.

The application module214is configured to provide access to one or more electronic documents (e.g., application documents222) along with the field-level data used to generate these documents. In one embodiment, the application module214acts as an intermediary between the user interface module212, which displays the requested electronic documents, and the one or more databases118-120, which store the data used to generate the electronic documents. Further still, requests for electronic documents may be processed by the application module214to determine whether the user requesting the electronic documents has authorization to view the data used to generate the electronic documents or displayed by the electronic documents. As discussed below with reference toFIG. 3, and in one embodiment, the application module214invokes the authentication module216and/or the transformation module218as the application documents222are being requested by the client device104. In this manner, the application module214is configured to validate that the user requesting the documents is authorized to view the data associated with one or more fields that comprise the requested one or more electronic documents.

The authentication module216is configured to authenticate a user and identify the one or more roles assigned to the user in providing the electronic documents to the client device104. In one embodiment, the user provides one or more user credentials via the client device104to the application server112, which are stored as the user credentials224. In one embodiment, the user credentials224include a username and password, which the user may provide by typing such credentials into an input device (e.g., a keyboard) communicatively coupled, or integrated with, the client device104. Additionally or alternatively, the user credentials224include biometric credentials such as fingerprint data, retina data, voice data, or other such biometric data. Using the provided credentials, the authentication module216confirms that the user is authorized to access the application server112. In one embodiment, the confirmation is performed by comparing previously provided user credentials with the credentials being currently provided by the user. The results of the comparison indicate whether the user122is authorized to access the application server112.

Having authenticated the user122, the authentication module216then determines the one or more roles assigned to the user122. In one embodiment, the authentication module216retrieves a record from the authentication database120corresponding to the user122. More specifically, and as an example, the authentication module216retrieves a field, such as a role field, from the corresponding record that identifies the roles to which the user122is assigned. The authentication module216then cross-references the hierarchical permission context structure230with the role identifier assigned to the user122to determine the permissions that the user122has with respect to the data stored in the application database118. As discussed above, and in one embodiment, the hierarchical permission context structure230is stored as one or more records in the authentication database120where one or more fields of each record identifies parent nodes and/or child nodes for a given record.

The transformation module218is configured to transform one or more of the application documents222given the permissions of the user122determined by the authentication module216. In one embodiment, transforming the one or more application documents222includes removing data from an application document prior to its transmission to the client device104for display to the user122. In another embodiment, transforming the one or more application documents222includes identifying fields for which the user122does not have permission to view and replacing the data for those identified fields with an identifier or message indicating that the user122does not have permission to view the field data. To determine which of the fields the user122may or may not view, the transformation module may retrieve one or more records from the application database118that correspond to the identified fields of the one or more application documents222. The data from the records may then be stored as the field-specific metadata232, which the transformation module218references to determine whether the user122has authorization to view the data associated with a given field.

Additionally or alternatively, the transformation module218may obtain document specific metadata226from the application database118, where the document specific metadata226provides metadata about one or more of the application documents222requested by the client device104. In one embodiment, and like the field-specific metadata232, the application database118includes one or more records that have fields that characterize a corresponding application. In this regard, and in one embodiment, the document specific metadata226includes, but is not limited to, the creator of the application document, the date and/or time the application document was created, the date and/or time the application document whether the application document is publicly viewable, one or more classified levels (if any) assigned to the application document, the application document type, and other such document specific metadata.

Furthermore, and in one embodiment, the transformation module218maintains a list of those fields that have been redacted, and includes such a list in the transmission to the client device104. Application documents that have been processed may be stored as the transformed documents228. In this manner, the client device104receives a list of those fields that the user is not able to view. In one embodiment, such list is used by an application of the client device104to display an identifier or indicator of the field that the user does not have permission to view.

FIG. 3illustrates a block diagram302, according to an example embodiment, illustrating the interactions between the modules208of the application server112and the client device104ofFIG. 1. As shown inFIG. 3, a user of the client device104requests one or more electronic documents (e.g., dynamically-generated webpages, spreadsheets, images, non-webpage documents, etc.) via the user interface module212. The user interface module212, in turn, is communicatively coupled to the interpreter module220for interpreting requests and generating the requested documents. In one embodiment, the interpreter module220is a server-side interpreter such as a PHP interpreter, a Python interpreter, a Ruby interpreter, any other interpreter now known or later developed, or combinations thereof. WhileFIG. 3illustrates that the user interface module212communicates with the interpreter module220, one of ordinary skill in the art will recognize that, in some instances, the user interface module212may communicate with the application module214directly rather than through the interpreter module220. In this regard, any communication pathways illustrated inFIG. 3are meant to illustrate one embodiment; there may be instances where communication pathways are established between different modules (e.g., a direct communication pathway between the authentication module216and transformation module218) and such arrangements are contemplated as falling within the scope of this disclosure.

The application module214is communicatively coupled to the authentication module216and the transformation module218. Accordingly, in one embodiment, when user credentials are provided to the application module214via the user interface module212, the application module214invokes the authentication module216to determine whether the user122is authorized to access the requested electronic documents and/or to determine one or more roles assigned to the user122. Accordingly, and as discussed previously, the authentication module216queries authentication database120with the provided user credentials. In response to the query, the authentication database120returns whether the user is authorized to access the one or more electronic documents and/or the one or more roles assigned to the user122. In addition, the authentication module216may query the authentication database122determine whether the user122is associated with any classified levels, user restrictions, or other such user related permissions. The determination of whether the user122is authorized to access the requested electronic documents and/or the one or more roles assigned to the user122are communicated to the application module214.

As discussed above, the application module214is also communicatively coupled with the transformation module218. In this regard the application module214invokes the transformation module214to redact or remove data from one or more of the electronic documents prior to their transmission to the client device via the interpreter module220and/or the user interface module212. In one embodiment, the application module214communicates the one or more roles assigned to the user122to the transformation module218. More particularly, the application module214communicates one or more role identifiers (e.g., node identifiers) to the transformation module218. In turn, the transformation module218queries the application database118for metadata about the requested electronic documents. In one embodiment, the transformation module218request the metadata for each data field appearing in the requested one or more electronic documents. Using the requested metadata from the application database118, transformation module218determines whether the user122can view the corresponding data for the data fields of the one or more electronic documents. In one embodiment, the requested metadata includes one or more user identifiers and the transformation module218communicates with the authentication module216to retrieve the one or more roles assigned to the user identifiers. In this way, the transformation module218compares the one or more roles assigned to the user122with the roles corresponding to the user identifiers of the metadata from the application database118.

In response to the comparison, the transformation module218determines whether data stored in the application database118is made viewable to the user122of the client device104. As discussed above with regard toFIG. 2, requested electronic documents that have been modified and/or transformed by the transformation module218become transformed documents228. In one embodiment, the transformation module218replaces data for which the user122is not authorized to view with a predetermined identifier or null value that signifies that the user122is not authorized to view the data with a given field. Furthermore, the transformation module218may include a list of the fields for which the user122is not authorized to view. These listed fields may be displayed to the user122via the user interface module212so that the user122is placed on notice that data exists for the listed fields but that the user122does not have sufficient authorization or clearance to view the data for the listed fields.

While the foregoing discussion of the transformation module218focuses on a field level analysis of requested electronic documents, and alternative embodiments, the application database118may also store metadata for one or more of the requested electronic documents. Thus, similar to the metadata for the fields of electronic documents, the electronic documents may also have similar metadata. Accordingly, and in some circumstances, the transformation module218may request the metadata for the electronic documents in determining whether the user122requesting such documents is authorized to view the data associated therewith.

Referring toFIG. 4is a hierarchical permission context structure402according to an example embodiment. As shown inFIG. 4the hierarchical permission context structure402is similar to a logical tree structure having a plurality of nodes404-430with one or more edges connecting the various nodes404-430. In the example shown inFIG. 4, the hierarchical permission context structure402includes a root node404which may correspond to a user role of administrator or superuser having permissions reserved for such role including, but not limited to, creating data, deleting data, modifying data, creating new fields, or otherwise manipulating the one or more electronic documents accessible by the application server112.

As the depth level for the hierarchical permission context structure402increases, the permissions for the nodes at the given depth level may be different than the permissions for the nodes at previous levels. For example, the nodes at higher depth levels may have less permissions than the nodes at lower depth levels. In this regard, nodes406-410may have fewer permissions than the node404. For example, the nodes406-410may have all of the permissions of the note404with the exceptions of such as permissions as being able to delete and/or add records to the application database118. Moving to the next depth level (e.g., the nodes412-420), the nodes412-420at this the depth level may have fewer permissions than the nodes above it. However, in alternative embodiments, the permissions of the nodes406-410may be configurable such that the permissions of the nodes vary. For example, the node406may have different permissions than the node410, and as one example, the node406may have the same, or fewer permissions, than the node410.

Alternatively or additionally, it is possible that, in some configurations of the hierarchical permission context structure402, the permissions assigned to one or more nodes of a given branch do not vary or have minor variations. For example, node406, node412, and the group of nodes422may have similar permissions to the root node404. In this regard, the branch of nodes that includes node406, the node412, and the node group422may be structured as shown inFIG. 4for organizational purposes rather than to substantively change the permissions assigned thereto.

In one embodiment, the nodes of the hierarchical permission context structure402correspond to organizational groupings (e.g., departments, committees, working groups, etc.) of an organization. Furthermore each of the nodes404-430may be associated, or assigned, a unique identifier (e.g., one or more alphanumeric characters) that identifies the corresponding node. In this regard, a record in the authentication database120corresponding to a user has a role field that is populated with one or more of the unique identifiers assigned to the nodes404-430of the hierarchical permission context structure402. Thus, through the association of node identifiers with the records of the authentication database120, users of the application server112may be assigned one or more roles.

Furthermore, a user may be assigned a unique identifier that identifies the user. For example, a field of a record of the authentication database120may store a value representing the unique identifier. Accordingly, and in one embodiment, to determine the roles assigned to a given user, a module of the application server112queries the authentication database120with the user credentials and/or user identifier and, in response, receives the one or more role identifiers assigned to the user. Using the retrieved one or more role identifiers, the module then cross-references the hierarchical permission context structure402to determine the permissions that the user has with regard to one or more fields of the requested electronic document.

Referring toFIG. 5are example records518-524from the application database118ofFIG. 1, according to an example embodiment502. As shown inFIG. 5, the records518-524include one or more fields504-516. In one embodiment, the fields504-516include a “type” field504, a “created by” field506, a “label” field508, a “unique identifier” field510, a “public viewable” field512, a “classified level” field514, and a “value” field516. WhileFIG. 5illustrates that an example record includes fields504-516, one of ordinary skill in the art will recognize that a record may include alternative, fewer, or additional fields. Accordingly, such variations and configurations are contemplated as falling within the scope of this disclosure.

Starting with the “type” field504, this field504indicates the type of data stored by a given record. The types of data storable by the records of the application database118include any type of data displayable or transmittable to the client device104. In some circumstances, the types of data storable by the records of the application database118correspond to those datatypes displayable in a webpage such as text data, numerical data, graphical data, hyperlinks, sound data, form data (e.g., a checkbox, a radio button, a drop-down menu, etc.), or any other type of data displayable in a webpage. As shown inFIG. 5, the field504indicates that the records518-524store data corresponding to text data. Referring next to the “created by” field506, this field506stores a value identifying the user that created the record for the corresponding field. As shown inFIG. 5, the user is identified by a user identifier, and in this case, the user identifier appears as “USERID456.” As discussed previously, a module may use this user identifier to determine the permissions a given user has with respect to the data stored in the “value” field516. In this manner, when another user accesses the application server112, the transformation module218retrieves the one or more roles assigned to the user identifier of “USERID456” and compares the retrieved one or more roles with the roles assigned to the current user. In an alternative embodiment, and as discussed further below, the transformation module218retrieves the one or more roles assigned to the current user identifier and cross-references the permissions assigned to the one or more roles to determine whether the current user has permission to view the data stored in given record.

With reference to the “label” field508, this field508indicates the name of the field that is to appear in an electronic document. In this regard, and as one example, an electronic document that includes a field corresponding to record518would show the words “Market Segment” to indicate the presence of the field corresponding to record518. Similarly, other electronic documents that include fields corresponding to records520-524would include the words “Market Subsegment,” “Patent Number,” and “Platform Type” to indicate the field within their respective electronic document. In this manner, when an electronic document is generated dynamically and includes an identifier referencing a given record, the name of the field represented by the identifier is incorporated into the dynamically generated electronic document.

Next, the “UU ID” field510(or unique identifier field) stores a series of alphanumeric characters that uniquely identify a corresponding field and/or record. In this regard, should an electronic document include the unique identifier (e.g., the UU ID) unique identifier may be replaced with one or more portions of the corresponding record, such as the text data in the “label” field508or the value of the field stored in the “value” field516of the corresponding record.

The next two fields512-514(e.g. the “publicviewable” field512and the “classified level” field514) indicate, respectively, whether a given record is publicly viewable to all users of the application server112and any classified level required to view the data of a given record. As shown inFIG. 5, the records518,520,524are publicly viewable as indicated by the Boolean value of “TRUE” stored in the “publicviewable” field512of the records518,520,524. Accordingly, and in this example, any authorized user of the application server112may view the data stored in the “value” field516of records518,520,524. As a different example, the record522is not publicly viewable as indicated by the Boolean value of “FALSE” stored in the “publicviewable” field512. Accordingly, in this alternative example, a user that desires to view the data stored in the “value” field516of the record522would need to be assigned one or more roles that has permissions to view such data. As discussed below, where a user does not have such permissions, the user may be presented with a predetermined value or identifier indicating that he or she does not have authorization to view the data stored in the “value” field516. Referring to the “classified level” field514

Finally, and with reference to the “value” field516, this field516stores the value to be displayed with, or incorporated into, the requested one or more electronic documents. As shown inFIG. 5, the data stored in the “value” field516for each of the records518-524is text data, where the value data for the record518is “SEGMENT A,” the value data for the record520is “SUB-SEGMENT 1,” the value data for the record522is “1234567,” and the value data for the record524is “PLATFORM B.” While the value data for each of the records518-524is text data, other types of data may be used as value data for the records518-524. For example, the value data may include image data, a hyperlink to an electronic file (e.g., an image file, a sound file, a text-based file, etc.), sound data, video data, or any other types of data. As discussed, where the user122is authorized to view the value data, the value data is included in the requested one or more electronic documents. However, where the user122is not authorized to view the value data, the transformation module218replaces the value data with a previously determined value or identifier to signify that the user122is not authorized to view the value data. In one embodiment, where the value data from one or more of the records518-520is replaced, the transformation module218communicates the replaced value data to the application module214and/or the interpreter module220, which then dynamically generates the requested electronic documents using the replaced value data rather than the value data from the one or more records518-520. In this manner, the user122is made aware that a value exists for a given field (e.g., the “Patent Number” field, corresponding to record522), but is not provided with the value of the given field.

FIG. 6illustrates an example graphical user interface602, according to an example embodiment, for interacting with an application provided by the application server ofFIG. 1. In one embodiment, the graphical user interface602is displayed by one or more of the applications of the client device104, such as the web client106, client application(s)108, or the programmatic client110. As shown inFIG. 6, a first user604has accessed an application provided by the application server112. In one embodiment, the application server112, via the user interface module212and the application module214, dynamically generates an electronic document from data stored in the application database118. Accordingly, the graphical user interface602displays an electronic document showing information about various fields retrieved from the application database118. With reference toFIG. 5, such fields may include the “Market Segment” field (e.g., record518), the “Market Subsegment” field (e.g., record520), the “Patent Number” field (e.g. record522), and the “Platform Type” field (e.g., record524).

As shown inFIG. 6, a second user606, different than the first user604, has created the electronic document displayed in the graphical user interface602. Furthermore, the second user606may be responsible for providing the data values for the various records used to generate the displayed electronic document. Accordingly, to determine whether the first user604is authorized to view the data displayable by the electronic document, the transformation module218compares the permissions of the one or more roles assigned to the first user604with the roles authorized to view of the data displayable in the electronic document. In one embodiment, the determination is performed by comparing the roles of the first user604the roles assigned to the second user606(or the user having created one or more of the fields displayable in an electronic document). In another embodiment, the determination is performed by identifying the one or more roles assigned to the first and retrieving the permissions of such roles with respect to each of the fields displayable in an electronic document. As explained above, the permissions for the one or more roles may be identified by referencing the hierarchical permission context structure402.

InFIG. 6, the transformation module218has determined that the first user604is authorized to view the field data of the “Patent Number” field. Thus, as shown inFIG. 6, and with reference toFIG. 5, the data value608from the “value” field516is displayed to the user122via the graphical user interface602. However, as discussed below with regard toFIG. 7, depending on the permissions assigned to the one or more roles of the user122, the data value608may not be displayed.

FIG. 7illustrates another example graphical user interface702, according to an example embodiment, for interacting with the application provided by the application server ofFIG. 1. InFIG. 7, a third user704has accessed the application provided by the application module214and displayable by the user interface module212. However, and with reference toFIG. 5, the third user704has different permissions than either the first user604or the second user606. In particular, the third user704is not authorized (e.g., does not have the permissions) to view the data stored in the “value” field516of the record522corresponding to the “Patent Number” field. Accordingly, the transformation module218replaces the data of the “value” field516with a previously determined identifier that conveys to the third user704that he or she is not authorized to view the replaced data. However, the third user704is still made aware that data exists for the “Patent Number” field because such field is included in the dynamic generation of the electronic documents displayed by the user interface module212. In this manner, unauthorized users are prevented from viewing restricted or classified fields but they are still made aware that such data exists. This allows the unauthorized users to seek out those who are authorized and to obtain the restricted data from them.

FIGS. 8A-8Dillustrate a method802, according to an example embodiment, for dynamic runtime field-level access control using the hierarchical permission context structure ofFIG. 4. With reference toFIG. 2, the method802may be implemented by any one of the modules208and is described by way of reference thereto. Initially, the application server112, via the user interface module212and/or the application module214, receives a request to access a web application (Operation804). In one embodiment, user credentials, such as a username and password, are provided with the request (Operation806). Alternatively and/or additionally, the application module214may request that the user122provide such credentials before being granted access to the application provided by the application module214. As discussed above, user credentials may also include biometric credentials, such as fingerprint data, retina data, voice data, or any other such biometric credentials now known or later developed.

With the received user credentials, the authentication module216then determines the one or more user roles associated with the user identified by the provided user credentials (Operation808). As explained previously, and in one embodiment, the authentication module216queries the authentication database122to obtain the one or more user roles. Provided that the user is authenticated, the authentication module216then instructs the application module214to provide access to the web application hosted by, or provided by, the application server112(Operation810). The application server112then waits for the client device104to provide a request for one or more electronic documents accessible via a web application (Operation812).

Referring next toFIG. 8B, the transformation module218and/or the application module214then determines the various data fields to be included in the requested one or more electronic documents (Operation814). As explained above, the requested electronic documents may be generated dynamically via an interpreter module220, which retrieves data from one or more “value” fields from corresponding records stored in the application database118. The transformation module218may leverage the interpreter module220to identify those fields that are dynamically populated with the data in the generation of the one or more requested electronic documents.

In determining whether a user is authorized to view the data for a given field, the transformation module218may engage in one or more operations as described below. Initially, the transformation module218selects a first identified field (Operation816). The transformation module218then queries the application database118to determine whether the first identified field is a secured field (Operation818). In one embodiment, a secured field is a field where the Boolean value in the “publicviewable” field in the record corresponding to the first identified field is “FALSE.” In this embodiment, and as one of ordinary skill in the art will recognize, an unsecured field is a field where the Boolean value in the “publicviewable” field is “TRUE.” In this manner, where the first identified field is determined as being an unsecured field (e.g., “No” branch of Operation818), the method802then proceeds to Operation828, discussed further below. However, where the first identified field is determined as being a secured field (e.g., “Yes” branch of Operation818), the method802then proceeds to Operation820.

At Operation820, the transformation module218determines whether the user is assigned one or more predetermined roles, such as an administrative role. This determination is performed because, if the field is a secured field, an administrator should be able to view the data of the secured field. In one embodiment, and as discussed above, the transformation module218determines the one or more roles assigned to the user by querying the authentication database120, which returns the one or more roles assigned to the user. The authentication database120may return one or more node identifiers, which the transformation module218may cross reference with the hierarchical permission context structure230to determine the permissions assigned to the user.

If this if the user is determined not to be an administrator (e.g. “No” branch of Operation820), then the method802proceeds to Operation828. In contrast, if the user is determined to be an administrator (e.g. “Yes” branch of Operation820), then the method802proceeds to Operation822.

At Operation822the transformation module212determines whether the requested electronic document is a secured document (e.g., an electronic document that is not publicly viewable). In one embodiment, this determination is made by querying the application database118and retrieving metadata from a record corresponding to the requested electronic document. Similar to the records illustrated inFIG. 5, the record corresponding to the requested electronic document may also have similar fields. Thus, and in one embodiment, the record corresponding to the requested electronic document has a “publicviewable” field. The transformation module212then determines whether the Boolean value stored in the “publicviewable” field is “TRUE” or “FALSE.” Where the Boolean value is “TRUE,” the method802proceeds to Operation828; where the Boolean value is “FALSE,” the method802then proceeds to Operation824.

Referring toFIG. 8C, the transformation module212next determines whether the user requesting the electronic document is the owner of the data stored in the “value” field of the record corresponding to the field being analyzed (Operation824). With reference toFIG. 5, and in one embodiment, this determination is made by referencing the “createdby” field506of the record corresponding to the field being analyzed. As the user accessing the web application may be assigned a user identifier, the transformation module212compares this user identifier with the user identifier listed in the “createdby” field506. Where the transformation module212determines that the accessing user is the data owner (e.g., “Yes” branch of Operation824), the method802proceeds to Operation828. Alternatively, where the transformation module212determines that the accessing user is not the data owner (e.g., “No” branch of Operation824), the method802proceeds to Operation826.

At Operation826, the transformation module212determines whether the accessing user is authorized to view the data of the field being analyzed. In this regard, the transformation module212may determine whether the one or more roles assigned to the user correspond to one or more roles assigned to the data owner (e.g., the user identified in the “createdby” field). Alternatively, the transformation module212may reference the hierarchical permission context structure230to determine whether the one or more roles assigned to the user has a permission to view the field being analyzed. In one embodiment, the permission is specific to the field being analyzed. In alternative embodiments, the permission corresponds to the type of field being analyzed. In further embodiments, the permission corresponds to the UUID assigned to the field being analyzed. In this way, a single permission may apply to multiple fields displayable within the requested one or more electronic documents (e.g., a one-to-many relationship between a permission and applicable fields).

Should any of the foregoing decisions be answered in the affirmative (e.g., the “Yes” branch of Operations818-826), the method proceeds to Operation828. At Operation828, the transformation module212signals to the application module214that the data for the field being analyzed can be displayed in the requested electronic document. Accordingly, the application module214retrieves the data stored in the “value” field for the record corresponding to the field being analyzed. This data may then be communicated to the interpreter module220, which dynamically generates the requested one or more electronic documents for display via the user interface module212. The method802then proceeds to Operation834ofFIG. 8D, which is discussed further below.

However, should the foregoing decisions each be answered in the negative, the method802proceeds to Operation830. At Operation830, the transformation module212communicates a predetermined restriction identifier to the application module214to be displayed instead of the data stored in the “value” field of the record corresponding to the field being analyzed. In addition, the transformation module212then adds the field being analyzed to a restricted field list (Operation832), which is also communicated to the application module214. Thus, when the requested electronic document is generated by the application module214and/or the interpreter module220, the client device104displays an electronic document with the predetermined restriction identifier and, in some embodiments, a list of the restricted fields determined by the transformation module212.

Referring next toFIG. 8D, the transformation module212then determines whether there are remaining fields to be analyzed in the requested one or more electronic documents (Operation834). If this decision is determined in the affirmative (e.g., “Yes” branch of Operation834), the transformation module212then selects the next field in the requested one or more electronic documents for analysis (Operation836). The method802then returns to Operation818ofFIG. 8B.

Alternatively, if there are no fields remaining to be analyzed (e.g., “No” branch of Operation834), the transformation module212incorporates the restricted field list into the one or more electronic documents being provided to the client device104(Operation838). As discussed above, the application module214and/or the interpreter module220then provides the requested one or more electronic documents to the client device104with the restricted field list (Operation840).

In this way, the disclosed systems and methods provide a mechanism in which sensitive data is made available to authorized users, but also in which users who are not authorized are made aware that such data exists. The technical benefit of such systems is that the analysis is done at run-time through the dynamic generation of data and that separate electronic documents for individual users are not needed. Thus, different users having different sets of permissions may each view different sets of data for a given electronic document. Furthermore, as the disclosed systems and methods leverage a hierarchical context permission structure, individual users need not be assigned permissions for specific fields. Rather, such permissions are determined from the one or more roles assigned to a given user. Thus, a further technical benefit is that permission management of users is made simpler and far more easier to manage than if each user were assigned permissions for specific fields.

Modules, Components, and Logic

Machine and Software Architecture

The modules, methods, applications and so forth described in conjunction withFIGS. 1-8Dare implemented in some embodiments in the context of a machine and an associated software architecture. The sections below describe a representative architecture that is suitable for use with the disclosed embodiments.

Example Machine Architecture and Machine-Readable Medium

The machine900may include processors910, memory930, and I/O components950, which may be configured to communicate with each other such as via a bus902. In an example embodiment, the processors910(e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Radio-Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor912and processor914that may execute instructions916. The term “processor” is intended to include multi-core processor that may comprise two or more independent processors (sometimes referred to as “cores”) that may execute instructions contemporaneously. AlthoughFIG. 9shows multiple processors, the machine900may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core process), multiple processors with a single core, multiple processors with multiples cores, or any combination thereof.

The memory/storage930may include a memory932, such as a main memory, or other memory storage, and a storage unit936, both accessible to the processors910such as via the bus902. The storage unit936and memory932store the instructions916embodying any one or more of the methodologies or functions described herein. The instructions916may also reside, completely or partially, within the memory932, within the storage unit936, within at least one of the processors910(e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine900. Accordingly, the memory932, the storage unit936, and the memory of processors910are examples of machine-readable media.

Communication may be implemented using a wide variety of technologies. The I/O components950may include communication components964operable to couple the machine900to a network980or devices970via coupling982and coupling972respectively. For example, the communication components964may include a network interface component or other suitable device to interface with the network980. In further examples, communication components964may include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices970may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a Universal Serial Bus (USB)).

Transmission Medium

The instructions916may be transmitted or received over the network980using a transmission medium via a network interface device (e.g., a network interface component included in the communication components964) and utilizing any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). Similarly, the instructions916may be transmitted or received using a transmission medium via the coupling972(e.g., a peer-to-peer coupling) to devices970. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions916for execution by the machine900, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

Language