Method, system and program product for authentication of user access to database

Abstract

A method, system, and program product are provided for authenticating user access to a database using a multi-step process. A user request is received in a gateway API for accessing a database, and the user is authenticated by the gateway API based on a user authorization token. In response to the user being unauthenticated in the gateway API based on the user authorization token, access by the user to the database is denied, in response to the user being authenticated in the gateway API based on the user authorization token, an authenticated request is provided from the gateway API to the API handler. Based on the authenticated request, the API handler acquires, from the access eligibility information server, a service key for accessing the database through the API handler, and accesses the database using the service key.

Description

TECHNICAL FIELD

[0001] This specification relates to a multi-step process for authenticating a user's access to a database and methods of using the multi-step process. BACKGROUND

[0002] The market demand for intelligent driving is increasing, and safety is a factor for winning customers' trust in intelligent driving. Safety testing includes field testing, general road performance verification, and virtual verification in the initial stage of development. The degree of simulation of virtual scenarios determines the comprehensiveness related to safety performance verification of autonomous driving systems and advanced driving assistance systems (ADAS). The current development process of ADAS systems and autonomous driving systems requires going through MIL (model in loop), SIL (software in loop), HIL (hardware in loop), DIL (driver in loop), and VIL (whole vehicle in loop). The driving scenario library is an important part of the development process and is executed throughout the development process.

[0003] AV (Autonomous Vehicle) systems use sensors within the vehicle to collect information related to the performance of the vehicle or information associated with the environment surrounding the vehicle. This information can be sent to a central server for inspection and analysis in order to help improve the performance of the vehicle or collect information associated with the environment in which the vehicle is moving. In some instances, third parties such as application developers, insurance companies, or government agencies initiate queries related to information associated with the performance of the vehicle or the environment surrounding the vehicle. AVs collect large amounts of data on a daily basis, which is stored on a server, such as a market data collection (MDC) server. A vehicle API interface (Application Programming Interface) is used to store the data in the MDC database. SUMMARY

[0004] In at least one embodiment, a method of authenticating user access to a database using a multi-step process includes receiving a user request to access a database, the user request including a user authorization token, a request identification (ID), and an event date. The user is authenticated based on the user authorization token. In response to the user not being authenticated based on the user authorization token, the user is denied access to the database. In response to the user being authenticated based on the user authorization token, an authenticated request is provided to an access eligibility information server based on the user request. A service key to access the database is obtained from the access eligibility information server based on the authenticated request. The database is accessed using the service key.

[0005] In at least one embodiment, a system of authenticating user access to a database using a multi-step process includes a memory storing computer readable instructions and a processor coupled to the memory, the processor configured to execute the computer readable instructions to perform actions to receive a user request to access a database, the user request including a user authorization token, a request identification (ID), and an event date. The user is authenticated based on the user authorization token. In response to the user not being authenticated based on the user authorization token, the user is denied access to the database. In response to the user being authenticated based on the user authorization token, an authenticated request is provided to an access eligibility information server based on the user request. A service key to access the database is obtained from the access eligibility information server based on the authenticated request. The database is accessed using the service key.

[0006] In at least one embodiment, a non-transitory computer readable medium is a computer program product including a computer program that, when executed by a processor, causes the processor to perform actions including receiving a user request to access a database, wherein the user request includes a user authorization token, a request identification (ID), and an event date. The user is authenticated based on the user authorization token. In response to the user not being authenticated based on the user authorization token, the user is denied access to the database. In response to the user being authenticated based on the user authorization token, an authenticated request is provided to an access eligibility information server based on the user request. A service key to access the database is obtained from the access eligibility information server based on the authenticated request. The database is accessed using the service key. BRIEF DESCRIPTION OF DRAWINGS

[0007] The schemes of the present disclosure will be best understood by reading the following detailed description in conjunction with the accompanying drawings. It is to be noted, however, that the various features, in order to maintain brevity, are not drawn to scale. In fact, the dimensions of the various features can be increased or decreased as needed in order to make the description concise.

[0008] Figure 1 Data collection in an autonomous driving environment is represented in at least one embodiment.

[0009] Figure 2 an action representing a Lambda authorizer that authorizes a user.

[0010] Figure 3 a multi-step process of at least one embodiment that authenticates a user's access to a database (or other controlled resource).

[0011] Figure 4 is a flowchart of a method of at least one embodiment that uses a multi-step process to authenticate a user's access to a resource (e.g., a database, a server, or the like).

[0012] Figure 5 is a high-level functional block diagram of a processor-based system of at least one embodiment. DETAILED DESCRIPTION

[0013] The embodiments described herein relate to examples of implementing various features of the subject matter provided. In order to simplify the present disclosure, examples related to constituent elements, values, actions, materials, configurations, or the like are described below. Of course, these are examples, and are not intended to be limiting. Other constituent elements, values, actions, materials, configurations, or the like can be assumed. For example, the above or over the second feature in the following description of the first feature includes an embodiment in which the first feature is formed in direct contact with the second feature, an embodiment in which a further feature is formed between the first feature and the second feature so that the first feature and the second feature cannot be in direct contact. In addition, the present disclosure will repeatedly use reference signs and / or reference words in various examples. This repetition is repetition for the purpose of simplification and clarification, and does not define the relationship between the various embodiments and / or constituents described.

[0014] Furthermore, in order to facilitate the description, spatially relative terms such as "below," "under," "beneath," "above," "upper," and the like, can be used in this specification to describe one element's or feature's relationship to another element or feature as illustrated in the figures. The spatially relative terms are intended to encompass different orientations of the device in its operation, for example, the device in the figures is turned on its side and viewed such that the establishment of orientation on figure is other than the orientations designed on the present device. The spatially relative terms are intended to encompass all possible orientations of the device. The devices can be rotated from that which is depicted in the figures, and the spatially relative terms used herein interpreted accordingly.

