HK1118350A - Architecture for computer-implemented authentication and authorization - Google Patents

Description

Computer-implemented authentication and authorization architecture

Technical Field

The present invention relates to a computer implemented method and system for controlling access and authorization rights associated with enterprise data, applications and other objects via a user authorization level.

Background

Typically, control of user rights to access enterprise data and/or other electronic resources (data and programs with different privileges and access rights, including all sub-parts) all relies on user authentication (verifying user identification to ensure that a person or machine is consistent with a claim). There are a number of ways of secure authentication including passwords, smart cards, certificates, and even biometrics such as retinal scans or voice recognition. Among these, the use of certificates and digital signatures, smart cards, and biometrics is referred to as a "strong" security level, while ordinary password-protected access is considered "weak" by typical financial institutions and security experts. While current authentication protocols are robust and allow little or no ambiguity, authentication alone is not sufficient to define and enforce the rights that everyone has with respect to these resources. Instead, the authorizations are not handled well enough to prevent the applications from frequently conflicting with each other or working for the opposite purpose, which is for a particular user authorization in relation to the corporate security agreement of particular data or other program resources.

Furthermore, the authorization level of the user is not static. Typically, these authorization levels change as a result of promotion, demotion, suspension, or termination, or the "need to know" of employees working in a particular project. Authentication and authorization are not only important in payment authorization or in the context of making a contract (contract) to constrain a company. In fact, the increasingly burdensome day-to-day access to data, programs, or other electronic resources should follow the role and hierarchical position of the user at the company. That is, companies often wish to limit access to data resources selected for a predetermined user or a predetermined level of users. For example, a user who may have a legitimate need to access data relating to a line or customer assigned to him may not have a legitimate need to access data relating to a line and/or customer that is outside of his sphere of responsibility. Moreover, even a properly authenticated user who may have a reasonable need to access a particular data resource may only have a reasonable interest (interest) in viewing the data, and may not have a corresponding reasonable interest in entering new data or changing existing data. Finally, a single user may have various attributes, such as either long tenure or short term with the company, which may result in the company's security agreement requiring different authorization levels. A very important example is a security check, which may not be inferred from other authorization element values.

What is needed, therefore, is a method and system for ensuring strong authorization. In particular, what is needed is a method and system that ensures, in accordance with corporate security protocols, that those seeking access to these electronic resources are in fact authorized to initiate these activities and access these resources, and that these accesses are appropriate. Also needed are strong and quantifiable (qualified) authorization methods and systems operable in distributed network computing environments.

Disclosure of Invention

According to one embodiment thereof, the present invention is a computer-implemented method for controlling access to secured data resources. The method may comprise the steps of: storing (inventorying) data resources to be secured; generating a requirements data structure comprising one element mapped to each inventoried data resource, each element configured to store a requirement value set according to an authorization level required to access the mapped data resource; for each user having access to any of the inventoried data resources, defining and storing an authorization data structure comprising one element mapped to each of the plurality of data resources, each element configured to store an authorization value set in accordance with an authorization granted to the user to access the mapped data resource; receiving a user request to access at least one secure data resource; the grant and requirements data structures are compared and access to any secured data resource in the received user request that maps to any element in the requirements data structure having a requirement value greater than the grant value of the corresponding element in the grant data structure is not allowed.

The comparing step may include the step of clearing (pruning) the grant and requirements data structure to include only elements mapped to the inventoried data resources requested to be accessed by the user request. The method may include the step of allowing access in a received user request to any secured data resource mapped to any element in the requirements data structure having a requirement value less than or equal to the grant value of the corresponding element in the grant data structure. The receiving step may be performed by a user request including a database query. The disallowing access step may include a step of disallowing compilation and execution of the database query. The receiving step may be performed by a user request comprising an SQL query. The defining and generating steps may be performed by an authorization and requirements data structure that includes a user identification field configured to store a value uniquely identifying the user. The comparing step may include the step of obtaining an authorization data structure including a subscriber identification field having a value that matches the value of the subscriber identification field in the generated requirements data structure. The comparing step may include disallowing execution of the received user request unless the grant binary number collectively formed by the values of the grant data structure elements is greater than the request binary number collectively formed by the values of the requirements data structure elements. A step may be performed to determine which element of the requirements data structure has a value less than the corresponding element of the grant data structure. The determining step may include the step of performing an XOR operation on the values of the elements in the requirements data structure and the values of the corresponding elements in the grant data structure. A logging step may also be performed to log instances that are not allowed to access any data structure. A step may also be performed to generate a message to request greater authorization when access to the secured data resource is not allowed. The method may further comprise the step of updating the value of a selected element in the grant data structure when the message requesting greater grant is answered to grant greater grant in relation to the selected element. The secure data resources may include at least one of a data structure and an application. The defining and storing steps may be performed by describing the authorization data structure in Directory Services Markup Language (DSML) form and by entering the authorization data structure as user data in the user's digital certificate.

According to another embodiment thereof, the present invention is a computer system including a database storing a plurality of secured data resources to which user access is controlled. The computer system may include at least one processor; the at least one processor generates (spawned) a plurality of processes, the processes comprising processing logic to: storing (inventorying) data resources to be secured; generating a requirements data structure comprising one element mapped to each inventoried data resource, each element configured to store a requirement value set according to an authorization level required to access the mapped data resource; for each user having access to any of the inventoried data resources, defining and storing an authorization data structure comprising one element mapped to each of the plurality of data resources, each element configured to store an authorization value set in accordance with an authorization granted to the user to access the mapped data resource; receiving a user request to access at least one secure data resource; the grant and requirements data structures are compared and access to any secured data resource in the received user request that maps to any element in the requirements data structure having a requirement value greater than the grant value of the corresponding element in the grant data structure is not allowed.

The invention may also be viewed as a machine-readable medium having stored thereon data representing sequences of instructions which, when executed by a computing device, cause the computing device to control user access to a plurality of secured data resources by performing the steps of: storing (inventorying) data resources to be secured; generating a requirements data structure comprising one element mapped to each inventoried data resource, each element configured to store a requirement value set according to an authorization level required to access the mapped data resource; for each user having access to any of the inventoried data resources, defining and storing an authorization data structure comprising one element mapped to each of the plurality of data resources, each element configured to store an authorization value set in accordance with an authorization granted to the user to access the mapped data resource; receiving a user request to access at least one secure data resource; the grant and requirements data structures are compared and access to any secured data resource in the received user request that maps to any element in the requirements data structure having a requirement value greater than the grant value of the corresponding element in the grant data structure is not allowed.

According to another embodiment thereof, the present invention is a computer-implemented method of controlling user access to enterprise data resources. The method may comprise the steps of: storing (inventorying) data resources to be secured; assigning a requirement value for each inventoried data resource that defines an authorization level required to access the data resource; storing the demand value for each of the inventoried data resources in a demand data structure; defining, for each user having access to any of the inventoried data resources, a grant data structure including a grant value for each of the inventoried data resources, each grant value determining whether the user is allowed to access the corresponding secure data resource, and when a request from the user to access one of the inventoried data resources is received, comparing the demand data structure and the user's grant data structure and allowing the access request to be performed only when the grant value for accessing the requested data resource is at least as great as the corresponding demand value.

The method may further include the step of enabling the selected user to define and assign the assigned authorization data structure to a lower ranked user in the enterprise, the defined and assigned authorization data structure storing an authorization value that is no greater than an authorization value of the authorization data structure of the user defining and assigning the assigned authorization data structure. The enabling step may be performed such that each grant value of the grant data structure for each user is not greater than a corresponding grant value of the grant data structure assigned to a hierarchically higher user. The method may further include the step of granting the user a request for an increased authorization level to access the selected data resource and correspondingly increasing the authorization value of the selected data resource in the authorization data structure of the requesting user. A step of deleting the user authorization data structure may also be performed when the user leaves the enterprise. The authorization value of each user's authorization data structure may initially default to a lowest value representing the lowest possible authorization level and the authorization data structure of each element may be reset manually, optionally, or automatically upon the occurrence of an event (e.g., promotion) specified by an administrator or indicated by a corporate security protocol.

Drawings

FIG. 1 is a flow diagram of aspects of a method performed by a computer to control access to secured data resources, according to an embodiment of the invention.

FIG. 2 is a flow diagram representing steps that may be performed to allow query execution or deny query execution according to an embodiment of the invention.

FIG. 3 shows additional and expanded steps that may be performed to control access to secured data resources, according to an embodiment of the invention.

