Multi-step process for authenticating access by user to database

Abstract

To provide a method, a system and a computer program for authenticating user access to a database by using a multi-step process.SOLUTION: A user request is received by a gateway API for accessing a database, and the user is authenticated by the gateway API on the basis of a user approval token. The user's access to the database is denied in response to non-authentication of the user by the gateway API on the basis of the user approval token, and the authenticated request is provided from the gateway API to an API handler in response to authentication of the user by the gateway API on the basis of the user approval token. Based on the authenticated request, the API handler acquires, from an access credential server, a service key for accessing the database by the API handler, and accesses the database by using the service key.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] SUMMARY OF THE INVENTION This specification relates to a multi-step process for authenticating access by a user to a database, and a method for using the multi-step process. [Background technology]

[0002] Market demand for intelligent driving functions is increasing, and safety is an influential factor in winning customer trust in intelligent driving. Safety testing includes on-site testing, public road performance verification, and virtual verification in the early stages of development. The degree of virtual scene simulation determines the comprehensiveness of safety performance verification for advanced driver assistance systems (ADAS) and autonomous driving systems. The current development process for ADAS systems and autonomous driving systems requires going through model-in-loop (MIL), software-in-loop (SIL), hardware-in-loop (HIL), driver-in-loop (DIL), and whole vehicle-in-loop (VIL). Driving scene libraries are a critical part of the development process and are implemented throughout the development process.

[0003] AV systems use sensors within the vehicle to collect information about the vehicle's performance or information related to the vehicle's surrounding environment. This information can be sent to a central server for inspection and analysis to help improve the vehicle's performance or gather information related to the environment in which the vehicle travels. In some examples, third parties, such as application developers, insurance companies, or government agencies, submit queries regarding information related to vehicle performance or the vehicle's surrounding environment. AVs collect large amounts of data daily, and the data is stored on a server, for example, a Market Data Collection (MDC) server. An ego-vehicle API interface is used to store the data in the MDC database. Summary of the Invention

[0004] In at least an embodiment, a method for authenticating access by a user to a database using a multi-step process includes receiving a user request to access the 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, the authenticated request is provided to an access credential server based on the user request. Based on the authenticated request, a service key for accessing the database is obtained from the access credential server. The database is accessed using the service key.

[0005] In at least one embodiment, a system for 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 operations to receive a user request to access the 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, the authenticated request is provided to an access credential server based on the user request. Based on the authenticated request, a service key for accessing the database is obtained from the access credential server. The database is accessed using the service key.

[0006] In at least one embodiment, a non-transitory computer-readable medium that, when executed by a processor, causes the processor to perform operations including 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, the authenticated request is provided to an access credential server based on the user request. Based on the authenticated request, a service key for accessing the database is obtained from the access credential server. The database is accessed using the service key. [Brief explanation of the drawings]

[0007] Aspects of the present disclosure are best understood from the following detailed description when read in conjunction with the accompanying drawings. It should be noted that, according to industry practice, various features have not been drawn to scale. In fact, the dimensions of various features may be increased or decreased for clarity of illustration.

[0008] [Figure 1] FIG. 1 illustrates data collection in an autonomous driving environment according to at least one embodiment. [Figure 2] Figure 2 shows the Lambda authorizer in action to authorize a user. [Figure 3] FIG. 3 illustrates a multi-step process for authenticating a user's access to a database (or other controlled resource) according to at least one embodiment. [Figure 4] FIG. 4 is a flowchart of a method for authenticating user access to a resource (eg, a database, server, or the like) using a multi-step process according to at least one embodiment. [Figure 5]FIG. 5 is a high-level functional block diagram of a processor-based system according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] The embodiments described herein set forth examples of implementing various features of the provided subject matter. To simplify the disclosure, examples of components, values, operations, materials, arrangements, or the like are described below. Of course, these are examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, or the like are contemplated. For example, the formation of a first feature above or on a second feature in the following description includes embodiments in which the first and second features are formed in direct contact, as well as embodiments in which an additional feature is formed between the first and second features such that the first and second features are not in direct contact. Additionally, the present disclosure repeats reference numerals and / or letters in various examples. This repetition is for the purposes of brevity and clarity and does not dictate a relationship between the various embodiments and / or configurations described.