[0015] Terms such as "user equipment," "mobile station," "mobile device," "mobile device," "subscribing station," "subscribing user equipment," "access terminal," "terminal," "headset," and similar terms refer to wireless devices used by subscribers or users of wireless communication services to receive and deliver data, control, voice, video, speech, gaming, data streams, or signaling flows. These terms are used interchangeably in the subject specification and associated figures. Terms such as "access point," "base station," "Node B," "evolved Node B," "next generation Node B," "enhanced gNB," "home Node B (HNB)," and "home access point (HAP)" and similar terms refer to wireless network components or devices that provide and receive data, control, voice, video, speech, gaming, data streams, or signaling flows to and from user equipment (UE).

[0016] In order to access data through the vehicle API, user authentication is required. However, granting authenticated users direct access to the database presents several challenges. For example, the database is large, making it more difficult to track the actions users are actually taking. Consequently, complex access boundary definitions are used. While users can still design complex queries to access data, this is not scalable or maintainable. Furthermore, granting many users access to database data can lead to data leaks, making data encapsulation more difficult.

[0017] In at least one embodiment, a method for authenticating user access to a database using a multi-step process is provided. The method includes receiving a user request for access to a database, the user request including a user authorization token, request identification information (ID), and a time and date. Authenticating the user based on the user authorization token. In response to the user not being authenticated based on the user authorization token, denying the user access to the database. In response to the user being authenticated based on the user authorization token, providing an authenticated request to an access qualification information server based on the user request. Retrieving a service key for accessing the database based on the authenticated request. Accessing the database using the service key.

[0018] The embodiments described in this specification provide a method that provides one or more advantages. For example, the method of at least one embodiment uses multiple authentication steps to access data stored in an external database. A user is authenticated at the HTTP (Hypertext Transfer Protocol) API level by using an access token, but cannot use that token to access the database directly. According to at least one embodiment, multiple steps are involved in the authentication. The first authentication is to authenticate the user using a user authorization token. The second authentication is an authentication related to the consent of the application access to the database. This forces the user to access the data through the API, enabling better query design by the API developer that is automatically shared between API users. In addition, the user cannot access the database directly, so here the developer has the opportunity to easily filter and change the data encapsulation strategy through the API. With respect to the implementation of the API, the user is authenticated on the HTTP request side, but to access the database, an application key is provided, which neither the user can access nor know.

[0019] Autonomous vehicles analyze data, understand where the vehicle has progressed, detect and avoid hazards, and transport passengers safely with little or no human input. Data collection includes obtaining data captured from one or more sensors within the vehicle and nearby devices in the vehicle's environment. Thus, autonomous vehicles rely on the collection and processing of large amounts of data. Environmental data such as weather, road conditions, other vehicles, pedestrians, road signs, and real-time data related to similar environments combined with information about the vehicle and intelligence for making immediate driving decisions can generate several terabytes (TB) of data per hour for a test vehicle. This data is analyzed for real-time events as managed by the vehicle, but then the data is analyzed by the manufacturer on a per-scenario basis to identify new driving states that can be used to inform the AI (Artificial Intelligence) that underlies the autonomous actions of the vehicle.

[0020] The capabilities of the vehicle system can also be adjusted based on the priority level of the user making the request. For example, different users can have different priority levels for access to the data. The priority level is set based on the type of customer, such as government, police, retailer, entertainment, etc. Also, software developers can request access to the database to develop new applications.

[0021] Figure 1 Data collection in an autonomous driving environment 100 representing at least one embodiment.

[0022] Figure 1Autonomous vehicles 110, 120, 130 are shown. Autonomous vehicle 110 includes at least sensor 112 and sensor 114. Autonomous vehicle 120 includes at least sensor 122 and sensor 124. Autonomous vehicle 130 includes at least sensor 132 and sensor 134. Autonomous vehicles 110, 120, 130 can include more sensors. Such sensors include video cameras, Radio Detection and Ranging (RaDAR) sensors, Light Detection and Ranging (LiDAR) based sensors, Infrared (IR) sensors, and the like.

[0023] Wireless communication in autonomous vehicles 110, 120, 130 refers to the exchange of information between these vehicles and other devices via network 140. Wireless communication enables sharing of data with other vehicles, infrastructure, and connected devices such as traffic lights, road sensors, and the like. Sharing of data via wireless communication enables a more coordinated and efficient transportation system. Wireless standards enable communication between autonomous vehicles, enabling them to exchange information such as speed, direction, and location. This communication helps to coordinate collision avoidance and improves overall road safety.

[0024] Autonomous vehicles use various wireless technologies such as cellular networks, Wi-Fi, and V2X (Vehicle-to-Everything) communication protocols including V2V (Vehicle-to-Vehicle), V2I (Vehicle-to-Infrastructure), and V2P (Vehicle-to-Pedestrian). By connecting to the network, these vehicles have access to a vast amount of data such as high-precision maps, weather conditions, traffic patterns, and updates related to construction work or accidents.

[0025] Server 170 can collect data from autonomous vehicles 110, 120, 130, as well as infrastructure and connected devices such as traffic light 150, road sensors 160, 162, 164, and the like. The data is stored in a database within server 170 and can be provided to autonomous vehicles 110, 120, 130 or accessed by different users.