FIG. 4 illustrates an exemplary security data structure underlying the GSDS and RSDS data structures according to the following "working Example" (Worked Example) and according to an embodiment of the present invention.

FIG. 5 is a block diagram of an exemplary computer on which embodiments of the present invention may be implemented.

Detailed Description

An embodiment of the computer of the present invention that performs the method to define, protect and control access to secured data resources may comprise five modules: an initial (setup) resource storage module, an initial authorization module, an SQL compilation module, a core function module, and an upgrade and update module. These modules span (span) the functions described below: various databases are set up and populated (populating) to enable or prevent users from performing SQL (or other structured) queries or other requests to access secure data resources, depending on whether they are authenticated and fully authorized.

According to embodiments of the present invention, when a user is denied access or other privileges with respect to a secured data resource or program, such denial is interpreted as a result of the user not being granted sufficient privileges or authorization to access the secured data resource that is the target of its SQL query or other request to access the data resource. According to embodiments of the present invention, a user may be given the opportunity to send a message to his or her administrator when the user query is prevented from executing because there are not enough permissions associated with the secured data resources to be accessed by the SQL query. Such a message (e.g., as an email, or other form of electronic message) may be automatically formatted and may indicate the particular requested access privileges, the current level of user access privileges currently maintained in relation to the secured data resource to be accessed, and the level of access privileges required to satisfy the user's SQL query. Messages may also be generated automatically and independently of the user to prompt his or her administrator or some designated (preferably more highly ranked) person of the persons attempting to access the secured data resource. According to an embodiment of the present invention, all user attempted actions related to Relational Database Management Systems (RDBMs) are understood as SQL or similar structured statements. Any statements or functions written in any programming language or script/other script can be stored in (e.g., Oracle corporation) RDBMs and their use safely controlled.

Thereafter, if the administrator has sufficient access privileges, the administrator may specify or grant the additional access privileges requested and the user may be given the opportunity to query again, this time with a successful prospect. According to embodiments of the present invention, a user can only specify or grant access privileges equal to or less than the set of privileges granted thereto. In this manner, no user may grant or specify a secure data resource access privilege greater than the access privilege currently specified to him. According to the present invention, a user may cause a query to be executed only if the user is found to have access privileges equal to or greater than those required to execute the specified query.

Architectures, methods, and systems suitable for establishing control over, and access to, data resources are described in detail below. The phrase "secure data resource," as used herein, is intended to include all data, databases, files, programs, applications, and other items to which access, execute, and other privileges employing SQL (example) commands are controlled. Initial resource storage, initial authorization, SQL compilation, core functionality, and upgrade and update modules are described below generally in their order of execution.

Initial resource storage

The initial resource storage module 102 may be configured to record all secure data resources and store access privilege levels required to access the stored secure data resources. The secure data resources and the respective access privilege levels (or permissions, these two terms being used interchangeably herein) may be stored in a secure data resource database, as shown at 104 in FIG. 1. Once generated, the store may serve as a framework to which a Security Data Structure (SDS) may be attached. An exemplary SDS is shown in fig. 4 at reference numeral 400.

According to embodiments of the present invention, each user desiring access to the secured data resources may be provided with a unique identification number, for example, 64 bits. As shown, SDS400 may include (1) a dummy element that holds the USER _ ID 412 of the authenticated USER. The dummy element may occupy the least significant position of the SDS 400. SDS400 may also include (2) all elements of SDS400 that are needed to map to corporate security protocols, including one element of each secure data resource for security authorization, and (3) all bits, nibbles (nibbles), or bytes that may be needed to represent values stored in each SDS element. Each element 402 of the SDS400 may be identified by an element identifier (a-n in the example shown in fig. 4). For example, the access privileges required to access element e in SDS400 may be represented and stored by a single bit. For example, an authenticated user may have either sufficient access privileges to access the secure data resource corresponding to element e, or the user may not. Thus, the size 406 of element e may be 1 bit, which is sufficient to represent two values of 406; i.e., authorized (e-1) or unauthorized (e-1). The SDS400 may also include a brief description of each element as shown at 404. In this example, if the value of the element is "0," the user is not authorized to access the secure data resource mapped to element e. Conversely, if the value of the element is "1," the authenticated user is indeed authorized to access the secured data resource mapped to element e. According to an embodiment of the present invention, a user may access a secure data resource corresponding to element e if the user is determined to have an access privilege for element e that is at least as great as the access privilege required to access element e. If the user is determined not to have access privileges for element e that are at least as great as the access privileges required to access element e, the user may not be able to access (or may not be granted access to) the secured data resource corresponding to element e. That is, an SQL query attempting to access a secure data resource corresponding to element e will only be allowed to compile and execute if the user's access privileges to that element are at least as great as the access privileges stored for that element in the secure resource database 104. The user's access privileges must meet the access requirements of each query or the user query will be denied execution. This allows very good control over access to secure data resources.

Because of the potentially large number of secure data resources, the SDS400 may be configured to include a correspondingly large number of elements, possibly storing access privileges at one or more bits of each element. Note that elements may differ greatly in size. For example, access privileges stored in such an SDS400 may be defined by configuring (exploiting) the Human Resources (HR) department of the company. These access privileges reflect what the HR manager knows about to the employee person and the criteria and value specified by the HR. HR is also a general manager of corporate base rules related to contractors, contractor employees, subcontractors, partners, partner employees, suppliers, supplier employees, and all who may need reasonable access to a subset of tightly controlled corporate secure data resources. All of these people may require access privileges to one or more secured data resources that are stored, and all require basic access privileges granted by the HR to the company secured data resources or have any appropriate portion of sufficient access privileges that one person cannot grant more privileges than one person now owns.

For example, the HR and/or legal department may determine the status of any authenticated individual and the access privileges to secured data resources resulting from that status. Then, the administrator responsible for each authenticated person may transfer a subset of their own access privileges to those who report to them once the HR determines that the status of those persons is employee, contractor, or otherwise.

The HR may also have the right to protect its own data. The administrator of the resource will decide to access privileges and specify storage elements and values to implement their part in the overall corporate security model, either directly or through extended approved methods.

For example, access privileges or rights may be defined according to a security check level (e.g., restricted issue 1, secret 2, highest secret 3, restricted to executors (Executive Eyes Only) 4). However, in each instance, the binary number storing the access privileges of each element should indicate the hierarchical order of the access privileges such that a higher (for example) number indicates a higher order privilege, linked or mapped to the secure data resource specified by the element. Note that multiple secured data resources may be accessed by multiple different applications, and the access privileges suggested or specified by these applications or different administrators may be different. It is therefore important that the access privileges of such secured data resources, which may be accessed by a plurality of applications, are set to a highest level required by any of the plurality of applications to prevent a user purchasing an application from accessing a predetermined secured data resource using less than required access privileges. The application of the invention described herein incorporates this principle.

If applicable, the criteria are implemented here such that the products of the criteria can be described as binary numbers in the designated and assigned elements 402. If not feasible, all of the necessary information required by the standard must be available when the user sends an SQL command so that the SQL compiler can generate the appropriate binary numbers to input to the elements in the query.

At this time, the initial resource storage module 102 has acquired the required access privilege level of each of the plurality of elements corresponding to each of the plurality of secure data elements whose access is controlled, and which is required for each user having access to the secure data resource. The Oracle Registration Facility (ORF), available from the assignee of the present invention, may be used (but is not required) by the data resource owner as a tool to add elements and values to the particular secured data resources that are protected in the secured resource database 104. The SDS, as well as the dummy user ID elements, may be represented as a binary number or bit string of known structure of elements of different sizes, as shown at 400 in fig. 4. The USER _ ID may also be appended to all SDS structures, such as the GSDS and RSDS (discussed below) included.

The question of how many bits in an SDS bit string may be handled is at least partially set forth in volume 2A of the IA-32 intel architecture software developer manual: the instruction set is set forth with reference to a-M. Pages 3 through 7, among others, record "bit (base, offset)". return the value of one bit in a bit string, which is a sequence of bits in a memory or register.. if the base is a memory address, the offset can range from-2 Gbits to +2 Gbits ". In short, a bit string or bit strings may occupy (takeup) the available empty memory. The programmer may declare an integer set to protect the necessary memory and then initialize the SDS structure as appropriate. Setting a single bit in the format of a given SDS structure 300 is not a difficult proposition, and equal grant (GSDS, discussed herein below) will allow the same access to memory. The size of 2 Gbits should be understood as the largest possible size of an unsigned bit string, even though it is feasible to use all the memory available during execution.