[0010] Additionally, spatially relative terms such as "lower," "below," "belower than," "upper," "above," and the like are used herein for ease of description to describe the relationship of one element or feature to another element or feature as shown in the figures. Spatially relative terms are intended to encompass various orientations of the device in use or operation in addition to the orientation depicted in the figures. The device may be oriented differently (rotated 90 degrees or at other orientations), and the spatially relative descriptions used herein interpreted accordingly.

[0011] Terms such as "user equipment," "mobile station," "mobile," "mobile device," "subscriber station," "subscriber equipment," "access terminal," "terminal," "headset," and similar terms refer to wireless devices utilized by subscribers or users of wireless communication services to receive or transmit data, control, voice, video, audio, gaming, data streaming, or signaling streaming. These terms are used interchangeably in the subject specification and related drawings. The terms "access point," "base station," "Node B," "evolved Node B (eNode B)," next generation Node B (gNB), enhanced gNB (en-gNB), Home Node B (HNB)," "Home Access Point (HAP)," or the like, refer to wireless network components or devices that source and receive data, control, voice, video, audio, gaming, data streaming, or signaling streaming from UEs.

[0012] To enable data acquisition through the vehicle API, user authentication is performed. However, allowing users to have direct access to the database through authentication presents several problems. For example, because the database is large, it is more difficult to track what users are actually doing. Therefore, complex access boundary definitions are used. Users can also design complex queries to access data, but this is not scalable or maintainable. Furthermore, allowing a large number of users to access data in the database can lead to data leakage and make data encapsulation more difficult.

[0013] In at least one embodiment, a method is provided for authenticating user access to a database using a multi-step process. The method includes receiving a user request to access the 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, the authenticated request is provided to an access credential server based on the user request. Based on the authenticated request, a service key is obtained to access the database. The database is accessed using the service key.

[0014] The embodiments described herein provide a method that provides one or more advantages. For example, at least one embodiment of the method uses two authentication steps to access data stored in an external database. A user is authenticated at the HTTP API level by using an access token, but the token cannot be used to directly access the database. According to at least one embodiment, multiple authentication steps are involved. The first authentication is to authenticate the user using a user authentication token. The second authentication involves granting application access to the database. This forces the user to access the data through the API, allowing better query design by API developers that is automatically shared among API users. Also, because the user does not have direct access to the database, developers now have the opportunity to easily select and modify data encapsulation strategies through the API. For API implementations, the user is authenticated at the HTTP request side, but an application key is provided to access the database, which is not accessible or visible to the user.

[0015] Autonomous vehicles analyze data to understand where the vehicle is going, detect and avoid hazards, and safely transport passengers with little or no human input. Data collection involves acquiring 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. Real-time data about the environment, such as weather, road conditions, other vehicles, pedestrians, and road signs, combined with information about the vehicle and intelligence used to make immediate driving decisions, can generate several terabytes of data per hour for a single test vehicle. That data is analyzed for real-time events as managed by the vehicle, but later, the data is analyzed by the manufacturer on a scene-by-scene basis to identify new driving conditions that can be used to inform the AI ​​underlying the vehicle's autonomous operation.

[0016] The capabilities of the vehicle system can also be adjusted based on the priority level of the requesting user. For example, different users can have different priority levels for access to data. Priority levels are set based on the type of customer, e.g., government, police, retail, entertainment, etc. Additionally, software developers may seek access to databases to develop new applications.

[0017] FIG. 1 illustrates data collection in an autonomous driving environment 100 according to at least one embodiment.

[0018] 1 shows autonomous vehicles 110, 120, and 130. Autonomous vehicle 110 includes at least sensors 112 and 114. Autonomous vehicle 120 includes at least sensors 122 and 124. Autonomous vehicle 130 includes at least sensors 132 and 134. Autonomous vehicles 110, 120, and 130 may include more sensors. Such sensors include cameras, radio detection and ranging (RaDAR) sensors, light detection and ranging (LiDAR)-based sensors, infrared (IR) sensors, and the like.