[0026] In addition to providing data within server 170 back to autonomous vehicle 110, autonomous vehicle 120, autonomous vehicle 130, other users want to access data within server 170. For example, test engineers and application software developers can use data within server 170 in testing applications in closed software-in-the-loop (SIL) testing without access to real vehicles.

[0027] Figure 2 Action 200 represents a Lambda authorizer that authorizes users.

[0028] In Figure 2 The function of token authenticator 210 is used to control access to HTTP API gateway 220. User 222 logs in to third-party identity provider 240.

[0029] Third-party identity provider 240 makes, manages, and maintains identity for provisioning. After a successful login, third-party identity provider 240 issues an access token to the client. Third-party identity provider 240 issues an encrypted signed token to user 222, which contains information related to the user identity associated with user 222 and the version.

[0030] After obtaining the token, user 222 issues an HTTP request to API gateway 220, which includes the access token. API gateway 220 passes the token to token authenticator 210. To use the token to access a resource (e.g., a database, a server, or the like), an authorization code is defined using a function that maps token characteristics to gateway resources and versions.

[0031] Token authenticator 210 executes authorization logic to make an identity management policy (IAM). Token authenticator 210 calls a function that authenticates the token through third-party identity provider 240. Token authenticator 210 passes the response to API gateway 220.

[0032] API gateway 220 evaluates the IAM against API gateway resources 250 (e.g., a database, a server, or the like) that are requested by user 222 to determine whether user 222 is authorized to access API gateway 220 and, in turn, API gateway resources 250. API gateway 220 grants or denies the request issued by user 222. In the case of a grant, API gateway 220 passes the request from user 222 to API gateway resources 250.

[0033] Figure 3A multi-step process 300 to authenticate a user's access to a database (other control resource) is shown in accordance with at least one embodiment.

[0034] In Figure 3 The user 310 accesses an application programming interface (API) 320 to request vehicle data. For example, the user 310 accesses the API 320 through a web browser, generating an HTTP request 312 related to vehicle data. The API 320 is also sometimes referred to as a gateway API. Through the web browser, the user 310 can provide a request identification (ID) and an event date to the API 320 through the HTTP request 312. The HTTP request 312 also contains, for example, a bearer token as described with reference to Figure 2 The user 310 obtains an authentication token 314 from the identification provider 330 to control access to the API 320 as described above. The authentication token (bearer token) 314 is provided automatically when the user 310 uses a UI (User Interface) such as a data lens, or manually after logging into the identification provider 330 (as described above) after initially obtaining the authentication token 314 through the identification provider 330. Figure 2 The user 310 obtains an authentication token 314 from the identification provider 330 to control access to the API 320 as described above. The authentication token (bearer token) 314 is provided automatically when the user 310 uses a UI (User Interface) such as a data lens, or manually after logging into the identification provider 330 (as described above) after initially obtaining the authentication token 314 through the identification provider 330.

[0035] The API 320 transmits the authentication token 322 to the Lambda authorizer 340. The Lambda authorizer 340 invokes a Lambda function that authenticates the user 310 through the identification provider 330 based on the authentication token 322. The Lambda authorizer 340 then transmits an authentication response 342 to the API 320. Thus, the API 320 identifies users one at a time, processing each authentication of the user 310 with respect to the API 320 through the Lambda authorizer 340. The authentication response 342 can indicate a failure of the user's authorization or a success of the user's authorization. For example, a failure of the user's authorization can result from the user not providing the authentication token 314 in the HTTP request 312, the authentication token 322 not being authenticated by the Lambda authorizer 340 / identification provider 330, or the authentication token 322 expiring.

[0036] When the user's 310 authorization fails, the API 320 denies the user 310 access to the data. In response to the user 310 not being authenticated, for example, not being authorized to access the API gateway, the API 320, the user 310 is not able to proceed further.

[0037] When the user's 310 authorization succeeds, the API 320 sends an authenticated request 324 containing the request ID and the event date to an API handler 350.

[0038] The API handler 350 obtains the database service key 362 from the access entitlement information server 360 to access a resource (e.g., a database 370, a server, or the like) based on the authenticated request 324. Thus, the API handler 350 obtains its own entitlement information related to the external database 370. To decide whether to enable the API 320 to access a table within the database 370, a service role and an asymmetric access key (database service key 362) associated with the database 370 are used. The user 310 makes the service role, and the private key of the user 310 is registered within the database 370 so that the database 370 can agree to access to data within the database 370 based on the service role. The service role identifies the user 310 who represents the HTTP API service within the database 370. Thus, while the access to the API 320 is controlled on a per-user basis, the access to the database 370 is controlled based on the database service key 362 via the service account and the service role related to the user 310 associated with the data within the database 370. The database 370 and the like service stores and uses secrets within the access entitlement information server 360. The access entitlement information server 360 is a secure and convenient storage system related to API keys, passwords, certificates, and other confidential data. The access entitlement information server 360 provides a central place and a trusted source of unique information to manage, access, and monitor secrets throughout the cloud. The access entitlement information server 360 manages, obtains, and rotates database entitlement information, application entitlement information, OAuth tokens, API keys, and other secrets throughout their life cycles. The database service key 362 within the access entitlement information server 360 is rotated periodically by using a function to update the public key (database service key 362) within the access entitlement information server 360 and the makeup of the database 370 related to the user 310. For example, the database service key 362 can be rotated automatically every month.

[0039] The API handler 350 sends a data request 352 related to data within the database 370 based on the role associated with the database service key 362. The data request 352 includes a request ID to access the database 370, event data, the database service key, and the like.

[0040] The database 370 analyzes the database service key 362 received in the data request 352 from the API handler 350, and identifies the service account and the service role associated with the database 370.