The available size of 2 Gbits is large enough that it can hold exactly 2,000,000,000 total elements, one bit each, or 2 x 1000. However, with such a capacity of 250 megabytes of memory allocated, each structure may only occupy a small portion of the available memory in even a less powerful desktop computer. Furthermore, the memory allocated to the SDS structure and the comparison operation (also discussed herein below) may be easily released when the comparison result is processed. The same reasoning for the maximum extent of the bit string can also be applied to the grant structure (GSDS) described below. Note also that the mechanism described below may include a shortened subset of the full SDS: the resource SDS (hereinafter RSDS) may be configured to contain bit values corresponding to each element of all secure data resources or may be configured to contain only the actually evaluated resources to be secured that are requested by the user in the SQL query and discovered by the compiler function, which is a more economical proposition in terms of memory usage.

Initial authorization

Since each data resource that needs to be controlled has been stored and assigned a location and value in the SDS structure, access rights to those stored secured data resources may be selectively granted to the user. Returning now to FIG. 1, the initial authorization module 106 participates in processing a list of people who have access and operational privileges or rights with respect to the secured data resources stored by the module 102 and stored in the secured resources database 104. In the initial authorization module 106, the RSDS structure in the form shown in the example of fig. 4 is copied and its constituent elements 302 default to zero. The reason for this is to set the default value of the access grant as low as possible compared to the preferred default as high as possible access requirement. In this way, before the access grant and operation privilege are set, the grant SDS or GSDS is set to 0 by default whereas the access grant and operation privilege requirements of each element are set to a maximum value. These values may then be varied according to the desired level of access for each element and the level of access to be granted to each user for accessing the secured data resources. The GSDS structure representing access privileges has the same data structure and elements (although the element values are not required), which allows the RSDS and GSDS to be easily compared to one another to determine whether a particular authenticated user will be authorized to access a particular secure data resource.

The initial authorization module 106 may be configured to collect and/or receive basic information from the HR regarding the employee's employment status, identity level, and permissions related to secure data resources. The initial authorization module 106 may be configured to generate a GSDS for each person having access to any one of the secure data resources. The GSDS of each person having such an access right has the same structure as shown in fig. 4, and bit values of the respective elements are appropriately set according to the access right of the person. Each person's GSDS will include that person's USER _ ID in the least significant portion of the GSDS structure.

To set such access privileges, the HR authority (for example) may grant privileges to the resources it controls, and it may also enter security rules according to its privileges. The next step may be that each supervisor of a person who has access to any one of the secured data resources (all employees have such a supervisor, possibly in addition to the CEO) grants a particular privilege level to each person who reports to him or her, optionally following an approval step from the supervisor's supervisor, the company's security officer, the HR, or any auditing agent of the company's choice. This feature attempts to allow privilege assignments to be viewed in a manner deemed appropriate by the configuration company.

The use of models or templates can make the assignment of access rights to individuals receiving authorization from their administrators very fast. Such a model or template may be used by an administrator to assign a particular set of permissions (a subset of the permissions they possess) to his or her reporter for a secure data resource. At the end of this process, all employees or other authenticated individuals having any level of access to the secured data resources will be assigned a particular privilege level on the respective GSDS element consistent with their location at the company and/or consistent with their scope of responsibility at the company. Corporate policies may determine whether a second level administrator needs to approve some or all of the authorization from the first level administrator. The value of the personal independent element defaults to 0, meaning that it is inaccessible. In this manner, each person's GSDS enables employees to access only those secure data resources that are needed to complete the employee's work or contractual tasks. Similar integrated controls are equally applicable to contractors and their employees and partners and their employees, as well as suppliers and customers and their employees, who have access to any company's secured data resources.

The end result of all administrators using such modules as a tool to grant privileges would be a GSDS structure, with all appropriate elements assigned values that represent the privilege level of a particular authenticated person. The GSDS of the authenticated person may be described in the form of Directory Services Markup Language (DSML) and entered as user data into the certificate of the authenticated person. GSDS DSML may be stored, for example, in a database of an Oracle application server, and it may be stored in an Oracle security server.

In this way, the configuration company may fully specify the access rights of all authenticated personnel having any access rights to any company secure data resources and may store these access rights in each such personnel's respective GSDS. This allows the individual's GSDS to be compared to the resource security requirements described in the RSDS. In each case, the administrator, being the putative resource owner (with approval of other personnel of the company required by the company policies and procedures), should specify the user ID and their GSDS for the certificate-bearing personnel. The next module describes the functionality of responding to a user's SQL query after the user has logged in with a certificate (e.g., public key infrastructure or PKI). The certificate number (including, for example, the USER ID) can now be imported to the least significant position of the RSDS and GSDS.

Note also that additions to the secure resource database 104 (i.e., additions to the secured data resources being accessed for control) may need to be returned to the original resource storage module 102 to record the secured data resources in the secure resource database 104. Also required may be modification of the user or user GSDS to add elements corresponding to the newly added secure data resources. The initial authorization module 106 may then be awakened to appropriately set the bit values of the elements corresponding to the newly added secured data resources for each user's GSDS. In normal use (e.g., a user describes an SQL query against a secure data resource, as shown at 110 in fig. 1), the initial resource store module 102 and the initial authorization module 106 may not be used (although the authorization database 108 may be used). Again, the default privileges of any user in relation to any new additions to the secure storage default to zero or inaccessible.

SQL precompilation

The functionality of the pre-compiler module 112 includes parsing and scanning of queries requested by users or session-level series of queries or access requests and selecting secure data resources needed to execute the queries and establishing an RSDS for the queries. Note that the element bit value in the RSDS will always default to a maximum number consistent with the element size, while the default user authorization is zero. Thus, the default bit value corresponding to an element identifier having a size of two bits will be "11" and the default bit value corresponding to an element identifier having a size of one bit will be "1". This locks anyone who does not have the highest available privilege if an element is not assigned the bit value of a particular digit for unexpected or other reasons.

One important function of the pre-compiler module 112 is to (1) concatenate the particular SQL secure data resource invoked from the cumulative query of the session with the element identifier and the bit value corresponding to the element identifier representing the security authorization level of that secure data resource (and any significant security subset or related rules thereof), (2) write the particular bit value to the RSDS structure so that the core function module 114 (described below) can properly test the authorization privileges of the authenticated user according to the user's own GSDS structure, and (3) always support and execute the highest value of any authorized source from the particular bit value corresponding to any element identifier when repeated and unequal security requests from multiple sources are made. The third item (3) is a key protection to solve the current problem of unequal protection of the same information by different applications.

At the end of the pre-compilation process, there is a data structure SDS with n +1 dimensions (elements) containing one or more bits, where the data structure SDS with n elements has additional content, representing the lower binary number of the authenticated user ID. The default value is set to the highest number that the size of the ID element can reach, and the user ID can be added to this element by authenticating the login. Elements, all but the user ID, may be stored in order of their numerical value; this means that the most significant digits resulting from the allocation of elements to resources and the allocation of values to access levels can be arranged to the left with the least significant digits to the right.

SQL precompilation, and the processing of the later-determined standard values for the retained elements, must not only specify the result of applying the standard as the value of the retained element, but must also reorder the elements in a stored secure SDS (keeping the user ID at the least significant bit value). As shown below, in the initial grant, there will be a set of matching elements that must have the same ordering as the elements originating from the additional security value to the storage resource. To distinguish the two SDS instances, they will be named Resource Secure Data Structure (RSDS) and authorization secure data structure (GSDS), respectively. The default value of USER _ ID of RSDS is the highest value available in the allocated size. The default value of USER _ ID of GSDS is set to 0. Thus, absent an authenticated login, the core operations described below must always fail.

The core function 114 is responsible for determining whether the privileges of the user are sufficient to allow the user's direct or indirect SQL queries to be generated and compiled and executed. Existing principles of operation invoke permutation (range), open, or blind queries to return any information to users with sufficient privileges. Embodiments of the present invention may continue this principle, but may describe an optional message for a direct request for a secure resource made by a user without the required privilege level or authority. Embodiments of the present invention may also check to see if the user is guessing the presence of security information that he does not have sufficient privileges. For example, a certain number of failed specific resource references in a session may generate a message to the user, the user's administrator, and/or the owner of the resource for which the access attempt failed. These messages may be configured and should comply with existing enforcement security policies related to unauthorized access to data.

Precompilation efficiency