[0019] Wireless communication among autonomous vehicles 110, 120, 130 refers to the exchange of information between these vehicles and other devices over network 140. Wireless communication allows data to be shared with other vehicles, infrastructure, and connected devices, such as traffic lights, road sensors, and the like. Sharing data via wireless communication enables a more coordinated and efficient transportation system. Wireless standards enable communication between autonomous vehicles, allowing them to exchange information such as speed, direction, and location. This communication helps them coordinate and avoid potential collisions, improving overall road safety.

[0020] Autonomous vehicles use a variety of 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 a network, these vehicles can access vast amounts of data, such as high-definition maps, weather conditions, traffic patterns, and updates regarding construction activities or accidents.

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

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

[0023] FIG. 2 illustrates the operation 200 of the Lambda authorizer to authorize a user.

[0024] 2, the functionality of the token authenticator 210 is used to control access to the HTTP API gateway 220. A user 222 logs into a third-party identity provider 240.

[0025] Third-party identity provider 240 creates, manages, and maintains identities for orchestration. After successful login, third-party identity provider 240 issues an access token to the client. Third-party identity provider 240 issues a cryptographically signed token to user 222, which contains information about the user identity and permissions associated with user 222.

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

[0027] The token validator 210 executes authorization logic to create an identity management policy (IAM). The token validator 210 invokes a function to authenticate the token with a third-party identity provider 240. The token validator 210 forwards the response to the API gateway 220.

[0028] API gateway 220 evaluates the IAM for the API gateway resource 250 (e.g., database, server, or the like) requested by user 222 to determine whether user 222 is authorized to access API gateway 220, and therefore API gateway resource 250. API gateway 220 either permits or denies the request by user 222. If permitted, API gateway 220 forwards the request from user 222 to API gateway resource 250.

[0029] FIG. 3 illustrates a multi-step process for authenticating a user's access to a database (or other controlled resource) 300 according to at least one embodiment.

[0030] In FIG. 3 , a 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 to generate an HTTP request 312 for vehicle data. The API 320 may also be 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 includes an authentication token 314 that the user obtains from an identity provider 330 to control access to the API 320, for example, as described above with reference to FIG. 2 . The authentication token (bearer token) 314 is either provided automatically when the user 310 uses a UI such as a data lens, or manually by the user 310 after first obtaining the authentication token 314 with the identity provider 330 after logging in to the identity provider 330 (as described above with reference to FIG. 2 ).

[0031] The API 320 forwards the authentication token 322 to the Lambda authorizer 340. The Lambda authorizer 340 invokes a Lambda function that authenticates the user 310 with the identity provider 330 based on the authentication token 322. The Lambda authorizer 340 then forwards the authentication response 342 to the API 320. Thus, the API 320 individually identifies the user and handles each authentication to the API 320 by the user 312 through the Lambda authorizer 340. The authentication response 342 can be used to indicate a failure to authorize the user or a success to authorize the user. For example, a failure to authorize the user can result in the authentication token 322 not being authenticated by the Lambda authorizer 340 / identity provider 330 or the authentication token 322 expiring in response to the user not providing the authentication token 314 in the HTTP request 312.

[0032] If authorization of user 310 fails, API 320 denies access to the data by user 310. In response to user 310 not being authenticated, e.g., not being authorized by the API gateway to access API 320, then user 310 cannot proceed further.

[0033] Upon successful authorization of the user 310, the API 320 sends an authenticated request 324, including the request ID and the event date, to the API handler 350.

[0034] Based on the authenticated request 324, the API handler 350 obtains a database service key 362 from an access credential server 360 to access a resource (e.g., a database 370, a server, or the like). Thus, the API handler 350 obtains its own credentials for the external database 370. The service role and asymmetric access key (database service key 362) associated with the database 370 are used to determine whether the API 320 is allowed to access tables in the database 370. The user 310 creates a service role, and the user's 310 private key is registered in the database 370 so that the database 370 can grant access to data in the database 370 based on the service role. The service role identifies the user 310, who represents the HTTP API service in the database 370. Thus, while access to the API 320 is controlled on a per-user basis, access to the database 370 is controlled through the service account and service role for the user 310 associated with the data in the database 370, based on the database service key 362. Services such as database 370 store and use secrets in access credential server 360. Access credential server 360 is a secure and convenient storage system for API keys, passwords, certificates, and other sensitive data. Access credential server 360 provides a central location and single source of truth to manage, access, and audit secrets across the cloud. Access credential server 360 manages, retrieves, and rotates database credentials, application credentials, OAuth tokens, API keys, and other secrets throughout their lifecycle. Database service key 362 in access credential server 360 is periodically rotated by using the database 370 configuration for user 310 and the ability to update the public key (database service key 362) in access credential server 360.For example, the database service key 362 can be automatically rotated each month.