[0041] In response to the data request 352 (request ID, event data, database service key, and same kind of content), the database 370 sends back to the API handler 350 the sensor data 372 within the database 370 that is not anonymized (e.g., confidential data).

[0042] The API handler 350 anonymizes (e.g., converts the confidential data to anonymized data) the confidential data to generate anonymized data (L2 data) 354, which is provided to the API 320. The API 320 then provides the anonymized data (anonymized data) 326 to the user 310.

[0043] Thus, while access to the API 320 is controlled on a per-user basis, access to the external database 370 is controlled based on the database service key 362 via the service account and service role of the user associated with the database 370. According to at least one embodiment, to determine whether to enable the API 320 to access a table within the database 370, the service role and asymmetric access key (database service key 362) associated with the database 370 are used. The authentication process for the user 310 is performed by the API 320 and the token authenticator 340, and then the authenticated request 324 is passed to the API handler 350.

[0044] According to at least one embodiment, to enable access to a resource (e.g., database 370, server, or the like), the API handler 350 obtains the database service key 362 from the access eligibility information server 360 and uses the database service key 362 to make data requests 352 related to access to the database 370. The user 310 makes an asymmetric key pair for an application, the private key (database service key 362) obtained by the API handler 350 to access the database 370 is stored in the access eligibility information server 360, the public key (database service key 362) is generated from the private key (database service key 362), and the public key (database service key 362) is registered in the database 370 for association with the user 310. A role is made that identifies the user 310 associated with the HTTP API service within the database 370. The public key (database service key 362) of the user is registered in the database 370, and the associated role is provided to the user 310 via the API handler 350.

[0045] It is a problem to give each user 310 direct access to the database 370 or only through one API handler 350. For example, it is desirable to give an application its own database service key 362 so that a user can establish a session with a token and authenticate the session. However, having a single level of authentication to access the database 370 does not provide the granularity of the user level for making decisions on access to data in the database 370, so there is a much higher likelihood of data leakage. In the case of a database 370 that is large, having billions of records, it is difficult to control access to the records using a single level of authentication. Therefore, in at least one embodiment, the user is prevented from directly accessing the database 370, and instead, some level of data encapsulation is provided, with the data being provided through the API 320 and the API handler 350. The API handler 350 not only interfaces with the database 370, but also makes restrictions on queries that can be sent to the database 370 based on the database service key 362 obtained from the access entitlement information server 360.

[0046] Another problem is that the user 310 does not know where the data is configured in the database 370. Therefore, another advantage of not giving the user direct access to the data includes anonymizing the data and making data extraction more efficient. The alternative is to use large scale queries and multi-step authentication to give many users direct access to the database. This is analogous to a restaurant that does not give the user access to the food pantry to decide what menu items the user wants to order, but instead provides a menu to the user to make ordering more efficient. In other words, in response to giving the user the freedom to code their own queries, in many cases, the user will construct inefficient queries. For example, the user can construct the same query using more resources to obtain the data in response to the query, thereby possibly overloading the system. The user 310 does not know where the data is configured, does not know the method of designing efficient queries, and the user 310 can access data that is not authorized for access. Therefore, the embodiments described in this specification provide access to data that is not only more secure, but also provides a more stable system.

[0047] Figure 4 is a flowchart 400 of a method of at least one embodiment using a multi-step process to authenticate user access to a database.

[0048] In Figure 4 In the method, the process begins (S402) by receiving a user request to access a resource (e.g., a database, a server, or the like) in an application programming interface (API), the user request including a user authorization token, a request identification (ID), and a date of the event (S410). Referring to Figure 3The user 310 accesses an application programming interface (API) 320 to request vehicle data. For example, the user 310 accesses the API 320 through a web browser, generating an HTTP request 312 related to vehicle data. The API 320 is sometimes also referred to as a gateway API. Through the web browser, the user 310 can provide a request identification (ID) and an event date to the API 320 through the HTTP request 312. The HTTP request 312 also contains, for example, a vehicle identification number (VIN) as described with reference to Figure 2 The user 310 obtains an authentication token 314 from the identification provider 330 to control access to the API 320 as described above. The authentication token (bearer token) 314 is provided automatically when the user 310 uses a UI such as a data lens, or manually provided by the user 310 after logging into the identification provider 330 (as described above) after initially obtaining the authentication token 314 through the identification provider 330. Figure 2 The user 310 obtains an authentication token 314 from the identification provider 330 to control access to the API 320 as described above. The authentication token (bearer token) 314 is provided automatically when the user 310 uses a UI such as a data lens, or manually provided by the user 310 after logging into the identification provider 330 (as described above) after initially obtaining the authentication token 314 through the identification provider 330.

[0049] Based on the user authorization token, a decision is made whether the user is authenticated (S414).

[0050] In response to the user not being authenticated in the API based on the user authorization token, access to the resource is denied (S420). Referring back to Figure 3 When the user 310 fails to be authorized, the API 320 denies the user 310 access to the data. In response to the user 310 not being authenticated, e.g., not being authorized to access the API 320, the user 310 is then unable to proceed further.

[0051] In response to the user being authenticated based on the user authorization token (S422), a next authentication process is started (S426).

[0052] Based on the user authorization token, the user is authenticated in the API. Referring back to Figure 3 The API 320 transmits the authentication token 322 to the token authenticator 340. The token authenticator 340 invokes a function that authenticates the user 310 through the identification provider 330 based on the authentication token 322. The token authenticator 340 then transmits an authentication response 342 to the API 320. Thus, the API 320 identifies the user on a user-by-user basis, processing each authentication of the user 312 with respect to the API 320 through the token authenticator 340. The authentication response 342 can be used to indicate a failure of the user to be authorized or a success of the user to be authorized. For example, a failure of the user to be authorized can result from the user not providing an authentication token in the HTTP request 312, the authentication token 322 not being authenticated by the token authenticator 340 / identification provider 330, or the authentication token 322 expiring.