Embodiments of the present invention may include two precompilers. The precompiler 112 may run first and the second precompiler may run next to convert embedded or specialized SQL statements. Many customers now tolerate a reduction in performance in exchange for increased security. However, embodiments of the present invention may improve rather than reduce the performance of a particular set of queries. In fact, selection of only those queries that are authorized (removing (ripping out) unauthorized statements or statement fragments) may send substantially smaller queries to the compiler. Furthermore, the stored precompiler results may allow for (1) faster determination of even authorized portions of SQL statements and (2) replacement of precompiler functionality even for repeated queries over a period of time or in a session.

Converting generic "where^*The particular set of "SQL clauses as requested" where "entries may also substantially reduce the scope and execution time of a particular query. Processing a closed set of entries is much faster than a broad or general global category, which inevitably must be retrieved and processed in a database table to gather such information. The pre-compiler module 112 according to one embodiment of the present invention may pass the modified query containing only entries that need to test privileges; the core function 114 removes any under-privileged portions of the query and the compiler may simply compile the reduced query.

According to one embodiment of the invention, all queries should be precompiled at 112 to prepare the authorization tests required for the requested query and its portions; an alternative is to either accept a reduced or otherwise secure protocol and execution scheme before any of the efficiencies provided by embodiments of the present invention are preserved (e.g., fully compiled and await other low level security checks to prevent further performance-consuming results). A further option is to optimize security and limit performance. Of course, performance may also be obtained by eliminating security. However, embodiments of the present invention allow both performance and authorization security, well mapped to the goals understandable to the customer for specific application security rules to meet their institutional security protocols.

According to embodiments of the present invention, each report generation, each bit of information acquisition, each edit or update, each data call, and security operation is preferably described in the database as a SQL (structured query language) query. Tables and templates, data collection pages, other graphical user interfaces, and similar structures may have SQL statements embedded therein. Developers and others with programmable access to corporate resources may also be controlled with respect to authorization security. In some cases, improvements to non-SQL compilers or execution environment tools may be needed.

Currently existing SQL pre-compilers convert embedded SQL statements into statements that can be processed by the compiler in a supported program language. Such a compiler, which may be used herein to parse and scan an incoming SQL query and identify the secure data resources it is to access and retrieve the relevant elements and element values from the RSDS database where the level of authorization required to access such secure data resources is encoded. These elements may then be assembled in the RSDS structure. The RSDS structure may then be replicated by the GSDS structure of a corresponding single user having the same elements in the same order. The GSDS structure and RSDS structure may then be passed as such to the core function processing shown as 114 in fig. 2.

If a user query fails because the user's GSDS is not specified with sufficient authorization for secure data resources that need to be accessed, the user should not be able to gain access thereto. Blind queries or non-specific queries that include ordering, for example, can be easily detected and blocked. If found, a failed query notification may be sent to the user's administrator. However, such notifications should only be sent to administrators with sufficient privileges with respect to the secure object that the user's SQL query attempted to access. If not, the failure may be sent as a notification to the owner of the security object, who may then decide whether to contact the user's administrator and/or (possibly) grant privileges to the administrator. Guesses of unauthorized variable names, marked by repeated failures in the same session, are violations of most corporate security policies and can notify the user's administrator through appropriate messages. The owner of these security resources may define a number of tests, after which the system may consider such repeated access attempts as a violation of the company's security policy. The notification of an illegal guess does not necessarily require disclosure of the existence of secure data resources to any administrator without appropriate privileges; i.e. high enough to access the secured data resources.

An important function of the SQL precompiler 112 is to receive input from a user query regarding resource security requirements and translate such input into a specific SQL statement and a connection between related secure data resources used in executing the statement. According to embodiments of the present invention, a precompilation of the query as a whole may then be imported to set the bits required for each of the plurality of element values of the user RSDS to reflect the security value of the query. Thus, the number of RSDS elements whose respective values are set is variable depending on the query. In any event, SQL precompilator 112 acts as a security daemon (gatekeeper), creating a challenge that users need to face for their own GSDS, as it sets the appropriate bits for the attempted query in the user RSDS structure. The end result is to block unauthorized users from passing until they reach anywhere near the secured data resource.

The SQL precompilation process may first set the values of all GSDS elements equal to the values in the user GSDS structure that stores privileges. This may make it possible that users never have privileges other than the privileges to which they are assigned. Unused, unsolicited resources will not prevent a particular user from accessing other authorized secure data resources when the user's query does not reference these resources. Thus, optionally, the RSDS and GSDS structures may be cleared to retain only those elements relevant to the current session query.

The SQL precompilator 112 may also conveniently store a set of names for particular privileges when this particular session and its query dispute so that these names may be inserted into messages generated in the operational conclusion of the core function 114, which may be described in detail below.

The query may be stored locally as updates to the RSDS element values are determined by SQL precomplexer 112. It is expected that over time, within and between sessions, repeated queries of the user may be retrieved from such local storage instead of being computed at each instance. Core function

According to an embodiment of the present invention, the core function may be executed by the core function module 114 to compare the subscriber RSDS generated for the query that the subscriber desires to execute with the subscriber GSDS that sets the rights, which the subscriber has been granted in advance, with respect to the secure data resource. The core function may compare the user RSDS generated by the submitted query with the user's own pre-generated GSDS. According to one embodiment of the invention, such a comparison may be performed in the following manner:

1. determining whether the GSDS is greater than or equal to the RSDS;

2. the result is 1 or 0 (logically true or logically false);

3. if the result is true, the user is previously granted sufficient rights to have his or her query executed and the query may be allowed to compile and execute.

4. If the result is false; that is, if GSDS < RSDS, the bit operation of GSDS XOR RSDS generates a unique number indicating that the element of RSDS is larger than the corresponding element in GSDS and the user's query is prevented from being executed (at least any operation related to access to a secure data resource to which it does not have sufficient permissions);

5. the unique number output of step 4 above generates a combination of element identifiers with insufficient authority.

6. Embodiments of the present invention may be configured to disallow queries that attempt to access secure data resources for which the user does not have sufficient privileges and/or request grant of sufficient privileges from the initial authorization module 106. A message may also be generated to notify, for example, the owner of the secured data resource that the access attempt was unsuccessful. Blind, broad, or a predetermined number of repeated guesses may also result in the generation and sending of one or more messages to the resource owner (and the user's administrator if the user's administrator has privileges), the first two and the last may be considered violations of corporate security policies and result in messages being generated and sent to the resource owner and/or designated security personnel (configuration entries).

7. If the user chooses to request grant of sufficient rights to complete the failed query (or independently of the user), the method returns to the process described (outlined) in connection with initial authorization module 106.

8. If rights are granted, the user authorized, stored, and linked queries may then remove the unauthorized portions and authorized queries are executed and the secure data resources referenced by the queries are accessed. The user may only be able to learn directly from a particular reference to a resource in a query that authorization failed unless otherwise configured. Alternatively, the system may be arranged to remove unauthorized elements and their corresponding resources from the query, and then compile and execute the authorized portion of the query.

The unique number can also be generated as follows with respect to steps 4 and 5 described above. In the test of ═ a false result is obtained, and there must be at least one element tested that failed. That is, there must be a requirement (RSDS side) greater than privilege (GSDS side) in at least one instance of an element. Once the elements of the GSDS and RSDS are sorted and arranged, any failure of an element must mean that the RSDS has at least one most significant bit in each of its failed elements. Note that the XOR operation result for the same element GSDS of 0 and RSDS of 1 is 1, while the XOR operation result for the corresponding element GSDS of 0 and RSDS of 0 is 0. This is either an exclusive or xor mechanism rather than the whole. If there is a difference, the most significant position that would result in a failed element if the element failed the test of ═ must be 1.

Since the elements are ordered and all known, the n elements must have the following combinations of failures:

for example, if n-5, there are 5 different elements, each or all of which may fail. The combination (order is not important to failure of the element) is:

failure of a single element a ═ 5! 1! (5-1)! (result is 5)

Failure of two elements B ═ 5! 2! (5-2)! (result is 10)

Failure C ═ 5!for three elements! A/3! (5-3)! (result is 10)

Failure D ═ 5!for four elements! 4! (5-4)! And (the result is 5)

Failure of five elements E ═ 5! 5! (5-5)! (the result is 1)

The implication is that for n-5, an indexed array of cells with 31 possibilities can hold different combinations of all the failed elements of such a set of 5 elements. The number represented by each combination of failed elements may be a number between 1 and 31 (note that 0 represents no failure and is not part of the array). Any array of A + B + C + D + E may hold all combinations possible that fail, and the array may be generated anytime the sorted elements of the GSDS are known. The array may then be indexed so that each failed element may be deduced from the unique number generated by the GSDS and RSDS xor operations. Thus, the index of the array containing the failed element may be derived from the unique number as a result of the XOR core operation.