[0035] API handler 350 sends data requests 352 for data in database 370 based on the role associated with database servicer key 362. Data requests 352 include a request ID, event data, a database service key, and the like, to access database 370.

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

[0037] In response to the data request 352 (request ID, event data, database service key, and the like), the database 370 returns the non-anonymized sensor data 372 (e.g., sensitive data) in the database 370 to the API handler 350.

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

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

[0040] According to at least one embodiment, to enable access to a resource (e.g., database 370, server, or the like), API handler 350 obtains database service key 362 from access credential server 360 and makes data request 352 for data to database 370 using database service key 362. User 310 creates an asymmetric key pair for the application, stores a private key (database service key 362) in access credential server 360 that is obtained by API handler 350 to access database 370, generates a public key (database service key 362) from the private key, and registers the public key (database service key 362) in database 370 where the public key (database service key 362) is associated with user 310. A role is created, and the role identifies user 310 to be associated with an HTTP API service in database 370. The user's public key (database service key 362) is registered in database 370, and the associated role is given to user 310 through API handler 350.

[0041] Having individual users 310 access database 370 directly or simply through a single API handler 350 is problematic. For example, allowing an application to have its own database service key 362 allows users to establish a session with a token and validate the session. However, having a single level of authentication to access database 370 does not provide granular configuration at the user level for determining access to data in database 370 and therefore makes data leakage much more likely. Database 370 often has billions of records, making it difficult to control access to records using a single level of authentication. Therefore, at least one embodiment prevents users from directly accessing database 370 but instead provides a level of data encapsulation, with data provided through API 320 and API handler 350. API handler 350 not only interfaces with database 370 but also restricts the queries that can be issued to database 370 based on database service key 362 obtained from access credential server 360.

[0042] Another problem is that users 310 do not know where the data is located in the database 370. Therefore, other benefits of not giving users direct access to the data include anonymizing the data and making data extraction more efficient. An alternative is to allow many users direct access to the database using large queries and multi-step authentication. This is similar to a restaurant where a menu is provided to users to make ordering more efficient, rather than allowing users to access a pantry to decide what they want to order. In other words, by giving users the freedom to code their queries, users often construct inefficient queries. For example, a user may construct the same query in a way that can overload the system by using more resources to retrieve data in response to the query. Without knowing where the data is located and how to design an efficient query, users 310 may access data that they are not authorized to access. Therefore, the embodiments described herein provide access to data that is not only more secure, but also provides a more stable system.

[0043] FIG. 4 is a flowchart 400 of a method for authenticating user access to a database using a multi-step process according to at least one embodiment.

[0044] 4, the process begins (S402) and a user request to access a resource (e.g., a database, server, or the like) is received at an application programming interface (API), where the user request includes a user authorization token, a request identification (ID), and an event date (S410). Referring to FIG. 3, a 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 to generate an HTTP request 312 for vehicle data. The API 320 may also be referred to as a gateway API. Through the web browser, the user 310 can provide the request identification (ID) and the event date to the API 320 through the HTTP request 312. The HTTP request 312 also includes an authentication token 314 that the user obtains from an identity provider 330 to control access to the API 320, for example, as described above with reference to FIG. 2. The authentication token (bearer token) 314 is either provided automatically when the user 310 uses a UI such as DataLens, or manually by the user 310 after first obtaining the authentication token 314 with the identity provider 330 after logging in to the identity provider 330 (as described above with reference to FIG. 2).

[0045] A determination is made whether the user is authenticated based on the user authorization token (S414).

[0046] In response to the user not being authenticated at the API based on the user authorization token, access to the resource is denied (S418). Referring to Figure 3, if authorization of user 310 fails, API 320 denies user 310 access to the data. In response to user 310 not being authenticated, e.g., not being authorized to access API 320, then user 310 cannot proceed further.

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

