Patent ID: 12242626

DETAILED DESCRIPTION

Different data environments may use different mechanisms to regulate which users have access to which data sources (e.g., applications, application features, data sets, etc.) therein. That is, the mechanisms regulate the privileges that each user has for accessing each data environment and prevent users who are not authorized to access certain features or data from doing so. As such, each environment needs to receive information defining the privileges for each user that is authorized to access at least a portion of the features/data available therefrom. To track privileges across a multitude of data environments, the graphing service described herein uses a privilege graph to track users and corresponding privileges. The privilege graph, when displayed to a user, graphically represents the associations between authorizations, users, groups, etc. within an entity (e.g., the user's employer), which enables the user to easily comprehend the nature of authorizations for the entity.

In some examples, the graphing service may be pre-configured to access privilege information maintained by a data environment for incorporation into the privilege graph. Pre-configuring the graphing service to perform in such a manner may only be practical for data environments from more popular vendors. Users of the graphing service are more likely to use a more popular vendor, which enables a provider of the graphing service incentive to expend the resources necessary to preconfigure the graphing service for data environments from that vendor. However, there are numerous other data environments that may not be as popular and new environments may join the market. Rather than relying on the provider of the graphing service to configure the graphing service to access an as yet unsupported data environment, the graphing service described below includes an Application Programming Interface (API) framework to receive privilege information from the unsupported data environment. While a user will need to implement the framework in the data environment, the user will not have to wait for pre-configured support to be implemented by the graphing service, especially since that support may never come.

FIG.1illustrates implementation100for pushing access-privilege from data environments to a graphing service. Implementation100includes graphing service101, data environments102, user terminal103, and identity environments104. Data environments102includes data environment121. Graphing service101and data environments102communicate over respective communication links111. Graphing service101and user terminal103communicate over communication link112. Graphing service101and identity environments104communicate over respective communication links113. While communication links111-113are shown as direct links, communication links111-113may include intervening systems, networks, and/or devices. Graphing service101executes on one or more computing systems, such as server systems, having processing and communication circuitry to operate as described below. User terminal103is a user operated computing system, such as a desktop workstation, laptop, tablet computer, smartphone, etc., that user141uses to access data environments102and/or graphing service101.

In operation, graphing service101generates privilege graph131to which tracks authorizations defined in identity environments104and corresponding ones of data environments102. Identity environments104include one or more systems that maintain information about users (e.g., user identity information, user attributes, etc.) and information about which of data environments (including specific data/features therein) each user is allowed to access. Identity environments104may include an active directory (AD) server, a privilege account management (PAM) system, human resources management system (HRMS), identity and access governance (IAG) system, cloud-based identity access management system, or any other type of system that maintains the user information discussed above. By tracking the authorization of many, if not all, users in an organization (e.g., business enterprise), privilege graph131is able to not only represent authorizations for particular users but also represent authorizations based on attributes of users (e.g., the user's role and/or group). The users may include human users, such as user141, non-human users (such as applications, micro-services, etc.), or some combination thereof. Privilege graph131may be stored local to graphing service101or may be accessible to graphing service101from an external data repository, which may itself be managed by one of data environments102. Graphing service101performs operation200, described below, incorporate access privilege information from data environment121, which graphing service101is not preconfigured to automatically retrieve access privilege information therefrom. Other data environments of data environments102may similarly provide access privilege information to graphing service101using the mechanism described by operation200.

FIG.2illustrates operation200to push access-privilege from data environments to a graphing service. In operation200, graphing service101registers data environment121therewith to enable data environment121to use API calls to graphing service101(201). The API framework supported by graphing service101enables data environment121to use one or more predefined API calls to interact with graphing service101. To interact with the API of graphing service101, data environment121is configured to generate and transmit API calls that conform to the requirements of graphing service101's API (e.g., conforms to any data formatting or information-type requirements for the API calls). Data environment121is registered with graphing service101so that graphing service101knows an API call is being received from data environment121, specifically, and that data environment121is authorized to make API calls to graphing service101.

In some examples, a registration API call may be transmitted from data environment121to graphing service101to trigger data environment121's registration therewith. The registration API call may identify data environment121to graphing service101. The registration API call may provide a name/identifier for data environment121, may provide information about data environment121(e.g., a type of data environment, specifications for data environment121, or some other information relevant to graphing service101—including combinations thereof). The registration API call may further include credentials, such as a username and password combination, that indicates to graphing service101that data environment121is authorized to interact with data environment121. In other examples, a user of graphing service101, such as user141, may input information about graphing service101(e.g., a name/identifier, environment type, etc.) into graphing service101to trigger data environment121's registration with graphing service101.

As a result of registration, data environment121may be provided with information necessary for graphing service101to comply with API calls from data environment121. For example, graphing service101may generate a token that data environment121is required to include in its API calls to graphing service101. If an API call from data environment121does not include the token that graphing service101has associated with data environment121, then graphing service101will not comply with the API call.

After data environment121is registered with graphing service101, graphing service101receives API call122transmitted from data environment121(202). API call122provides information about access permissions for data environment121. The information may indicate which users have access to which data/features (e.g., data tables, applications, application components, etc.) of data environment121if not all of data environment121. The users may each be identified individually or based on a group in which the user is categorized (e.g., every user in a particular workgroup may be allowed access to data environment121). Similarly, the access permissions may include indications whether a user has privileges for data read, data write, metadata read, metadata write, and non-data—including combinations thereof. In some examples, data environment121provides all information about the access permissions in API call122even if previous instances of API call122have been sent from API call122with access permission information. In other examples, data environment121only provides an incremental update by including only information that has changed since a previous instance of API call122was sent to graphing service101.

Upon receiving the access permission information from data environment121with API call122, graphing service101incorporates the information into privilege graph131(203). Incorporating the information into privilege graph131along with information received from others of data environments102, graphing service101is able to maintain a representation of user access permissions across all of data environments102, not just those of data environments102that graphing service101is preconfigured to access directly. As noted above, others of data environments102that graphing service101is not configured to access directly may be configured to use the API of graphing service101in a manner similar to data environment121. In some examples, the access permission information may already be formatted as required for inclusion in privilege graph131. In other examples, graphing service101may reformat the information into a canonical format used for privilege graph131. When displayed, privilege graph131may be displayed so that users, such as user141, can visualize user access permissions across all of data environments102. Changes to the access permissions can be made based on what user141sees. In some examples, changes made by user141to privilege graph131may be propagated to the affected ones of data environments102to change access permissions thereat. For example, user141may notice that users in a particular group should not have access to data environment121and may change privilege graph131accordingly. An API call may be made from graphing service101to data environment121indicating which users should no longer have access to data environment121and data environment121will update its access permissions accordingly.

FIG.3illustrates data environments300for pushing access-privilege from data environments to a graphing service. Data environments300are included in data environments102. Data environments include data environment121and data environment321. Data environment121includes data301-303, which are different sets of data (e.g., tables, databases, etc.). The access permissions of data environment121are maintained separately for each of data301-303as privileges311-313. In other examples, the access permissions may be combined together. Data environment321is another of data environments102along with data environment121. Rather than being a type of data environment that only stores data, data environment321provides an application to users. Specifically, data environment321provides application instances304-305with another application instance306coming in a later example. The access permissions are maintained separately for each instance as privileges314-315, although, the access permissions may be combined in other examples. While data environment121only provides data and data environment321only provides application instances, other types of data environments may exist in data environments102. For example, a data environment may provide both data and an application or may provide multiple different applications rather than multiple instances of the same one. The data, application instances, or other type of electronic feature provided by a data environment are referred to below as a data source.

Depending on the type of data environment that is using the API provided by graphing service101, different types of information may be provided. For example, defining access to certain features of an application is different than defining access to a data set. Graphing service101provides templates for API calls referring to different types of data source. API calls from data environment121to provide access information in the examples below

FIG.4illustrates operational scenario400for pushing access-privilege from data environments to a graphing service. In operational scenario400, data environment121transmits registration request401to graphing service101at step 1 to register data environment121with graphing service101. Data environment321transmits registration request402to graphing service101at step 2 to register data environment321with graphing service101. In this example, data environment121and data environment321are registering with graphing service101at substantially the same time, as may occur when graphing service101is first creating privilege graph131for data environments102. In other examples, data environment321may register with graphing service101at a different time. For instance, data environment321may come online at a later date than data environment121. Registration request401identifies data environment121to graphing service101(e.g., provides a name of data environment121) and provides authentication information (e.g., username and password) that, when processed by graphing service101, confirms that data environment121can access the API of graphing service101. Registration request402similarly identifies data environment321and provides authentication information to graphing service101. The authentication information may be the same for each of registration request401and registration request402.

Upon receiving registration request401and registration request402, graphing service101registers data environment321and data environment321at step 3. Registration request401and registration request402may each be an API call to graphing service101's API or may take some other format. Registration in this example includes generating environment identifier403for data environment121and environment identifier404for data environment321. In other examples, graphing service101may instead use an identifier provided by data environment121and data environment321, such as that included in registration request401and registration request402, respectively. In some examples, user141may name data environment121and data environment321to generate environment identifier403and environment identifier404. Graphing service101also creates token405unless token405has already been created when previously registering a data environment. In this example, a single token405is used for data environment321and data environment121but, in other cases, a distinct token may be generated for each data environment.

Graphing service101confirms the registration of data environment121and sends environment identifier403and token405at step 4 to data environment121. Similarly, graphing service101confirms the registration of data environment321and sends environment identifier404and token405at step 5 to data environment321. Data environment121needs to include both environment identifier403and token405in future API calls to graphing service101for graphing service101to comply with the calls. Likewise, data environment321needs to send environment identifier404and token405in future API calls to graphing service101for graphing service101to comply with the calls. Otherwise, graphing service101will not trust that the API calls are coming from a registered source.

In addition to registering each of data environment121and data environment321as a whole, data environment121and data environment321register the particular data sources therein, as each data source is associated with different access privileges. As such, data environment121sends registration request406at step 6 to graphing service101and data environment321sends registration request407at step 7 to graphing service101. Registration request406requests data301-303be each registered as data sources and registration request407requests that application instances304-305be each registered as data sources. In some examples, a separate request may be required for each data source rather than the single request from each of data environment121and data environment321in this example. Like registration request401and registration request402, registration request406and registration request407may be API calls to graphing service101's API or may take some other format.

Responsive to registration request406and registration request407, graphing service101registers data301-303and application instances311-312at step 8. Registration creates source identifiers408for each of the data sources (i.e., data301-303) in data environment121and source identifiers409for each of the data sources (i.e., application instances304-305) in data environment321. Source identifiers408are sent to data environment121at step 9 and source identifiers409are sent to data environment321as step 10. After receiving source identifiers408, data environment121sends API calls410with privileges311-313at step 11 to graphing service101. Each of API calls410corresponds to one of privileges311-313and identifies the data source using a respective one of source identifiers408corresponding to the data course. Similarly, after receiving source identifiers409, data environment321sends API calls411with privileges314-315at step 12 to graphing service101. Each of API calls411corresponds to one of privileges314-315and identifies the data source using a respective one of source identifiers409corresponding to the data source. In other examples a single API call may be sent from each of data environment121and data environment321for all privileges thereat rather than one API call per data source as occurs here. Each of API calls410identifies data environment121using environment identifier403, identifies the data sources using the particular data source using a corresponding one of source identifiers408, and token405. Graphing service101, therefore, knows to which of the data sources the particular API call is referring and the inclusion of token405authenticates the call. Likewise, each of API calls411identifies data environment321using environment identifier404, identifies the data source using the particular data source using a corresponding one of source identifiers409, and token405.

Upon receiving privileges311-315, graphing service101incorporates privileges311-315into privilege graph131at step 13. In some examples, privilege graph131may be initially created using privileges311-315or may simply update an already existing privilege graph131having access information for other data environments of data environments102.

FIG.5illustrates operational scenario500for pushing access-privilege from data environments to a graphing service. In operational scenario500, application instance306is instantiated within data environment321after the most recent update of access permission information to graphing service101. The most recent update may have occurred with API calls411above or additional updates may have occurred subsequent to API calls411. Since application instance306is not yet registered with graphing service101, data environment321transmits registration request501at step 1 to graphing service101. Graphing service101registers application instance306at step 2 and sends source identifier502, which was created during that registration, to data environment321at step 3. Data environment321now has the two respective source identifiers409for instances304-405and source identifier502for application instance306. After registration, data environment321sends API call503with privileges316at step 4 so that graphing service101can include privileges316in privilege graph131at step 5. API call503includes environment identifier404to identify data environment321, source identifier502to identify application instance306, and token405to authenticate API call503to graphing service101.

After some time has elapsed since privileges316were initially sent to graphing service101with API call503, privileges316are updated in data environment321at step 6. For example, a user that did not have access to application instance306previously may now have access. Since privilege graph131does not yet reflect that change, data environment321sends API call504with the updates to privileges316at step 7. API call504may be a different type of call than API call503because API call503included all of privileges316while API call504may only indicate the changes made during the update. Although, similar to API call503, API call504includes environment identifier404to identify data environment321, source identifier502to identify application instance306, and token405to authenticate API call503to graphing service101. When updates are made to any of the other privileges311-315, data environment121and data environment321may similarly send API calls with updates to graphing service101. The update calls may be triggered in response to changes or may occur on some other schedule (e.g., once an hour), which may be dependent on user preferences.

FIG.6illustrates graphs600for pushing access-privilege from data environments to a graphing service. Graphs600include subgraph601and privilege graph602. Subgraph601is an example subgraph created by graphing service101to represent an update to privileges316in the example above. The update to privileges316includes privilege633that allows employee641to access application instance306. Graphing service101obtains identity information about employee641from one or more of identity environments104to determine that employee641is in group611and fills role623. Graphing service101creates the nodes and connections of subgraph601from that information.

Privilege graph602is an example of privilege graph131to which subgraph601is to be incorporated. As can be seen in privilege graph602, employees642in group612and filing role621are already allowed to access application instance306along with application instance304based on privileges631. Privilege graph602also shows that employees642in group612that fill role622have privileges632that allow them to access data301-303and application instance305.

FIG.7illustrates privilege graph700for pushing access-privilege from data environments to a graphing service. Privilege graph700is an example of privilege graph602after incorporation of subgraph601. When combining subgraph601into privilege graph602, graphing service101included employee641with the other employees642. Since one of employees642(i.e., employee641) is now in group611, the node for employees642branches to the node for group611in addition to the node for group612. The node for group611then branches to the node for role623, which branches to the node for privileges633. The node for privileges633then branches to the node for application instance306to indicate that an employee of employees642having the attributes of group611and role623will have privileges633and be allowed access to application instance306. In this example, only employee641will satisfy those attributes but, over time, more employees may be added to privilege graph700having the same attributes.

In some examples, graphing service101may use privilege graph700as a proxy authorization system to determine whether a user can access a data source before the user contacts the data source. For example, if user141is employee641and wants to access application instance306, then graphing service101references privilege graph700to determine that user141can access application instance306. Graphing service101may then allow user141to data environment321via user terminal103and data environment321may then perform its own determination about whether user141can access application instance306(if privilege graph700is up to date, user141should be allowed). Alternatively, graphing service101may indicate to data environment321that user141has already been authenticated/authorized (e.g., graphing service101may act like a single sign (SSO) for data environment321or others of data environments102).

FIG.8illustrates computing architecture800for pushing access-privilege from data environments to a graphing service. Computing architecture800is an example computing architecture for implementing graphing service101. A similar architecture may also be used for other systems described herein, such as user terminal103, although alternative configurations may also be used. Computing architecture800comprises communication interface801, user interface802, and processing system803. Processing system803is linked to communication interface801and user interface802. Processing system803includes processing circuitry805and memory device806that stores operating software807.

Communication interface801comprises components that communicate over communication links, such as network cards, ports, RF transceivers, processing circuitry and software, or some other communication devices. Communication interface801may be configured to communicate over metallic, wireless, or optical links. Communication interface801may be configured to use TDM, IP, Ethernet, optical networking, wireless protocols, communication signaling, or some other communication format—including combinations thereof.

User interface802comprises components that interact with a user. User interface802may include a keyboard, display screen, mouse, touch pad, or some other user input/output apparatus. User interface802may be omitted in some examples.

Processing circuitry805comprises microprocessor and other circuitry that retrieves and executes operating software807from memory device806. Memory device806comprises one or more computer readable storage media, such as a disk drive, flash drive, data storage circuitry, or some other memory apparatus. In no examples would a computer readable storage medium of memory device806, or any other computer readable storage medium herein, be considered a transitory form of signal transmission (often referred to as “signals per se”), such as a propagating electrical or electromagnetic signal or carrier wave. Operating software807comprises computer programs, firmware, or some other form of machine-readable processing instructions. Operating software807includes graphing service module808. Operating software807may further include an operating system, utilities, drivers, network interfaces, applications, or some other type of software. When executed by processing circuitry805, operating software807directs computing architecture800to operate as described herein.

In particular, graphing service module808directs computing architecture800to register a data environment to enable the data environment to use Application Programming Interface (API) calls. Graphing service module808further directs computing architecture800to receive an API call transmitted from the data environment. The API call provides information about access permissions for the data environment. Graphing service module808also directs computing architecture800to incorporating the information into a privilege graph representing data access authorizations.

The descriptions and figures included herein depict specific implementations of the claimed invention(s). For the purpose of teaching inventive principles, some conventional aspects have been simplified or omitted. In addition, some variations from these implementations may be appreciated that fall within the scope of the invention. It may also be appreciated that the features described above can be combined in various ways to form multiple implementations. As a result, the invention is not limited to the specific implementations described above, but only by the claims and their equivalents.