The result of this is that the initialization of the core function may include generating an array of failed element combinations accessed by a unique number as a result of the RSDS and GSDS xor operations. The core functionality, passing information about which elements are approved and which are not, may allow a user-submitted query to be executed only on those resources that the user has sufficient authorization.

The messaging tool knows the user ID of the user and has access to the information it needs about the user administrator. The message may finally ask the user: if you want i to send this message to your manager so that your manager can grant you enough rights to perform your query? The user may then modify the query or request the necessary privileges. The administrator, even if having sufficient authorization, may or may not choose to check the approval of the message; other approval procedures for this message may also be provided. The net result of implementing an embodiment of the present invention is to provide companies with an easy way to handle security requirements in a systematic, robust, and high performance manner.

In the case where a user attempts a large range of values, is partially authorized and partially not authorized, it may be (a) translated by the compiler into a request for all entries that are designated as authorized, (B) when a message with a user request for additional privileges is sent to the administrator, (C) result in a request for additional privileges, approved by the administrator, and sent to the owner of the resource in question, or (D) some combination of these, as determined by the configuration selected when the authorized user sets up the system.

In case the user tries different variables repeatedly, none is authorized to the user or even does not exist, is a violation of at least part of the security rules. This practice is similar to guessing passwords through trial and error. Embodiments of the present invention may be configured to send messages that are determined to be appropriate by the security policy of the client company.

Updates and upgrades

An upgrade and update module may be provided to pass existing security provisions (provisions) to the appropriate RSDS structure and allow further modification according to user preferences. Similarly, an existing application and rules external to it may be processed so that RSDS elements will be generated. Automatic processing of the user profile will then allow the same elements of the GSDS to hold the appropriate values. From this point of view, the user will have a fully functional system with the security features of the existing database system. The user may then further enrich (flesh out) the existing security parameters with any additional granularity. This module will also provide the appropriate form to collect the information needed for this process. The module may also provide forms and automated procedures to handle any partial or complete promotion and other changes in the status of system users that affect their job responsibilities, employment or contractual status, or specific information they need to know (and therefore their authorizations).

FIG. 2 is a flow diagram representing steps that may be performed to allow query execution or deny query execution according to an embodiment of the invention. Fig. 2 assumes that there already exists a GSDS structure stored for the user. The GSDS structure encodes user permissions related to secure data resources. Unprotected data resources, by their definition, have no restrictions on access to at least those who are properly authenticated. In operation, the method begins at S21, where a query is described and submitted for execution, the query is analyzed and an RSDS structure is generated for the person who submitted the query and for the secured data resources accessed by the submitted query, as invoked by step S22. By comparing the GSDS and RSDS for the user and its query, as shown at S23, a decision can be made regarding the user' S rights to access the secured data resource referenced by the submitted query. For example, if the GSDS is greater than or equal to the RSDS, the submitted query may be allowed to execute, as shown at S24 and S25. If the GSDS (its value) is less than the RSDS (its value), the user' S query may not be allowed (e.g., prevented from executing), as shown at S26. The method ends at S27. In the event of a failure, additional steps (e.g., such as an exclusive-or operation) may be performed to accurately determine which elements in the RSDS are set to a lower value than their corresponding elements in the user GSDS. To reduce the size of the GSDS and RSDS structures, they may be selectively cleared and/or masked as necessary.

FIG. 3 shows the extended steps that may be performed to control access to secured data resources in accordance with other embodiments of the present invention. The method shown in FIG. 3 begins at S31, where a storage operation is performed for all data resources that need to be protected, as shown at S32. Following S32, a predetermined number of bits may be assigned to each stored data resource to be secured to define its respective access rights. A single bit may be sufficient if access rights are granted or not, with more bits enabling higher precision control (e.g., read-only, read/modify, delete, etc.). A Secure Data Structure (SDS) framework may then be defined to hold these bits, an example of which is shown in FIG. 4. Steps S35 and S36 invoke a SDS structure defined for each user that may request access to the secured data resource and their respective granted permissions encoded by selectively setting bits corresponding to the authorization level of each element in the structure, thereby forming a GSDS structure for the user. When a reference or other query is received that attempts to access the secured data resource, an RSDS structure is generated for the user that submitted the query, the RSDS having the same structure as the user GSDS, as shown at S37. However, the RSDS has a bit value that maps to each constituent element of the secure data resource that the user query is attempting to access, and the values stored in each such element may or may not be less than their corresponding element in the user GSDS. When the GSDS and RSDS structures (or matching subsets, determined by a particular query) are compared to determine whether the submitted query is allowed, it may be determined by whether GSDS > ═ RSDS. If GSDS > -RSDS, the user's query is allowed. If GSDS < RSDS, the user submits a query for which the permissions are not sufficient and his or her query is (at least initially) denied execution, as invoked by step S38. Further operations (e.g., such as an exclusive-or operation) may be performed to accurately determine the elements that fail in the query (i.e., which RSDS elements are larger than the corresponding GSDS elements). Additional steps (not shown in FIG. 3) may then be performed for security purposes, such as a failed attempt to log in to access the secure data resource and/or a messaging step to notify an administrator and/or a request to grant sufficient rights to cause the query to be successfully executed.

Working examples

An example of one of the above-described computer-implemented authorization methods is shown below. The following example illustrates the manner in which business processes (business processes) and the security methods described herein affect the constituent parts of such business processes. For purposes of example only, this example describes a fictitious X corporation (hereinafter XCO) with three departments; namely, the ENTRADA division, the FUNDUS division and the GORGON division. XCO also has two levels; i.e., enter employee level and invoice approval level, which is the focus of the funds department. This example includes five users, three of which are invoice clerks (JONES, SMITH, and browse) and two of which are managers/invoice approvers (ditherers and SMITHERS). In this example, the five users will be dealing with two product families; namely the GIZMO product family and the GADGET product family. In general, each department may be organized as a single Operation Unit (OU) with final security rules. However, such OUs need not have any meaning unless they are used in user-defined rules and/or as a basis for granting privileges, rights, and roles to users in accordance with embodiments of the present invention.

Authority security rules applied in this example

All accounts were made by the FUNDUS department, the XCO central accounting department.

JONES can only enter invoices from the ENTRADA department. However, JONES can also view invoices from the FUNDUS department.

SMITH can only enter invoices from the FUNDUS department.

BROWN can enter invoices from ENTRADA and GORGON departments.

DITHERS can view ENTRADA, FUNDUS, and GORGON department invoices; the DITHERS may also approve/update these invoice accounts.

DITHERS can view, create, and update accounts (independent of product family) for the FUNDUS department.

SMITTHERS can view invoices from the GADGET product families of the ENTRADA, FUNDUS and GORGON departments. The SMITHERS can update these invoices (invoice payment methods) and approve invoices submitted for payment when they contain only items from the GADGET product family. SMITHERS cannot approve accounts for the GIZMO product family.

SMITTHERS may view and update accounts for the FUNDUS department and may approve payment of only invoices from the ENTRADA and FUNDUS departments.

The DITHERS is able to check (view) and approve (update) payment for any invoice entered that is only for the GIZMO product family.

Thus, both invoice clerks and managers/invoice approvers have only limited authority to update, approve, and even review or view records. The rules of accounts receivable and accounts receivable of XCO defined above set the need to access and update the financial records by product family (either GADGET or GIZMO) or to approve the payment of invoices from three departments of XCO (ENTRADA, FUNDUS and GORGON). Note that invoices containing GADGET and GIZMO product line items should be prohibited from being viewed by personnel having only GADGET product family review privileges, or only GIZMO product family review privileges, unless they may view a portion of the invoices.

The DITHERS will be able to view invoices from GIZMO product family items during the initial resource store and initial authorization phase, where the owner of the GIZMO first sets privilege requirements in the appropriate elements of the RSDS and then, during the initial authorization phase, the owner of the GIZMO authorizes and the corresponding elements and sets the corresponding privilege levels. The owner of the GIZMO product family resource may protect all GIZMO resources that he/she wishes to protect, establishing the appropriate elements in the GSDS. The owner may then authorize the DITHERS (and, by delegating and within the policy of the HR, the DITHERS may authorize his/her reporter). This means that DITHERS cannot access invoices for the GADGET product family item unless such access is granted by the owner of the GADGET or an owner with sufficient GADGET privileges.

DITHERS may also be inaccessible, with invoices having mixed invoice lines (e.g., the first invoice line is the GIZMO product family project and the second invoice line is the GADGET product family project) absent the necessary authorization.