[0053] In response to the user being authenticated in the API based on the user authorization token, the authenticated request is provided from the API to the API handler based on the user request (S430). Referring to Figure 3 When the authorization of the user 310 is successful, the API 320 sends the authenticated request 324 containing the request ID and the event date to the API handler 350.

[0054] The API handler obtains a service key to access the database through the API handler from the access entitlement information server based on the authenticated request (S434). Referring to Figure 3 The API handler 350 obtains a database service key 362 to access a resource (e.g., a database 370, a server, or a similar resource) from the access entitlement information server 360 based on the authenticated request 324. Thus, the API handler 350 obtains its own entitlement information related to the external database 370. To decide whether to enable the API 320 to access a table within the database 370, a service role and an asymmetric access key (database service key 362) associated with the database 370 are used. The user 310 makes the service role, and the private key of the user 310 is registered within the database 370 so that the database 370 can agree to access to data within the database 370 based on the service role. The service role identifies the user 310 representing the HTTP API service within the database 370. Thus, while the access to the API 320 is controlled per user, the access to the database 370 is controlled based on the database service key 362 via the service account and the service role related to the user 310 associated with the data within the database 370. The database 370 and other services store and use secrets within the access entitlement information server 360. The access entitlement information server 360 is a secure and convenient storage system related to API keys, passwords, certificates, and other secret data. The access entitlement information server 360 provides a central place and a trusted source of unique information to manage, access, and monitor secrets throughout the cloud. The access entitlement information server 360 manages, obtains, and rotates database entitlement information, application entitlement information, OAuth tokens, API keys, and other secrets throughout their life cycles. The database service key 362 within the access entitlement information server 360 is rotated periodically by using a function to update the public key (database service key 362) within the access entitlement information server 360 associated with the database 370 related to the user 310. For example, the database service key 362 can be rotated automatically every month.

[0055] The API handler accesses the database using the service key (S438). Referring to Figure 3API handler 350 sends a data request 352 related to data within database 370 based on the role associated with database service key 362. Data request 352 contains a request ID to access database 370, event data, database service key, and the like.

[0056] Database analyzes the service key received from the API handler and identifies the service account and service role associated with the database (S442). Referring to Figure 3 Database 370 analyzes database service key 362 received in data request 352 from API handler 350 and identifies the service account and service role associated with database 370.

[0057] Data from the database is sent back to the API handler (S446). Referring to Figure 3 In response to data request 352 (request ID, event data, database service key, and the like), database 370 sends back un-anonymized sensor data 372 (e.g., confidential data) within database 370 to API handler 350.

[0058] Data sent back from the database to the API handler is provided to the API (S450). Referring to Figure 3 API handler 350 anonymizes (e.g., converts confidential data to anonymized data) the confidential data to generate anonymized data 354, which is provided to API 320.

[0059] The sent back data is presented to the user (S454). Referring to Figure 3 API 320 then provides the anonymized data (anonymized data) 326 to user 310.

[0060] The service key is automatically rotated periodically by accessing the entitlement information server (S458). Referring to Figure 5 Access entitlement information server 360 provides a central place and trusted source of unique information to manage, access, and monitor secrets throughout the cloud. Access entitlement information server 360 manages, accesses, and rotates database service key 362 throughout the life cycle of database entitlement information, application entitlement information, OAuth tokens, API keys, and other secrets. Database service key 362 within access entitlement information server 360 is rotated periodically by using a function that updates the public key (database service key 362) within access entitlement information server 360 and the composition of database 370 related to user 310. For example, database service key 362 can be automatically rotated every month.

[0061] Next, the process ends (S470).

[0062] At least one embodiment provides a method of authenticating user access to a database using a multi-step process. The method includes receiving, in a gateway API, a user request to access a resource, the user request including a user authorization token, a request identification (ID), and an event date. The user is authenticated in the gateway API based on the user authorization token. In response to the user not being authenticated in the gateway API based on the user authorization token, the user is denied access to the resource. In response to the user being authenticated in the gateway API based on the user authorization token, an authenticated request is provided from the gateway API to an API handler based on the user request. The API handler obtains a service key from an access entitlement information server to access the database by the API handler based on the authenticated request. The API handler uses the service key to access the database.

[0063] ​ is a high-level functional block diagram of a processor-based system 500 of at least one embodiment.

[0064] In at least one embodiment, processing circuitry 500 provides a multi-step process of authenticating user access to a database. Processing circuitry 500 uses processor 502 to implement the multi-step process of authenticating user access to a database. Processing circuitry 500 also includes non-transitory computer-readable storage medium 504 that is used to implement the multi-step process of authenticating user access to a database. In particular, non-transitory computer-readable storage medium 504 stores instructions 506 that are executed by processor 502 to cause processor 502 to perform actions implementing the multi-step process of authenticating user access to a database, i.e., instructions 506 are encoded by computer program code. Execution of instructions 506 by processor 502 represents, at least in part, an application that implements at least a portion of the methods (processes and / or methods described below) described in this specification in accordance with one or more embodiments.