[0048] The user at the API is authenticated based on the user authorization token (S430). Referring to FIG. 3 , the API 320 forwards the authentication token 322 to the token authenticator 340. The token authenticator 340 invokes a function to authenticate the user 310 with the identity provider 330 based on the authentication token 322. The token authenticator 340 then forwards an authentication response 342 to the API 320. Thus, the API 320 individually identifies the user and processes the individual authentication by the user 312 to the API 320 through the token authenticator 340. The authentication response 342 can be used to indicate a failure to authenticate the user or a success to authenticate the user. For example, a failure to authenticate the user can result in the authentication token 322 not being authenticated by the token authenticator 340 / identity provider 330 or the authentication token 322 expiring in response to the user not providing an authentication token in the HTTP request 312.

[0049] In response to the user being authenticated at the API based on the user authorization token, an authenticated request is provided from the API to the API handler based on the user request (S434). Referring to Figure 3, upon successful authorization of the user 310, the API 320 sends the authenticated request 324, including the request ID and the event date, to the API handler 350.

[0050] Based on the authenticated request, the API handler obtains a service key from the access credential server to access the database through the API handler (S438). Referring to FIG. 3 , based on the authenticated request 324, the API handler 350 obtains a database service key 362 from the access credential server 360 to access a resource (e.g., database 370, server, or the like). Thus, the API handler 350 obtains its own credentials for the external database 370. The service role and asymmetric access key (database service key 362) associated with the database 370 are used to determine whether the API 320 is allowed to access tables in the database 370. The user 310 creates a service role, and the user 310's private key is registered in the database 370 so that the database 370 can grant access to data in the database 370 based on the service role. The service role identifies the user 310, who represents an HTTP API service in the database 370. Thus, access to API 320 is controlled on a per-user basis, while access to database 370 is controlled through service accounts and service roles for user 310 that are associated with data in database 370 based on database service key 362. Services such as database 370 store and use secrets in access credential server 360, which is a secure and convenient storage system for API keys, passwords, certificates, and other sensitive data. Access credential server 360 provides a central location and single source of truth to manage, access, and audit secrets across the cloud. Access credential server 360 manages, retrieves, and rotates database credentials, application credentials, OAuth tokens, API keys, and other secrets throughout their lifecycle.The database service key 362 in the access credential server 360 is rotated periodically by using a configuration of the database 370 for the user 310 and a function that updates the public key (database service key 362) in the access credential server 360. For example, the database service key 362 can be automatically rotated each month.

[0051] The API handler accesses the database using the service key (S438). Referring to Figure 3, the API handler 350 sends a data request 352 for data in the database 370 based on the role associated with the database servicer key 362. The data request 352 includes a request ID, event data, a database service key, and the like, to access the database 370.

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

[0053] The data from the database is returned to the API handler (S446). Referring to Figure 3, in response to the data request 352 (request ID, event data, database service key, and the like), the database 370 returns the non-anonymized sensor data 372 (e.g., sensitive data) in the database 370 to the API handler 350.

[0054] The data returned from the database to the API handler is provided to the API (S450). Referring to Figure 3, the API handler 350 anonymizes the sensitive data (e.g., converts the sensitive data to anonymized data) to generate anonymized data 354 and provides the anonymized data 354 to the API 320.

[0055] The returned data is presented to the user 454. Referring to Figure 3, the API 320 then provides the anonymized original data 326 to the user 310.

[0056] The service key is automatically rotated periodically by the access credential server (S458). Referring to FIG. 3, the access credential server 360 provides a central location and single source of truth for managing, accessing, and auditing secrets across the cloud. The access credential server 360 manages, retrieves, and rotates database credentials, application credentials, OAuth tokens, API keys, and other secrets throughout their lifecycle. The database service key 362 in the access credential server 360 is rotated periodically by using the configuration of the database 370 for the user 310 and a function that updates the public key (database service key 362) in the access credential server 360. For example, the database service key 362 can be automatically rotated each month.

[0057] The process then ends (S470).

[0058] At least one embodiment provides a method for authenticating user access to a database using a multi-step process. The method includes receiving, at 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 at the gateway API based on the user authorization token. In response to the user not being authenticated at the gateway API based on the user authorization token, the user is denied access to the resource. In response to the user being authenticated at 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. Based on the authenticated request, the API handler obtains a service key from an access credential server to access the database by the API handler. The API handler accesses the database using the service key.