How these security rules are implemented by one embodiment of the present invention is described in detail below. The Human Resources (HR) department, for example, may be the entity within XCO that is responsible for determining which employees may access company books and other secure data resources. Thus, for these three departments, only SMITH, JONES, and BROWN (invoice clerk) and DITHERS and SMITTHERS (manager/invoice approver) should have any one of the rights of the XCO-owned financial application anyway. Furthermore, at least one of the five people must be a logged-on and authenticated user. Invoice clerks are limited by the work they need to accomplish and the content they need to know; both of which are the basis for the privileges assigned to them by their administrators.

All XCO secure data resources may be logged in a database, as shown at 104 in fig. 1. According to an embodiment of the invention, the secure data resource comprises all data, programs, or electronic records belonging to XCO, the access of which is controlled. Thus, storage of all these data resources should be performed and the stored results stored in the registry database. From this registry database, a Resource Security Data Structure (RSDS) can be created for each person having access to these secure data resources. RSDS databases may be created to store these RSDS structures.

In this manner, the RSDS defines an authorization level that must meet the need for the uniquely identified person to whom the RSDS is assigned to gain any access, review, or be able to edit or approve of the stored secure data resources that his or her query attempts to access. The owner of the secure data resource will respond to the prompt from the initial secure resource storage module 102 as follows: this approach will result in the selective setting of the bits of the RSDS corresponding to its constituent elements for each element according to the desired level of access granted to the uniquely identified user. Using an alphabetic element identifier for each element of the TSDS structure, one can obtain:

A b c d e f g h I j k l m n(User_ID)

initial RSDS 111111111111111188888888

Post-initial RSDS 000000000000088888888

Note that the initial RSDS structure (i.e., the initial state of the RSDS before any bit values corresponding to the desired access level are set) has the bit value of the element identifier a, b, c.. m set to a maximum value of 11(11 is a binary number of 3). In this example, as shown in FIG. 3, elements a, b, c have three levels of authorization associated with them, corresponding to bit values 00 (inaccessible), 01 (view/audit), and 10 (input). Note also that userid 8888888 is used to represent a userid of a 64-bit string (for example) that uniquely identifies a User. The elements are also sorted in order of their maximum value, except only for the User _ ID of the least significant bit value.

Initial authorization

The authorization secure data structure (GSDS) is a mirror image of the RSDS structure; its initial element bit value is set to 0, the privilege being default.

a b c d e f g h I j k l m n

Initial GSDS 000000000000088888888

Post-initial GSDS 000000000000088888888

Meaning that each user defaults to no privilege at all for any secure data resources in the query. Note that the user's query was successful for any unprotected objects. If the user initiates a blind query, the user will only be able to view those objects for which the user actually has the required privileges. Embodiments of the present invention do not allow access to secure data objects to which users are not granted sufficient rights.

SQL compilation

Returning now to the specific example disclosed herein, SMITHERS, without the privilege to view or review any invoices containing information from the GIZMO product family, decides to check the GIZMO product family anyway-he knows the product name from other message sources and guesses through the appropriate WHRER clause. Now, through user SMITHERS login and authentication, SMITHERS initiates a series of queries in a single session from a financial application configured to access secure data resources, as shown in FIG. 1 at reference numeral 110. The query includes a request to report sales from the GIZMO and GADGET product families and a request to approve an account from the GORGON division for a particular invoice containing the GADGET and GIZMO product families. Review the rights security rules for this user: SMITTHERS can view invoices from the ENGARDA, FUNDUS, and GADGET product families of the GORGON division. SMITTHERS can update these invoices (invoice payment methods) and approve invoices submitted for payment when they contain only items from the GADGET product family. SMITTHERS cannot approve accounts for the GIZMO product family. In addition, the entitlement security rules also provide that SMITTHERS can view and update the credit for the FUNDUS department, and can approve the credit for invoices from only the ENTRADA and FUNDUS departments.

The compiler (precompilator) module (shown at 112 in fig. 1) will infer that the secure data resources relevant in the SMITHER's query are mapped to element identifiers f (approval of invoice from GORGON department), j (GADGET product family review), k (GIZMO product family review), l (approval of GADGET product family invoice), and m (approval of GIZMO product family invoice). Setting the bit values of the element identifiers in the RSDS according to the requirements of accessing the secure data resources in the query result of SMITHER, wherein the bit values are as follows:

a invoice privilege, Entrada 00(0 ═ no access 1 ═ view/audit 3 ═ input)

b invoice privilege, Fundus 00(0 ═ no access 1 ═ view/audit 3 ═ input)

c invoice privilege, Gorgon 00(0 ═ no access 1 ═ view/audit 3 ═ input)

d approval/renewal of invoice account, Entrada0(0 is not authorized and 1 is authorized)

e approval/renewal invoice account, Fundus 0(0 is not authorized and 1 is authorized)

f approval/renewal of invoice account, Gorgon 1(0 is not authorized and 1 is authorized)

g audit/view invoice account, Entrada0(0 is not authorized and 1 is authorized)

h check/view invoice account, Fundus 0(0 is not authorized and 1 is authorized)

i review/view invoice account, Gorgon 0(0 is not authorized and 1 is authorized)

j GADGET product family audit 1(0 ═ unauthorized 1 ═ authorized)

k GIZMO product family audit 1(0 ═ unauthorized 1 ═ authorized)

ledget product family account approval 1(0 ═ unauthorized 1 ═ authorized)

m GIZMO product family account approval 1(0 ═ unauthorized 1 ═ authorized)

n authenticated USER _ ID 8²Bit (64 bit unique SMITHERS ID)

Thus, according to the structure of the SDS400 shown in fig. 4, the RSDS of SMITHER may have the following format: 0000000010001111, the tail is followed by the 64-bit User _ ID of SMITHER in the least significant position. Clearing this structure to include only the bit values of those secure data resources that SMITHER desires to access through his query will result in the RSDS structure for these queries SMITHER as follows:

f j k l m User_ID

1 1 1 1 1 SMITHERS

as indicated above, each secure data resource that SMITHES attempts to access in its query has a corresponding bit value set to "1". Setting the bit value of the element identifier according to the rights to SMITHERS defined in the rights security rules for SMITHERS above results in the GSDS of SMITHERS having the following bit values:

a invoice privilege, Entrada 00(0 ═ no access 1 ═ view/audit 3 ═ input)

b invoice privilege, Fundus 00(0 ═ no access 1 ═ view/audit 3 ═ input)

c invoice privilege, Gorgon 00(0 ═ no access 1 ═ view/audit 3 ═ input)

d approval/renewal of invoice account, Entrada0(0 is not authorized and 1 is authorized)

e approval/renewal invoice account, Fundus 0(0 is not authorized and 1 is authorized)

f approval/renewal of invoice account, Gorgon 1(0 is not authorized and 1 is authorized)

g check/view invoice account, Entrada0(0 is not authorized and 1 is authorized)

h check/view invoice account, Fundus 0(0 is not authorized and 1 is authorized)

i review/view invoice account, Gorgon 0(0 is not authorized and 1 is authorized)

j GADGET product family audit 1(0 ═ unauthorized 1 ═ authorized)

k GIZMO product family audit 0(0 ═ unauthorized 1 ═ authorized)

ledget product family account approval 1(0 ═ unauthorized 1 ═ authorized)

m GIZMO product family account approval 0(0 is unauthorized 1 is authorized)

n authenticated USER _ ID 8²Bit (64 bit unique SMITHERS ID)

Note that the bit value of the user GSDS may be defined in advance in any query by that user. Thus, according to the structure of the SDS400 shown in fig. 4, the GSDS of SMITHER may have the following format: 0000000010001010, the tail is followed by the 64-bit User _ ID of SMITHER in the least significant position. Clearing this structure to include only the bit values corresponding to the RSDS generated above (so as to include only the bit values of the element identifiers f, j, k, l, m and User _ ID) to generate a cleared GSDS for the secure data resource that SMITHER attempts to access through its query as follows:

f j k l m User_ID

1 1 0 1 0 SMITHERS

note that only 5 bits are used to define the granted and requested permissions, and in addition 64 bits are used for User _ ID. Although the entire unedited bit string of the RSDS and GSDS structures may be used, it is not necessary in most queries that do not involve or require access to all stored secure data resources. Purging can be easily performed in the RSDS and GSDS because it is not necessary to estimate any GSDS bit values divided by those that match the subset of RSDS bit values that in turn are derived from the user query.

Core function