[0065] The processor 502 is electrically connected to the non-transitory computer readable storage medium 504 via a bus 508. The processor 502 is electrically connected to an input / output (I / O) interface 510 through the bus 508. The network interface 512 is electrically connected to the processor 502 via the bus 508. The network interface 512 is connected to a network 514, as a result of which the processor 502 and the non-transitory computer readable storage medium 504 are connected to external elements via the network 514. The processor 502 is configured to execute the instructions 506 encoded in the non-transitory computer readable storage medium 504, so as to enable the processing circuit 500 to perform at least a part of the processes and / or methods. In one or more embodiments, the processor 502 is a central processing unit (CPU), a multi-processor, a distributed processing system, an application specific integrated circuit (ASIC), and / or a suitable processing unit.

[0066] The processing circuit 500 includes the I / O interface 510. The I / O interface 510 is connected to external circuits. In one or more embodiments, the I / O interface 510 includes a keyboard, a keypad, a mouse, a trackball, a touchpad, a touchscreen, and / or a cursor direction key that communicates information and commands with the processor 502.

[0067] The processing circuit 500 also includes the network interface 512 connected to the processor 502. Through the network interface 512, the processing circuit 500 can communicate with the network 514 connected with one or more other computer systems. The network interface 512 includes a wireless network interface, such as Bluetooth, Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), General Packet Radio Service (GPRS), or Wideband Code Division Multiple Access (WCDMA); or a wired network interface, such as Ethernet, Universal Serial Bus (USB), or Institute of Electrical and Electronics Engineers (IEEE) 864.

[0068] The processing circuit 500 is configured to receive information through the I / O interface 510. The information received through the I / O interface 510 includes one or more of instructions, data, design rules, libraries of cells, and / or other parameters for processing by the processor 502. The information is transferred to the processor 502 via the bus 508. The processing circuit 500 is configured to receive information associated with a user interface (UI) through the I / O interface 510. The information is stored in the non-transitory computer readable storage medium 504 as the UI 520.

[0069] In one or more embodiments, one or more non-transitory computer readable storage media 504 have stored, thereon (in a compressed or uncompressed form), instructions 506 that are executable by a computer, a processor, or other electronic device to cause the device to perform a process or method as described in this specification. The one or more non-transitory computer readable storage media 504 include one or more of electronic storage media, magnetic storage media, optical storage media, quantum storage media, or any suitable combination of the foregoing.