[0059] FIG. 5 is a high-level functional block diagram of a processor-based system 500 according to at least one embodiment.

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

[0061] The processor 502 is electrically connected to a 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 by the bus 508. A network interface 512 is also electrically connected to the processor 502 via the bus 508. The network interface 512 is connected to a network 514, such that the processor 502 and the non-transitory computer-readable storage medium 504 connect to external elements via the network 514. The processor 502 is configured to execute instructions 506 encoded in the non-transitory computer-readable storage medium 504 to enable the processing circuit 500 to perform at least portions of processes and / or methods. In one or more embodiments, the processor 502 is a central processing unit (CPU), a multiprocessor, a distributed processing system, an application-specific integrated circuit (ASIC), and / or suitable processing unit.

[0062] Processing circuit 500 includes an I / O interface 510. I / O interface 510 is connected to external circuitry. In one or more embodiments, I / O interface 510 includes a keyboard, keypad, mouse, trackball, trackpad, touchscreen, and / or cursor direction keys that communicate information and commands to processor 502.

[0063] The processing circuit 500 also includes a network interface 512 coupled to the processor 502. The network interface 512 enables the processing circuit 500 to communicate with a network 514 to which one or more other computer systems are connected. The network interface 512 may include a wireless network interface, such as Bluetooth, Wi-Fi, Worldwide Interoperable 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.

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

[0065] In one or more embodiments, one or more non-transitory computer-readable storage media 504 have stored thereon instructions 506 (in compressed or uncompressed form) that can be used to program a computer, processor, or other electronic device to perform the processes or methods described herein. The one or more non-transitory computer-readable storage media 504 include one or more of an electronic storage medium, a magnetic storage medium, an optical storage medium, a quantum storage medium, or the like.

[0066] For example, non-transitory computer-readable storage medium 504 may include, but is not limited to, a hard drive, a floppy diskette, an optical disk, 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 other type of physical medium suitable for storing electronic instructions. In one or more embodiments using optical disks, one or more non-transitory computer-readable storage medium 504 includes a compact disk read-only memory (CD-ROM), a compact disk read / write (CD-R / W), and / or a digital video disk (DVD).

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

[0068] Thus, in at least one embodiment, the processor 502 executes instructions 506 stored on one or more non-transitory computer-readable storage media 504 to implement a multi-step process for authenticating a user's access to a database. The user interface 520 presents information 522 including an HTTP request, an authenticated request, data, and the like. The user interface 520 also presents at least an application programming interface (API) 524 and an API handler 526. The processor 502 receives an HTTP request 530 at the API 540 for a user to access a resource (e.g., a database 570, a server, or the like), the HTTP request 530 including a user authorization token, a request identification (ID), and an event date 532. The processor 502 presents the user interface of the API 540 to the user via a web browser and receives the HTTP request 530 at the API 540 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 the token authenticator 542, and the processor causes the token authenticator 542 to send the authentication token 532 from the HTTP request 530 to the identity provider 544. The processor 502 causes the identity provider 544 to return an authentication response 546 to the token authenticator 542 based on the authentication token 532, and the token authenticator 542 returns the authentication response 546 to the API 540. In response to the user not being authenticated at 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 at the API 540 based on the authorization token 532, the processor 502 causes the API 540 to send an authenticated request 550 to the 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 the access credential server 558 to access the database 570 via the API handler 552 .The processor 502 causes the API handler 552 to send a data request 560 to a database 570, the data request 560 including a request ID, an event date, and a database service key 562. The database 570 stores non-anonymized data 572. The processor 502 causes the database 570 to analyze a 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 retrieves data 574 from the database 570 in response to the data service key 554 including non-anonymized data 576, which is returned to the API handler 552. The processor 502 uses the API handler 552 to anonymize the non-anonymized data 576 to generate anonymized data 578, and provides the anonymized data to the API 540, where the anonymized data 578 is presented to the user. The processor 502 automatically periodically rotates the database service key 554 in the access credential server 558. Display 590 presents a user interface (UI) 592 that presents information 594 including HTTP requests, authenticated requests, and data, e.g., data retrieved from database 570. UI 592 also presents API 596 and vehicle handler 598 as described above.