The core function module, shown at 114 in FIG. 1, functionally and with reference to this example, tests whether SMITTHERS is to view GIZMO sales reports, GADGET sales reports and SMITTHERS is to approve billing from GORGON departments for specific invoices containing GADGET and GIZMO product families. This test may include a comparison of GSDS and RSDS bit strings. The final result of this comparison may include selectively blocking any SMITHERS's (for example) SQL queries that involve a secure data resource for which SMITHERS does not have appropriate rights or allowing such SQL queries to be executed. According to one embodiment of the invention, this comparison may include a first step of determining whether GSDS ═ RSDS is true. If true, the SMITHERS query is allowed to execute. If the result of GSDS ═ RSDS is false, an exclusive or operation (hereinafter XOR) or other test may be performed, using the bit string of RSDS and GSDS (which may be cleared) as operands.

Replacing the values of GSDS and RSDS, the GSDS > -, RSDS operation becomes 11010SMITHERS USER _ ID > -, 11111 SMITHERS USER _ ID ═ false. From which it can be inferred that at least one RSDS element has more most significant bits than the corresponding GSDS element. Thus, to determine which element or elements of the RSDS are larger than the corresponding elements of the GSDS, core functional block 114 may perform the following XOR operations:

11111 SMITHERS USER_ID

XOR 11010 SMITHERS USER_ID

001010

thus, the result of the XOR operation is:

f j k l m User_ID

0 0 1 0 1 0

ignoring the "0" resulting from the tail being OR'd by XOR' ing the two instances that SMITTHERS User _ ID must be the same, the result value is 00101, which corresponds to a decimal value of 5, representing the failed permissions for elements k and m (audit and account approval for the GIZMO product family). Alternatively, a separate XOR operation may be performed on each element of the RSDS and GSDS structures and any bits set in the result may then be stored and associated with its corresponding failed element. Eventually, core function 114 will not allow execution of attempted access by SMITHERS to secure data resources to which it has not been granted any or sufficient permissions, as shown at 122 in FIG. 1. In particular, an SQL query of SMITHER that accesses a secured data resource mapped to element identifiers k and m is denied execution. Functional, this means that SMITTHERS will not have access to the secure data resources related to auditing and accounting approvals for the GIZMO product family.

In more detail, when the XOR operation between GSDS and RSDS yields a non-zero result, at least one element (f, j, k, l, m) must fail. That is, in at least one instance, an element must have a greater demand (RSDS side) than privilege (GSDS side). If there is a difference between the two, when an element fails the XOR test, the most significant bit of the failed element is 1.

Having obtained the result of the XOR operation, there are a number of ways that may be used to determine which element or elements result in a logical 1, which indicates insufficient privilege. There is a possibility of failure for any or all of the five elements (f, j, k, l, m). The combination (order is not important to failure of the element) is:

failure of a single element a ═ 5! 1! (5-1)! (result is 5)

Failure of two elements B ═ 5! 2! (5-2)! (result is 10)

Failure C ═ 5!for three elements! A/3! (5-3)! (result is 10)

Failure D ═ 5!for four elements! 4! (5-4)! And (the result is 5)

Failure of five elements E ═ 5! 5! (5-5)! (result is 1, failure for all elements f, j, k, l, m has only one combination)

The implication is that an indexed array of cells with 31 possibilities can hold different combinations of all failed elements of such a set of 5 elements. The number represented by each combination of fail elements may be a number between 1 and 31 (note that 0 represents no failure and is not part of the array), just as a 5-bit binary number ranging from 0 to 31.

Any array of A + B + C + D + E may hold all combinations possible that fail, and the array may be generated anytime the sorted elements of the GSDS are known. The array may then be indexed so that each failed cell (containing information about the failed element set) may be deduced from the unique number generated by the GSDS and RSDS xor operations. Thus, the index of the cell of the array containing the failed element representation can be derived from the unique number as a result of the XOR operation.

The result of this is that the initialization of core function 114 may include generating an array of failed element combinations accessed by unique numbering as a result of RSDS and GSDSXOR operations. The core function 114, passing information about which elements are approved, may allow the compiler to continue execution only on those resources to which the user is granted sufficient permissions, as shown at 116 and 118 in FIG. 1.

When the core function 114 fails on any element (e.g., is set to a logical 1), a message to the manager of SMITHERS may be described, generated, and sent as shown at 122 and 124 in FIG. 1, in accordance with one embodiment of the present invention. The message may 1) notify the administrator of the access attempt to the secured data resources related to auditing and accounting of the GIZMO product family and/or 2) request that permission be granted sufficient for him to access GIZMO invoice entry and approve GIZMO accounts through, for example, an appropriate SQL query, as shown at 126 in fig. 1. For example, DITHERS, a manager who normally handles the GIZMO product family, may be absent because it is ill. In this case, if the manager of the SMITTHERS needs the information, he or she can contact the manager of the GIZMO product family and request that the appropriate rights to access the GIZMO product family be granted to him or her. The manager of SMITHERS, now having the appropriate privileges, may then grant the same or less access privileges to SMITHERS, thereby enabling the SMITHERS to access the GIZMO product family. The addition of SMITHERS rights may be accomplished by upgrading and updating the functionality of module 128.

Upgrading and updating

In order for SMITHERS to have access to secure data resources related to auditing and invoice approval for the GIZMO product family, the manager of SMITHERS, providing his or her granted sufficient permissions regarding these secure data resources, may use the upgrade function 128 to reset elements f, j, k, l, m in the GSDS structure of SMITHERS from

f j k l m User_ID

1 1 0 1 0 SMITHERS

To

f j k l m User_ID

1 1 1 1 1 SMITHERS

Note that the bit values of element identifiers k and m have been set from binary "0" to binary "1", indicating that the User corresponding to User _ ID is authorized to access the secured data resource mapped to these element identifiers. In this case, the GSDS of SMITHERS now stores "1" for element identifier k, which authorizes SMITHERS to audit the GIZMO product family and stores "1" for element identifier m, which authorizes SMITHERS to approve the accounts for the GIZMO product family. The SMITTHERS upgraded GSDS may be stored in the authorization database 108. Now, again looping through the process steps, SMITTHERS may then describe (for example) an SQL query configured to access secure data resources relevant to review and approval of the GIZMO product family, with the prospect that such an SQL query will be allowed to execute. After the SQL precompiler module 112 has executed, the core function module 114 executes to compare the RSDS obtained (which may be purged) from the SMITHERS SQL query by the SMITHERS upgraded GSDS. This time, the bit value in the RSDS structure corresponding to the associated element identifier is exactly equal to the bit value in the GSDS of SMITHES corresponding to the associated element identifier. In this case, since SMITTHERS's RSDS is equal to his GSDS, a determination may be made at step 116 to allow SQL queries of SMITTHERS for secure data resources related to auditing and approval of the GIZMO product family. The SMITHERS SQL query may then be compiled and executed, as shown at 118, where the method ends at step 120. Further attempts to execute the SQL command will all follow the same comparison between the final RSDS and the subscriber GSDS in the authorization database 108.

This example assumes that the user SMITHERS already knows all of the secure data resources included in its query. If SMITHER uses blind queries, wide-range values, or lucky guesses, SMITHERS may obtain information about objects that he does not have the privilege to him as a user. Embodiments of the present invention are configured to detect (e.g., at SQL precompilator module 112) any such blind queries, broad range, or non-specific references in the query; and compilation and/or querying of any such queries may not be permitted and may result in a message being sent directly to, for example, the administrator of the SMITHERS if he has the appropriate privileges or, if not, to the owner of the secured data resource that the SMITHERS is attempting to access. Embodiments of the invention will extend any scope or open a query as a set of elements and those that the user does not have privileges are prohibited from accessing/executing. The elements that pass the authorization will be those corresponding to the resource number in the final SQL result that is allowed. The owner of the secure data resources may then be free to grant access privileges to the secure data resources to the administrator of SMITHERS, and the administrator of SMITHERS may then be free to assign privileges that they normally own as well as special privileges. Note that a person can only assign rights that are equal to or less than the level of rights that they currently own. Otherwise, SMITTHERS or the administrator of SMITTHERS knows that their object lacking privileges is a violation of the need to know/need to complete work rules.

This leaves the prospect of lucky guesses. GIZMO is apparently a qualifier of the GIZMO product family, and SMITHERS already knows the presence of GIZMO. But for any instance of pure guessing, it is likely to be a trial of repetition and such a trial may be monitored. According to embodiments of the present invention, repeated failures that may constitute security policy violations are reported to the first and second line managers (e.g., SMITHERS). Embodiments of the present invention will never allow unauthorized access, even if guessing lucky and trial and error.