[0070] For example, the non-transitory computer readable storage medium 504 can include a hard disk, a floppy disk, a compact disc (CD), a digital versatile disc (DVD), a read-only memory (ROM), a random access memory (RAM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a flash memory, a magnetic or optical card, a solid state memory device, or any suitable type of physical medium suitable for storing electronic instructions, but is not limited thereto. In one or more embodiments using an optical disc, the one or more non-transitory computer readable storage media 504 include a compact disc read-only memory (CD-ROM), a compact disc -read / write (CD-R / W), and / or a digital versatile disc (DVD), but are not limited thereto.

[0071] In one or more embodiments, the non-transitory computer-readable storage medium 504 stores instructions 506 configured to cause the processor 502 to perform at least a portion of a process and / or method related to a multi-step process of authenticating a user's access to a database. In one or more embodiments, the non-transitory computer-readable storage medium 504 also stores information, such as an algorithm, that facilitates at least a portion of a process and / or method related to a multi-step process of authenticating a user's access to a database.

[0072] Accordingly, in at least one embodiment, the processor 502 executes instructions 506 stored in one or more non-transitory computer readable storage media 504 to implement a multi-step process to authenticate a user’s access to a database. The user interface 520 presents information 522 including HTTP requests, authenticated requests, data, and the like. The user interface 520 also presents at least an application programming interface (API) gateway 524 and an API handler 526. The processor 502 receives an HTTP request 530 in an API 540 related to a user seeking to access a resource (e.g., a database 570, a server, or the like) that includes a user authorization token, a request identification (ID), and an event date 532. The processor 502 presents a user interface of the API 540 to the user via a web browser in which the HTTP request 530 is received via the web browser. The processor 502 uses the API 540 to authenticate the user based on the authorization token 532 in the HTTP request 530. The processor 502 causes the API 540 to send the authentication token 532 from the HTTP request 530 to a token authenticator 542, which the processor causes to send the authentication token 532 from the HTTP request 530 to an identification information provider 544. The processor 502 causes the identification information provider 544 to send an authentication response 546 back to the token authenticator 542 based on the authentication token 532, which the token authenticator 542 sends back to the API 540. In response to the user not being authenticated in the API 540 based on the authorization token 532, the processor 502 denies the user access to the resource. In response to the user being authenticated in the API 540 based on the authorization token 532, the processor 502 causes the API 540 to send an authenticated request 550 to an API handler 552. Based on the authenticated request 550, the processor 502 causes the API handler 552 to obtain a database service key 554 from an access entitlement information server 558 to access the database 570 by the API handler 552. The processor 502 causes the API handler 552 to send a data request 560 including the request ID, the event date, the database service key 562 to the database 570. The database 570 stores data 572 that is not anonymized. The processor 502 causes the database 570 to analyze the database service key 554 received from the vehicle API handler 552 to identify a service account and service role 556 associated with the user in the database 570. Based on the database service key 554, the processor 502 obtains data 574 from the database in response to the data service key 554 including data 576 that is not anonymized to be sent back to the API handler 552.The processor 502 anonymizes data 576 that is not anonymized using an API handler 552 to generate anonymized data 578 that is provided to the API 540, which is presented to the user. The processor 502 automatically rotates the database service key 554 periodically in the access entitlement server 558. The display 590 presents a user interface (UI) 592 that presents information 594 including HTTP requests, authenticated requests, and data such as data retrieved from the database 570. The UI 592 also presents the API 596 and the API handler 598 as described above.

[0073] The implementations described in this specification provide one or more technical advantages. For example, the method of at least one implementation uses multiple authentication steps to access data stored in an external database. An API is used to authenticate a user at the HTTP API level using an access token, but the token cannot be used to directly access the database. According to at least one implementation, multiple steps are involved in the authentication. A first authentication is of the user. A second authentication is of consent to application access to the database. This forces the user to access data through the API, enabling superior query design by the API developer that is automatically shared among API users. In addition, the user cannot directly access the database, so here the developer has the opportunity to easily filter and change data packaging strategies through the API. With respect to the implementation of the API, the user is authenticated on the HTTP request side, but to access the database, an application key is provided, which neither the user can access nor know.

[0074] The implementations described in this specification are directed toward a method [1] of authenticating user access to a database using a multi-step process by a processor, the method comprising: receiving a user request to access the database, wherein the user request includes a user authorization token, a request identification (ID), and an event date; authenticating the user based on the user authorization token; in response to the user not being authenticated based on the user authorization token, denying the user access to the database; in response to the user being authenticated based on the user authorization token, providing an authenticated request to an access entitlement server based on the user request; obtaining a service key to access the database from the access entitlement server based on the authenticated request; and accessing the database using the service key.

[0075] [2] The method of [1] further comprising: accessing data from the database; receiving return data from the database; and presenting the return data to the user.

[0076] [3] The method of any one of [1] or [2], wherein the retrieval of data from the database comprises: retrieving confidential data; and anonymizing the confidential data to generate anonymized data.

[0077] [4] The method of any one of [1] to [3], further comprising: automatically rotating the service key periodically by accessing the access eligibility information server.

[0078] [5] The method of any one of [1] to [4], further comprising: analyzing, by the database, the service key received from the access eligibility information server to identify a service account and a service role associated with the database.

[0079] [6] The method of any one of [1] to [5], wherein the receiving of the user request to access the database comprises: presenting a user interface to the user via a web browser; and receiving an HTTP request via the web browser, wherein the HTTP request is the user request.

[0080] [7] The method of any one of [1] to [5], wherein the authenticating of the user comprises: providing a user authorization token to a token authenticator; and authenticating, by the token authenticator using an identification information provider, identification information of the user based on the user authorization token.

[0081] The solution of the present specification is directed to a system [8] comprising a memory storing computer readable instructions and a processor connected to the memory, the system [8] using a multi-step process to authenticate a user's access to a database, the processor configured to execute the computer readable instructions to perform actions to: receive a user request to access the database, wherein the user request includes a user authorization token, a request identification (ID), and a date of event; authenticate the user based on the user authorization token; in response to the user not being authenticated based on the user authorization token, deny the user access to the database; in response to the user being authenticated based on the user authorization token, provide an authenticated request to an access eligibility information server based on the user request; obtain a service key to access the database from the access eligibility information server based on the authenticated request; and use the service key to access the database.

[0082] [9] The system of [8], wherein the processor is further configured to: receive data from the database, receive retrieval data from the database, present the retrieval data to the user.

[0083]

[10] The system of any one of [8] or [9], wherein the processor is further configured to receive data from the database by: receiving confidential data from the database; and anonymizing the confidential data to generate anonymized data.

[0084]

[11] The system of any one of [8] to

[10] , wherein the processor is further configured to automatically rotate the service key periodically in the access-eligibility information server.

[0085]

[12] The system of any one of [8] to

[11] , wherein the processor is further configured to analyze the service key received from the access-eligibility information server to identify the service account and the service role associated with the database.

[0086]

[13] The system of any one of [8] to

[12] , wherein the processor is further configured to receive the user request to access the database by: presenting a user interface to the user via a web browser; and receiving an HTTP request via the web browser, wherein the HTTP request is the user request.

[0087]

[14] The system of any one of [8] to

[13] , wherein the processor is further configured to authenticate the user by providing the user authorization token to a token authenticator and receive the authentication of the user from an identification information provider based on the user authorization token.

[0088] The scheme of the present specification is directed to a computer program

[15] that, when executed by a processor, causes the processor to perform actions comprising: receiving a user request to access a database, wherein the user request includes a user authorization token, a request identification (ID), and an event date; authenticating the user based on the user authorization token; in response to the user not being authenticated based on the user authorization token, denying the user access to the database; in response to the user being authenticated based on the user authorization token, providing an authenticated request to an access-eligibility information server based on the user request; obtaining a service key to access the database from the access-eligibility information server based on the authenticated request; and accessing the database using the service key.

[0089]

[16] The computer program of

[15] further comprising: accessing data from the database; receiving return data from the database; and presenting the return data to the user, the return of data from the database comprising: receiving confidential data from the database; and anonymizing the confidential data to generate anonymized data.

[0090]

[17] The computer program of any one of

[15] or

[16] further comprising: automatically rotating the service key periodically through the access-eligibility information server.

[0091]

[18] The computer program of any one of

[15] to

[17] further comprises: analyzing, by the database, the service key received from the access eligibility information server, and identifying the service account and the service role associated with the database.

[0092]

[19] The computer program of any one of

[15] to

[18] , wherein the receiving of the user request to access the database comprises: presenting, to the user, a user interface via a web browser; and receiving, via the web browser, an HTTP request, wherein the HTTP request is the user request.

[0093]

[20] The computer program of any one of

[15] to

[19] , wherein the authenticating of the user comprises: providing, to a token authenticator, the user authorization token; and authenticating, by the token authenticator using the identification information provider, the identification information of the user based on the user authorization token.

[0094] Different use cases of these programs can be executed on any number of different computer systems, or can be distributed among such computer systems. Accordingly, although specific steps are set forth herein in connection with particular computer systems, software programs, processes, or entities, it is understood that various alternative implementations can be employed. It is further understood that the features of the various implementations can be interchanged, even if this is not explicitly stated.

[0095] Moreover, those skilled in the art will appreciate that the above-described technology can be practiced with a variety of computer system configurations, including personal computers, laptop computer systems, multi-core processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablet computers, pagers, wireless e-mail devices, and the like. Any device(s) can be used so long as the above-described technology can be practiced on the device(s). The embodiments described utilize terminology and nomenclature that is inherent to the particular technology or technical field in which the embodiments are utilized. However, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claims. Computer programs including the computer program of the above-described embodiments can also be stored and / or distributed as a computer program product, which can be stored and / or distributed on a storage medium or communication medium.

Claims

1. A method for authenticating user access to a database, the method using a multi-step process and a processor to authenticate user access to a database, the method comprising: receiving a user request for accessing a database, wherein the user request includes a user authorization token, a request identification information ID, and an event date; authenticating the user based on the user authorization token; in response to the user not being authenticated based on the user authorization token, denying the user access to the database; in response to the user being authenticated based on the user authorization token, providing an authenticated request to an access qualification information server based on the user request; obtaining a service key for accessing the database from the access qualification information server based on the authenticated request; and The database is accessed using the service key.

2. The method according to claim 1, wherein Also includes: accessing data from the database; receiving data back from the database; and presenting the returned data to the user.

3. The method according to claim 1 or 2, wherein: The accessing of the data from the database includes returning confidential data and anonymizing the confidential data to generate anonymized data.

4. The method according to any one of claims 1 to 3, wherein Also includes: The service key is automatically rotated periodically by the access qualification information server.

5. The method according to any one of claims 1 to 4, wherein Also includes: The service key received from the access qualification information server is analyzed through the database, and the service account and service role associated with the database are identified.

6. The method according to any one of claims 1 to 5, wherein The receiving of the user request to access the database comprises: presenting a user interface to the user via a web browser; and A Hypertext Transfer Protocol (HTTP) request is received via the web browser, wherein the HTTP request is the user request.

7. The method according to any one of claims 1 to 5, wherein The authentication of the user includes: providing the user authorization token to a token authenticator; and The identification information of the user is authenticated based on the user authorization token by using the token authenticator of the identification information provider.

8. A system for authenticating user access to a database, the system using a multi-step process to authenticate user access to a database, the system comprising: a memory storing computer-readable instructions; and a processor connected to the memory, The processor is configured to execute the computer-readable instructions to perform actions to: Receive a user request to access a database, wherein: The user request includes a user authorization token, a request identification information ID, and an event date; authenticating the user based on the user authorization token; in response to the user not being authenticated based on the user authorization token, denying the user access to the database; In response to the user being authenticated based on the user authorization token, providing an authenticated request to an access qualification information server based on the user request; obtaining, based on the authenticated request, a service key for accessing the database from the access qualification information server; as well as The database is accessed using the service key.

9. The system according to claim 8, wherein: The processor is further configured to access data from the database, receive return data from the database, and present the return data to the user.

10. The system according to claim 8 or 9, wherein: The processor is further configured to receive the data from the database by: receiving confidential data from the database; and anonymizing the confidential data to generate anonymized data.

11. The system according to any one of claims 8 to 10, wherein: The processor is further configured to automatically rotate the service key in the access qualification information server periodically.

12. The system according to any one of claims 8 to 11, wherein: The processor is further configured to analyze the service key received from the access qualification information server and identify the service account and service role associated with the database.

13. The system according to any one of claims 8 to 12, wherein: The processor is further configured to receive the user request to access the database by: presenting a user interface to the user via a web browser; and receiving a Hypertext Transfer Protocol (HTTP) request via the web browser, wherein the HTTP request is the user request.

14. The system according to any one of claims 8 to 13, wherein: The processor is further configured to authenticate the user by providing the user authorization token to a token authenticator, and receive authentication of the user from an identification information provider based on the user authorization token.

15. A computer program product for authenticating user access to a database, comprising a computer program, which, when executed by a processor, causes the processor to perform actions, wherein: The actions include: receiving a user request for accessing a database, wherein the user request includes a user authorization token, a request identification information ID, and an event date; authenticating the user based on the user authorization token; in response to the user not being authenticated based on the user authorization token, denying the user access to the database; In response to the user being authenticated based on the user authorization token, providing an authenticated request to an access qualification information server based on the user request; obtaining a service key for accessing the database from an access qualification information server based on the authenticated request; and The database is accessed using the service key.

16. The computer program product of claim 15, wherein: The actions further include: accessing data from the database; receiving return data from the database; and presenting the return data to the user, the receiving of the return data from the database including: receiving confidential data from the database; and anonymizing the confidential data to generate anonymized data.

17. The computer program product according to claim 15 or 16, wherein: The actions further include: automatically rotating the service key periodically via the access qualification information server.

18. The computer program product according to any one of claims 15 to 17, wherein: The actions further include: analyzing the service key received from the access qualification information server through the database, and identifying the service account and service role associated with the database.

19. The computer program product according to any one of claims 15 to 18, wherein: The receiving of the user request to access the database includes: presenting a user interface to the user via a web browser; and receiving a Hypertext Transfer Protocol (HTTP) request via the web browser, wherein the HTTP request is the user request.

20. The computer program product according to any one of claims 15 to 19, wherein: The authentication of the user includes: providing the user authorization token to a token authenticator; and authenticating identification information of the user based on the user authorization token by the token authenticator using an identification information provider.

Images