[0069] The embodiments described herein provide a method that provides one or more advantages. For example, at least one embodiment of the method 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 by using an access token, but the token cannot be used to directly access the database. According to at least one embodiment, multiple steps of authentication are involved. The first authentication is to authenticate the user. The second authentication involves granting application access to the database. This forces users to access the data through the API, allowing better query design by API developers that is automatically shared among API users. Also, because users do not have direct access to the database, developers now have the opportunity to easily select and modify data encapsulation strategies through the API. For API implementations, the user is authenticated at the HTTP request side, but an application key is provided to access the database, which is not accessible or visible to the user.

[0070] Aspects of the present specification are directed to a method [1] for authenticating, by a processor, access by a user to a database using a multi-step process, including receiving a user request to access the database, the user request including a user authorization token, a request identification (ID), and an event date; authenticating the user based on the user authorization token; denying the user access to the database in response to the user not being authenticated based on the user authorization token; providing the authenticated request to an access credential server based on the user request; obtaining a service key from the access credential server based on the authenticated request to access the database; and accessing the database using the service key.

[0071] [2] The method described in [1] further includes accessing data from a database, receiving returned data from the database, and presenting the returned data to a user.

[0072] [3] The method of any one of [1] or [2], wherein returning data from the database includes returning sensitive data and anonymizing the sensitive data to generate anonymized data.

[0073] [4] The method described in any one of [1] to [3] further includes automatically rotating the service key periodically by a secret manager.

[0074] [5] The method described in any one of [1] to [4] further includes analyzing, by the database, the service key received from the access credential server to identify a service account and a service role associated with the database.

[0075] [6] The method of any one of [1] to [5], wherein receiving a user request to access a database includes presenting a user interface to a user via a web browser, and receiving an HTTP request via the web browser, the HTTP request being the user request.

[0076] [7] The method of any one of [1] to [5], wherein authenticating the user includes providing a user authorization token to a token authenticator; and authenticating the identity of the user based on the user authorization token by the token authenticator using an identity provider.

[0077] Aspects of the present specification are directed to a system [8] for authenticating user access to a database using a multi-step process, the system including a memory storing computer-readable instructions and a processor coupled to the memory, the processor configured to execute the computer-readable instructions to perform operations to receive a user request to access the database, the user request including a user authorization token, a request identification (ID), and an event date; authenticate the user based on the user authorization token; deny the user access to the database in response to the user not being authenticated based on the user authorization token; provide the authenticated request to an access credential server based on the user request; obtain a service key from the access credential server based on the authenticated request to access the database; and access the database using the service key.

[0078] [9] The system of [8], wherein the processor is further configured to receive data from the database, receive return data from the database, and present the return data to a user.

[0079]

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

[0080]