FIG. 5 shows a block diagram of a computer system 500 upon which an embodiment of the invention may be implemented. Computer system 500 includes a bus 501 or other communication mechanism for communicating information, and one or more processors 502 coupled with bus 501 for processing information. Computer system 500 further includes a Random Access Memory (RAM) or other dynamic storage device 504 (referred to as main memory), coupled to bus 501 for storing information and instructions to be executed by processor 502. Main memory 504 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 502. Computer system 500 also includes a Read Only Memory (ROM) and/or other static storage device 506 coupled to bus 501 for storing static information and instructions for processor 502. A data storage device 507, such as a magnetic disk or optical disk, is coupled to bus 501 for storing information and instructions. Computer system 500 may also be coupled via bus 501 to a display device 521 for displaying information to a computer user. Alphanumeric input device 522, including alphanumeric and other keys, is typically coupled to bus 501 for communicating information and command selections to processor 502. Other types of user input devices are cursor control 523, such as a mouse, a trackball, or cursor direction keys to communicate direction information and command selections to processor 502 and to control cursor movement on display 521. The microphone may also be used to provide language input and the camera may be used to input user gestures or sign language, as shown at 525.

Embodiments of the present invention are illustrated and claimed herein in connection with a method and system for implementing authentication and authorization described above using computer system 500 and/or a plurality of such computer systems. According to one embodiment, the methods and systems described herein may be provided by one or more computer systems 500 in response to processor 502 executing sequences of instructions contained in memory 504. Such instructions may be read into memory 504 from other computer-readable media, such as data storage device 507. Execution of the sequences of instructions contained in memory 504 causes processor 502 to perform steps and has the functionality described herein. In an alternative embodiment, fixed circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, the present invention is not limited to any specific combination of fixed circuitry and software.

While the foregoing description has described preferred embodiments of the present invention, it is to be understood that the above description is by way of example only and is not limiting of the disclosed invention. Those skilled in the art will recognize that other alternative embodiments, and all such embodiments, are contemplated as falling within the scope of the present invention.

Claims (26)

1. A computer-implemented method for controlling access to a data resource by a user, comprising the steps of:

storing data resources to be secured;

generating a requirements data structure comprising one element mapped to each inventoried data resource, each element configured to store a requirement value set according to an authorization level required to access the mapped data resource;

for each user having access to any of the inventoried data resources, defining and storing an authorization data structure comprising one element mapped to each of the plurality of data resources, each element configured to store an authorization value set in accordance with an authorization granted to the user to access the mapped data resource;

receiving a user request to access at least one secure data resource;

the grant and requirements data structures are compared and access to any secured data resource in the received user request that maps to any element in the requirements data structure having a requirement value greater than the grant value of the corresponding element in the grant data structure is not allowed.

2. The computer-implemented method of claim 1, wherein the comparing step includes the step of clearing the grant and requirements data structure to include only elements mapped to the inventoried data resources requested to be accessed by the user.

3. The computer-implemented method of claim 1, further comprising allowing access in the received user request to any secured data resource mapped to any element in the requirements data structure having a requirement value less than or equal to the grant value of the corresponding element of the grant data structure.

4. The computer-implemented method of claim 1, wherein the receiving step is performed by a user request comprising a database query.

5. The computer-implemented method of claim 4, wherein the disallowing access step includes a disallowing compilation and execution of database queries.

6. The computer-implemented method of claim 1, wherein the receiving step is performed by a user request comprising an SQL query.

7. The computer-implemented method of claim 1, wherein the defining and generating steps are performed by including an authorization and requirements data structure configured to store a user identification field that uniquely identifies the user.

8. The computer-implemented method of claim 7, wherein the comparing step comprises the step of obtaining an authorization data structure that includes a subscriber identification field whose value matches the value of the subscriber identification field in the generated requirements data structure.

9. The computer-implemented method of claim 1, wherein the comparing step comprises disallowing the received user request from performing unless the authorization binary number collectively formed by the values of the authorization data structure elements is greater than the request binary number collectively formed by the values of the requirements data structure elements.

10. The computer-implemented method of claim 9, further comprising determining which elements of the requirements data structure have values that are less than corresponding elements of the authorization data structure.

11. The computer-implemented method of claim 10, wherein the determining step comprises the step of performing an XOR operation on the values of the elements in the requirements data structure and the values of the corresponding elements in the grant data structure.

12. The computer-implemented method of claim 1, further comprising a logging step to log each instance that is not allowed to access any data structure.

13. The computer-implemented method of claim 1, further comprising the step of generating a message to request greater authority when access to the secured data resource is not permitted.

14. The computer implemented method of claim 13, further comprising the step of updating the value of a selected element in the grant data structure when the message requesting greater authority is answered to grant greater authority in relation to said selected element.

15. The computer-implemented method of claim 1, wherein the secure data resources comprise at least one of data structures and applications.

16. The computer-implemented method of claim 1, wherein the defining and storing steps are performed by describing the authorization data structure in the form of Directory Service Markup Language (DSML) and by entering the authorization data structure as user data in a digital certificate of a user.

17. A computer system including a database storing a plurality of secured data resources to which user access is controlled, the computer system comprising:

at least one processor;

a plurality of processes generated by the at least one processor, the processes comprising processing logic to:

storing data resources to be secured;

generating a requirements data structure comprising one element mapped to each inventoried data resource, each element configured to store a requirement value set according to an authorization level required to access the mapped data resource;

for each user having access to any of the inventoried data resources, defining and storing an authorization data structure comprising one element mapped to each of the plurality of data resources, each element configured to store an authorization value set in accordance with an authorization granted to the user to access the mapped data resource;

receiving a user request to access at least one secure data resource;

the grant and requirements data structures are compared and access to any secured data resource in the received user request that maps to any element in the requirements data structure having a requirement value greater than the grant value of the corresponding element in the grant data structure is not allowed.

18. The computer system of claim 17, wherein the comparing step includes the step of clearing the authorization and requirements data structure to include only elements mapped to the inventoried data resources requested to be accessed by the user.

19. A computer readable medium having stored thereon data representing sequences of instructions that, when executed by a computer device, cause the computer device to control user access to a plurality of secured data resources by performing the steps of:

storing data resources to be secured;

generating a requirements data structure comprising one element mapped to each inventoried data resource, each element configured to store a requirement value set according to an authorization level required to access the mapped data resource;

for each user having access to any of the inventoried data resources, defining and storing an authorization data structure comprising one element mapped to each of the plurality of data resources, each element configured to store an authorization value set in accordance with an authorization granted to the user to access the mapped data resource;

receiving a user request to access at least one secure data resource;

the grant and requirements data structures are compared and access to any secured data resource in the received user request that maps to any element in the requirements data structure having a requirement value greater than the grant value of the corresponding element in the grant data structure is not allowed.

20. A computer-implemented method of controlling user access to data resources of an enterprise, the method comprising the steps of:

storing data resources to be secured;

for each inventoried data resource, specifying a requirement value defining an authorization level required to access the data resource;

storing the demand value for each of the inventoried data resources in a demand data structure;

for each user having access to any of the inventoried data resources, defining an authorization data structure including an authorization value for each of the inventoried data resources, each authorization value determining whether the user is allowed to access the corresponding secure data resource;

when a request is received from a user to access a stored data resource, the requirements data structure is compared to the user's grant data structure and the access request is permitted to be executed only if the grant value for the data resource for which access is requested is at least as great as the corresponding requirement value.

21. The computer-implemented method of claim 20, further comprising the step of enabling the selected user to define and assign the assigned authorization data structure to a lower-ranked user in the enterprise, the defined and assigned authorization-specified data structure storing an authorization value that is no greater than an authorization value in the authorization data structure of the user defining and assigning the assigned authorization data structure.

22. The computer-implemented method of claim 21, wherein the enabling step is performed such that each grant value in the grant data structure for each user is no greater than the corresponding grant value in the grant data structure assigned to the hierarchically higher user.

23. The computer-implemented method of claim 20, further comprising the step of granting an increased authorization level to a user request to access a selected data resource and correspondingly increasing the authorization value of the selected data resource in the authorization data structure of the requesting user.

24. The computer-implemented method of claim 20, further comprising the step of deleting the user authorization data structure when the user leaves the enterprise.

25. The computer-implemented method of claim 20, further comprising the step of initially defaulting the authorization value of the authorization data structure for each user to a lowest value representing a lowest possible authorization level.

26. The computer-implemented method of claim 20, further comprising the step of resetting the authorization value of the authorization data structure for each user to a value indicative of the status of the user at the business and appropriate for the new status of the user at the business.