[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 credential server.

[0081]

[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 credential server to identify a service account and a service role associated with the database.

[0082]

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

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

[0083]

[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 the token authenticator, and receive authentication of the user from the identity provider based on the user authorization token.

[0084] Aspects of the present specification are directed to a computer program product

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

[0085]

[16] The computer program described in

[15] further includes accessing data from a database, receiving returned data from the database, and presenting the returned data to a user, wherein returning data from the database includes receiving sensitive data from the database and anonymizing the sensitive data to generate anonymized data.

[0086]

[17] The computer program of any one of

[15] or

[16] further comprises automatically rotating the service key periodically by the access credential server.

[0087]

[18] The computer program described in any one of

[15] to

[17] further includes analyzing, by the database, the service key received from the access credential server to identify a service account and a service role associated with the database.

[0088]

[19] The computer program of any one of

[15] to

[18] , wherein receiving a user request to access a database includes presenting a user interface to the user via a web browser, and receiving an HTTP request via the web browser, the HTTP request being the user request.

[0089]

[20] The computer program of any one of

[15] to

[19] , wherein authenticating the user includes providing a user authorization token to a token authenticator, and authenticating the identity of the user based on the user authorization token by the token authenticator using an identity provider.

[0090] Separate instances of these programs may be running on or distributed among any number of separate computer systems. Thus, although particular steps are described as being performed by particular devices, software programs, processes, or entities, this is not required. Various alternative implementations will be appreciated by those skilled in the art.

[0091] Furthermore, those skilled in the art will readily appreciate that the above-described techniques may be utilized in a variety of devices, environments, and situations. Although the embodiments have been described in terms specific to structural features or method acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

Claims

1. 1. A method for authenticating access by a user to a database using a multi-step process by a processor, comprising: receiving a user request to access a database, the user request including a user authorization token, a request identification (ID), and an event date; authenticating the user based on the user authorization token; denying the user access to the database in response to the user not being authenticated based on the user authorization token; providing an authenticated request to an access credential server based on the user request in response to the user being authenticated based on the user authorization token; obtaining a service key from the access credential server for accessing the database based on the authenticated request; accessing the database using the service key; Including, method.

2. accessing data from the database; receiving returned data from the database; and presenting the returned data to the user. The method of claim 1.

3. said accessing said data from said database includes returning sensitive data; and anonymizing said sensitive data to generate anonymized data. The method of claim 2.

4. further comprising automatically rotating the service key periodically by the access credential server. The method according to any one of claims 1 to 3.

5. analyzing, by the database, the service key received from the access credential server to identify a service account and a service role associated with the database. The method according to any one of claims 1 to 3.

6. said receiving said user request to access said database comprising: presenting a user interface to the user via a web browser; receiving an HTTP request via the web browser, the HTTP request being the user request; Including, The method according to any one of claims 1 to 3.

7. The authentication of the user includes: providing the user authorization token to a token authenticator; authenticating, by the token authenticator using an identity provider, the identity of the user based on the user authorization token; Including, The method according to any one of claims 1 to 3.

8. 1. A system for authenticating user access to a database using a multi-step process, comprising: a memory storing computer readable instructions; a processor connected to the memory; wherein the processor executes the computer-readable instructions to perform operations, receiving a user request to access a database, the user request including a user authorization token, a request identification (ID), and an event date; authenticating the user based on the user authorization token; denying the user access to the database in response to the user not being authenticated based on the user authorization token; providing an authenticated request to an access credential server based on the user request in response to the user being authenticated based on the user authorization token; obtaining a service key from the access credential server for accessing the database based on the authenticated request; accessing the database using the service key; configured to: system.

9. 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. The system of claim 8.

10. the processor is further configured to receive sensitive data from the database by: receiving the data from the database; and anonymizing the sensitive data to generate anonymized data. The system of claim 9.

11. the processor is further configured to automatically rotate the service key periodically at the access credential server. A system according to any one of claims 8 to 10.

12. the processor is further configured to analyze the service key received from the access credential server to identify a service account and a service role associated with the database. A system according to any one of claims 8 to 10.

13. 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, the HTTP request being the user request. A system according to any one of claims 8 to 10.

14. the processor is further configured to authenticate the user by providing the user authorization token to a token authenticator, and to receive authentication of the user from an identity provider based on the user authorization token. A system according to any one of claims 8 to 10.

15. A computer program which, when executed by a processor, causes the processor to perform operations, said operations comprising: receiving a user request to access a database, the user request including a user authorization token, a request identification (ID), and an event date; authenticating a user based on the user authorization token; denying the user access to the database in response to the user not being authenticated based on the user authorization token; providing an authenticated request to an access credential server based on the user request in response to the user being authenticated based on the user authorization token; obtaining a service key for accessing the database from an access credential server based on the authenticated request; accessing the database using the service key; Including, Computer program.

16. accessing data from the database; receiving return data from the database; and presenting the return data to the user, wherein the receiving of the return data from the database includes receiving sensitive data from the database; and anonymizing the sensitive data to generate anonymized data.

16. A computer program according to claim 15.

17. further comprising automatically rotating the service key periodically by the access credential server.

17. A computer program according to claim 15 or claim 16.

18. analyzing, by the database, the service key received from the access credential server to identify a service account and a service role associated with the database.

17. A computer program according to claim 15 or claim 16.

19. receiving the user request to access the database includes presenting a user interface to the user via a web browser; and receiving an HTTP request via the web browser, the HTTP request being the user request.

17. A computer program according to claim 15 or claim 16.

20. the authenticating of the user includes providing the user authorization token to a token authenticator; and authenticating the identity of the user by the token authenticator using an identity provider based on the user authorization token.

17. A computer program according to claim 15 or claim 16.

Images