Selective security enhancements in source control environments

Abstract

A method for enforcing authentication requirements for documents of a document repository based at least in part on a security policy associated with a branch under which the document is organized. The method implements an approval service identified in a branch policy. The approval service determines whether a user is authorized to modify a document included in a branch. The method further selectively requires multiple authentications from multiple authentication systems in order to access one or more specific branches in the document repository. In addition, the multiple authentication systems are based on separate and independent sets of authentication credentials.

Description

Background Art

[0001] Despite the great strides made over the past few decades, risks still exist in the security of electronic systems. Some of these risks are related to malicious actors outside the enterprise who have successfully usurped traditional means of protecting enterprise resources. For example, malicious actors can illegally or otherwise obtain authentication credentials that provide access to enterprise resources. In some cases, software with relatively strong security protections may still include vulnerabilities that may be discovered and exploited by malicious actors with sufficient skills and resources to identify these vulnerabilities. Vulnerabilities also exist within the software organization that develops the software. If vulnerabilities may be intentionally included in a software product that is ultimately released to the public, these vulnerabilities can be exploited. Such exploitation may result in the compromise of customer data of the software product. Therefore, there is a need to improve computer security to further reduce the risks associated with the operation and development of computer software. Summary of the invention

[0002] A method implemented by an example device according to the present disclosure includes performing a first authentication on an account that is to access a document repository via a first authentication system; receiving a request from the account to submit a document to the document repository; decoding the request based on the first authentication; identifying a first branch of the document repository based on the decoding; determining that the first branch requires a second authentication; performing a second authentication on the account via a second authentication system in response to the required second authentication; and submitting the document to the first branch of the document repository based on the second authentication.

[0003] A computing system comprises: a hardware processing circuit; and one or more hardware memories storing instructions, wherein the instructions, when executed, configure the hardware processing circuit to perform operations including: performing a first authentication on an account to access a document repository via a first authentication system; receiving a request from the account to submit a document to the document repository; decoding the request based on the first authentication; identifying a first branch of the document repository based on the decoding; determining that the first branch requires a second authentication; performing a second authentication on the account via a second authentication system in response to the required second authentication; and submitting the document to the first branch of the document repository based on the second authentication.

[0004] A non-transitory computer-readable storage medium comprising instructions which, when executed, configure hardware processing circuitry to perform operations comprising: performing a first authentication, via a first authentication system, of an account to access a document repository; receiving a request from the account to submit a document to the document repository; decoding the request based on the first authentication; identifying a first branch of the document repository based on the decoding; determining that the first branch requires a second authentication; performing a second authentication, via a second authentication system, of the account in response to the required second authentication; and submitting the document to the first branch of the document repository based on the second authentication. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is an overview diagram of a system that implements one or more disclosed embodiments.

[0006] Figure 2 An example of document branches maintained by version control system 102 in an example embodiment is shown.

[0007] Figure 3 Example data structures implemented in one or more disclosed embodiments are shown.

[0008] Figure 4 Example message portions implemented by one or more disclosed embodiments are shown.

[0009] Figure 5 An example structure of version control branches is shown.

[0010] Figure 6 is a sequence diagram illustrating the flow of messages between components included in one or more disclosed embodiments.

[0011] Figure 7 is a flow chart of a method for authenticating a branch of a version control system.

[0012] Figure 8 A block diagram of an example machine 800 is shown upon which any one or more of the techniques (eg, methodologies) discussed herein may be performed. DETAILED DESCRIPTION

[0013] As discussed above, the current state of the art in computer security presents the following technical problem: It remains possible for malicious actors to gain unauthorized access to computer resources. This can occur through the malicious actor obtaining authentication credentials, which enables them to access computer resources protected by those credentials. Unauthorized access can also occur when a malicious actor obtains access to computer resources, such as as part of their employment. The malicious actor then abuses their access rights to achieve their own malicious purposes outside the scope of their employment.

[0014] The disclosed embodiments propose a technical solution to the technical problem. As described above, the technical solution reduces the ability of malicious actors to obtain unauthorized access rights. Some of these embodiments define a security policy for a branch of a version control system. The security policy defines one or more authentications that must be completed before access rights to a particular portion or branch of a document repository are granted to an account (based on one or more optional criteria).

[0015] In some embodiments, whether authentication is required depends on which branch of the version control system is being accessed. Some branches, such as those used by software engineers for their own development work and testing, are less authenticated than other branches whose documents are used to generate executable images distributed to or run on behalf of customers. By making the amount of authentication required for access different based on the branch being accessed, flexibility of access can be maintained. This flexibility minimizes the additional burden on software engineers in their daily work while providing additional security when it matters most, such as when software engineering work product is submitted to a branch used to generate running software for customer use.

[0016] In order to obtain additional flexibility in applying additional authentication processes, some embodiments condition additional authentication on one or more criteria, including the specific portion of the branch being accessed, the amount of data being accessed, or the geographic region or network domain where the requesting user is located (or not located). For example, some modifications to the operating system code, such as modifications to user space applications, can be considered less critical, so at least in some embodiments, such modifications can be made without additional authentication. At least in some embodiments, changes to the operating system kernel code or any code running in the kernel space are considered more critical to system security, so additional authentication is required. Therefore, due to the additional security provided by these embodiments, engineers responsible for assisting user space work may not bear additional burdens, while changes to kernel modules will require enhanced authentication processes. Similarly, some embodiments control the amount of authentication required based on the size of the portion of the document repository being accessed. As an example, in some embodiments, if a user requests to check out the entire operating system kernel of a specific branch, additional authentication is required. In some embodiments, the checkout of a single kernel file on the same specific branch does not require additional authentication.

[0017] Thus, the disclosed embodiments provide a flexible approach for providing additional security in a document version control system that increases the level of security where appropriate while minimizing the overhead imposed on software engineers in their day-to-day work and on computing systems that would otherwise have to perform additional security operations.

[0018] Figure 1 is an overview diagram of a system that implements one or more disclosed embodiments. Figure 1 A version control system (VCS) 102 is shown accessing a document repository 104. The document repository 104 stores source code for a software product. The code repository is controlled by the VCS 102, which provides controlled access to the document repository 104. For example, if a client device 106 is logged into an account with sufficient privileges, a copy of at least a portion of the software stored in the document repository 104 can be obtained. Figure 1 In an example embodiment of the present invention, the enterprise authentication system 108 provides access to the document repository 104 via the VCS 102. When authenticating access to the enterprise resources 112 and / or the document repository 104, the enterprise authentication system 108 consults the enterprise authentication data store 110 to verify the credentials provided by the client device 106. The enterprise authentication system 108 associates the account with the first set of credentials. Therefore, when providing access to the document repository 104, the VCS 102 is configured to require that the account attempting access has previously been authenticated by the enterprise authentication system 108.

[0019] The example system 100 also includes a build repository 120. The build repository receives code from a build system 122. The build system 122 receives code from the document repository 104 and compiles or otherwise processes the code received from the code repository to generate one or more executable images, which are stored in the build repository 120.

[0020] The system 100 also includes a data center 114. The data center 114 hosts one or more applications that are accessible via a network 109 via a firewall 107. Permission to modify any file (e.g., an executable file) in the data center 114 is provided via a second authentication system 116, which relies on a second authentication data store 118. For example, the second authentication data store 118 defines authentication credentials that are separate and independent from the enterprise authentication data store 110. The executable image generated by the build system 122 and stored in the build repository 120 is written to the data center 114 under certain conditions, such as during a recent release of software operating in the data center 114. In Figure 1 In the example embodiment of FIG. 1 , in order to update the software running in the data center 114 , authentication via the second authentication system 116 is required.

[0021] Figure 1 Also shown is an approval server 124. VCS 102 is configured to implement a branch-specific policy that requires additional approval from approval server 124 before any changes are made to a particular branch. In some embodiments, approval server 124 executes or runs an approval service that provides one or more functions attributed to an approval server, as described below.

[0022] If the particular branch is configured so that approval by the approval server 124 is required, the VCS 102 requests such approval from the approval server 124. In some embodiments, the approval server 124 is configured to obtain authentication of the user via the second authentication system 116 before approving the particular user to modify the particular branch. Again, this additional authentication is defined by a policy specific to the particular branch maintained by the VCS 102. The second authentication system 116 is configured to associate the account with the second set of credentials. After successfully obtaining authentication of the user via the second authentication system 116, the approval service approves the user's modification of the branch and provides this information back to the VCS 102.

[0023] Figure 2 An example of a document branch 200 maintained by VCS 102 in an example embodiment is shown. Figure 2Mainline branch 202 is shown. Development branch 204 receives a copy of the mainline branch at branching operation 206 such that checkpoint 208 of development branch 204 includes documents that are equivalent to documents at checkpoint 210 of mainline branch 202 .

[0024] A feature branch 212 is created from a checkpoint 214 of the development branch 204, so that a checkpoint 216 of the feature branch 212 includes documents equivalent to the checkpoint 214 of the development branch 204. The documents at the checkpoint 218 of the feature branch 212 are integrated with the documents at the checkpoint 220 of the development branch 204. The documents at the checkpoint 222 of the release branch 224 are integrated with the documents at the checkpoint 226 of the mainline branch 202.

[0025] At least some of the disclosed embodiments associate a security policy with one or more of the mainline branch 202, or the development branch 204, the feature branch 212, or the release branch 224. The security policy designates one or more criteria that must be met before providing access to a branch. In some embodiments, read access to a branch is associated with a first security policy, and write access to a branch is associated with a second security policy.

[0026] In some embodiments, the security policy associated with the branch specifies one or more authentications required to access the branch. For example, in some embodiments, the security policy specifies that access to the branch associated with the security policy requires authentication by the enterprise authentication system 108. In some embodiments, the security policy also requires authentication by the second authentication system 116 before providing access to the branch.

[0027] Some embodiments determine one or more specified authentications based on the type of access provided. For example, in some embodiments, read access to a branch requires only authentication by a single authentication system (e.g., enterprise authentication system 108), while write access to a branch requires authentication by at least two authentication systems (e.g., enterprise authentication system 108 and second authentication system 116).

[0028] Some embodiments determine one or more specified authentications based on the amount of data accessed on the branch. For example, in some embodiments, authentication is required if the number of files or bytes requested to be accessed exceeds a threshold (e.g., a threshold defined by a security policy).

[0029] Some embodiments determine one or more specified authentications based on the location of the user / account requesting access. Thus, for example, in some embodiments, if the account requesting access is requesting access from within a predefined geographic area (e.g., corresponding to a corporate campus), then a specified authentication is not required. In some other embodiments, if the requested access is from a defined geographic area, then a specified authentication is required. In some embodiments, this location-based requirement for additional authentication is also based on which branch is being accessed. Thus, in some embodiments, one or more branches do not have additional authentication requirements based on client location, while another branch does have additional authentication under certain location conditions.

[0030] Figure 3 An example data structure implemented in one or more disclosed embodiments is shown. Figure 3 The example data structure discussed is a relational database table, but various embodiments will utilize various known data architectures. For example, some embodiments implement one or more of the following: a relational database table, an unstructured data store, a traditional memory structure (e.g., a linked list, a tree, an array), or other data structure architectures. Figure 3 The examples provided in are in no way intended to limit the data structures used by one or more disclosed embodiments.

[0031] Figure 3 301, security policy table 311, authentication table 321, criteria table 331, and document table 341 are shown. Branch table 301 includes branch identifier field 304 and security policy identifier field 306. Branch identifier field 304 uniquely identifies a branch, such as Figure 2 Any of mainline branch 202, development branch 204, feature branch 212, or release branch 224 is discussed. Security policy identifier field 306 identifies the security policy of security policy table 311, discussed further below, that applies to the branch (identified by field 304).

[0032] The security policy table 311 includes a security policy identifier field 312, an authentication identifier field 314, an access type field 316, a data size field 318, and a location field 319. The security policy identifier field 312 uniquely identifies the security policy and can be cross-referenced with the security policy identifier field 306. The authentication identifier field 314 identifies the authentication required to allow access to the branch (subject to any criteria associated with the authentication, as discussed further below). The access type field 316 defines the access type controlled by the authentication. In various embodiments, the access type field 316 identifies read access, write access, or read and write access. Additional access types supported by some embodiments include branch deletion access. The data size field 318 optionally defines a data size limit that requires additional authentication defined by field 314 when exceeded. For example, if the amount of data requested is less than the amount defined by the data size field 318, then an example embodiment does not require additional authentication when modifying the first branch, but requires additional authentication when modifying the second branch if the amount of data requested is less than the second amount defined by the data size field 318 (e.g., the first and second branches will have two different security policies that define different data size limits). Note that to prevent users from bypassing data size limits for specific operations, some embodiments track the amount of data retrieved by a particular account or user over a predefined time period, or only the amount of data retrieved by a particular account during the history of that account. This tracked amount is then compared to the data size specified by the data size field 318 for the particular branch to determine whether additional authentication is necessary.

[0033] The location field 319 defines a location where additional authentication is or is not required. For example, in some embodiments, the location field 319 defines a location when additional authentication is required (e.g., a specific country or geographic region on Earth). If the client device requesting data from the branch is not within the specified area, at least the location field 319 does not require a second authentication. In some embodiments, the location field 319 defines a geographic area where a second authentication is not required. For example, in an example embodiment, the location field 319 defines a corporate campus or other secure area where additional authentication is not required. Some embodiments provide multiple location fields to be included in the security policy defined by the security policy table. In these embodiments, the location parameters specified by each location field are considered when determining whether additional authentication is required. Each location parameter (e.g., two different geographic areas require authentication) can be evaluated via a logical and or logical or operation.

[0034] Note that in some embodiments, multiple rows in security policy table 311 specify the same security policy identifier value. In this way, a security policy can specify more than one authentication (or more than one conditional authentication) for a single branch (or multiple branches if multiple branches reference the same security policy identifier).

[0035] Authentication table 321 includes authentication identifier field 322, authentication server field 324, authentication domain field 326, and authentication criteria list field 328. Authentication identifier field 322 uniquely identifies the authentication required by the security policy and can be cross-referenced with authentication identifier field 314 of security policy table 311. Authentication server field 324 identifies the authentication server that performs the authentication (specified by authentication identifier field 322). Authentication domain field 326 identifies the domain in which the authentication is to be performed. Authentication criteria list field 328 identifies one or more criteria that must be met in order to perform the authentication (identified by authentication identifier field 322). If any criteria specified by authentication criteria list field 328 are not met, access is granted without performing authentication (conditional on any other required authentication).

[0036] Criteria table 331 includes criteria identifier field 334 and threshold field 336. Criteria identifier field 334 uniquely identifies criteria. For example, some embodiments predefine identifiers using certain conditions. For example, in some embodiments, a first identifier is associated with a criterion for comparing the number of files requested for access with a threshold value defined by threshold field 336. In some embodiments, a second identifier is associated with a criterion for comparing the amount of data requested for access with a threshold value defined by threshold field 336. In some embodiments, a third identifier is associated with a criterion for comparing the location of the requester with a predefined area, and applying authentication if the requester is within the predefined area. In some embodiments, a fourth identifier is associated with a criterion for comparing the location of the requester with a predefined area, and not applying authentication if the requester is within the predefined area. In some embodiments, a fifth identifier is associated with a criterion for comparing a location within a branch (e.g., a file directory structure for which an access request is made) with a predefined location (e.g., a wildcard directory structure or specified by a regular expression), and applying authentication when the requested access is for a predefined location. In some embodiments, the sixth identifier is associated with a criterion of comparing a location within a branch (e.g., a file directory structure to which access is requested) to a predefined location (e.g., a wildcard directory structure or specified by a regular expression) and not applying authentication if the requested access is to a predefined location.

[0037] Document table 341 includes document identifier field 344, branch identifier field 346, and content field 348. Document identifier field 344 and branch identifier field 346 uniquely identify a specific version of a document. Two documents with a common value in the document identifier field but with different branch identifier fields 346 represent the same document on two different branches and are therefore two different versions of the same document. Content field 348 defines the content of the document identified by the combination of document identifier field 344 and branch identifier field 346.

[0038] The account table 352 includes an account identifier field 354 and an account credentials field 356. The account identifier field 354 uniquely identifies an account of a particular authentication system. The account credentials field 356 defines a set of credentials (e.g., one or more of an account name and / or an account password) used to authenticate the account. Some embodiments implement a first authentication data storage device (e.g., an enterprise authentication data storage device 110) that is relied upon for a first authentication of a user, and a second authentication data storage device (e.g., a second authentication data storage device 118) that is relied upon for a second authentication. In these embodiments, each data storage device stores separate and independent authentication credential information. For example, a first user has a first account name and a first password stored in a first authentication data storage device, and a second different account name and a second different password stored in a second authentication data storage device. In some embodiments, the account name assigned to a single "real" user is identical in the first and second authentication data storage devices. Some example embodiments utilize a structure similar or identical to the account table 352 to store authentication credentials.

[0039] Figure 4 Example message portions implemented by one or more disclosed embodiments are shown. Figure 4 Request message portion 400, response message portion 410, and request completion message portion 420 are shown. In some embodiments, each of request message portion 400, response message portion 410, and request completion message portion 420 are exchanged between a version control system (e.g., VCS 102) and a client device or user device (e.g., client device 106).

[0040] Message portion 400 includes an account identifier list field 402, a request identifier field 404, a path identifier field 406, a branch identifier field 408, and an access request field 409. Account identifier list field 402 uniquely identifies one or more authenticated accounts making the request. In some embodiments, any of the account identifiers stored in account identifier list field 402 may be the same as those described above for Figure 3The account identifier field 354 discussed above is cross-referenced. Note that in some embodiments, each authentication system (e.g., enterprise authentication system 108 and / or second authentication system 116) maintains a copy of the account table 352. The request identifier field 404 uniquely identifies a request to a version control system such as the one described above for Figure 1 The path identifier field 406 defines the path within the version control system that the request is requesting access to (e.g., " / module1 / codefile 1"). The branch identifier field 408 uniquely identifies the branch to which the request is directed (e.g., Figure 2 In some embodiments, the branch identifier specified in field 408 is the same as that specified above for the mainline branch 202, development branch 204, feature branch 212, or release branch 224. Figure 3 Any branch identifier field discussed is cross-referenced. Access request field 409 defines the type of access requested by the request (the request identified by request identifier field 404). In some embodiments, access request field 409 specifies one or more of read access, write access, read / write access, or branch delete access.

[0041] Response message portion 410 includes a request identifier field 412 and a result field 414. Request identifier field 412 corresponds to request identifier field 404. In other words, the response to the request includes an equivalent request identifier field value as the request itself. Result field 414 specifies the result of the request, such as grant or deny.

[0042] Request completion message portion 420 includes a request identifier field 422, a document identifier field 424, a branch identifier field 426, and a document data field 428. In the event that the request is a read request, the version control system sends a request completion message portion that includes the requested data (if the request is granted). When the request is a write request, the requester provides a request completion message portion that indicates the data to be written. To this end, document identifier field 424 and branch identifier field 426 combine to define the document for which the data is provided. Document data field 428 defines the data for the document. Note that for requests that apply to multiple documents, multiple request completion message portions are exchanged between the user device and the version control system.

[0043] Figure 5An example structure of a document repository 500 is shown. Document repository 500 includes a first branch 501, which includes a hierarchical file structure. As shown, root level folder 502 includes files and / or folders at the first level. The first level includes files 504 and 506, as well as folder or directory 508 and folder or directory 510A. Folder or directory 508 includes file 512 and file 514, which are labeled "File 3" and "File 4", respectively. Folder or directory 510A includes file 516A and file 518A, which are labeled "File 5" and "File 6", respectively.

[0044] exist Figure 5 501. A second branch 520 is also shown. The second branch 520 includes a subset of the files included in the first branch 501. For example, the second branch includes a folder 510B corresponding to the folder or directory 510A in the first branch 501, and a file 516B and a file 518B corresponding to the files 516A and 516B in the first branch 501, respectively. However, the second branch 520 does not include files corresponding to the files 504, 506, 512, and 514, nor does it include the folder or directory 508.

[0045] VCS102 maintains a copy of the files specific to each branch in the first branch 501 and the second branch 520. In some embodiments, two copies are stored, one for each branch. In some embodiments, the second branch 520 is implemented using incremental information that tracks changes in the files in the second branch 520 relative to their corresponding files in the first branch 501. The disclosed embodiments provide security policies specific to specific branches. For example, some embodiments define branch policies that apply to the first branch 501 but not to the second branch 520. Some of these same embodiments define branch policies for the second branch 520 but not the first branch 501. In some embodiments, VCS102 supports branch operations that create new branches in a manner similar to that shown for the first branch 501 and the second branch 520. In addition, in at least some embodiments, VCS102 supports merge operations that integrate files of one branch with corresponding files of another branch. For example, a merge operation of the second branch 520 to the first branch 501 will integrate any changes in the files of the second branch 520 with the data in the files of the first branch 501. If one or more files in either of the first branch 501 and / or the second branch 520 were modified before the merge operation occurred, those changes are typically included in the resulting integrated set of files for the branches.

[0046] Figure 6 is a sequence diagram illustrating the flow of messages between components included in one or more disclosed embodiments. Figure 6 6, an approval service 608, and an authentication provider 609 are shown. In some embodiments, the repository service 606 runs on the VCS 102 computer. In some embodiments, the approval service 608 runs on the VCS 102 computer. In other embodiments, the approval service 608 runs on a different physical hardware device. In some embodiments, the approval service 608 is a network service. Thus, the approval service 608 is an external service because it is external to the repository service. In some embodiments, the approval service 608 is described above with respect to Figure 1 The repository service is executed or executed on the approval server 124 discussed above. The repository service is configured to query the approval server 124 (eg, or an approval service running on the approval server 124) based on the branch configuration information, as discussed further below.

[0047] In some embodiments, the authentication provider 609 runs on the second authentication system 116. The authentication provider 609 relies on an authentication database including authentication credentials that is separate and distinct from any authentication credentials relied upon by the enterprise authentication system 108 (e.g., via the enterprise authentication data store 110 in some embodiments).

[0048] Messaging sequence 600 illustrates a pull request message 610 sent by client device 106 to repository service 606. Pull request message 610 references a branch within a repository (e.g., document repository 104) accessed by repository service 606. In some embodiments, pull request message 610 includes one or more fields of message portion 400, as described above with respect to Figure 4 For example, in some embodiments, pull request message 610 references a branch via branch identifier field 408 .

[0049] Upon receiving the pull request message 610, the repository service 606 determines that the branch referenced by the pull request message 610 requires approval by the approval service 608. For example, some embodiments of the repository service 606 maintain a mapping between branches and any services that must approve changes to documents within each branch (e.g., via the branch table 301, which maps branch identifiers (defined by field 304) to security policy identifiers (via field 306)). The repository service then sends a message 612 to the approval service 608 to indicate receipt of the pull request message 610. In some embodiments, the message 612 also includes information included in the pull request message 610, such as information identifying the branch to be approved.

[0050] After receiving message 612, approval service sends a create approval link message 614 to repository service 606. Create approval link message 614 provides a URL referencing a web server implemented or provided by approval service 608. Repository service 606 stores the link so that it is displayed in a user interface indicating that approval via the link is required before pull request message 610 is approved.

[0051] The user on the client device 106 then selects the link via the user interface. Upon selection, a message 616 is sent from the client device to a network server hosted or provided by the repository service 606. The approval service 608 also sends the metadata to the client device 106 via message 618. The approval service 608 responds to the message 616 with a challenge message 620. In some embodiments, the challenge message 620 is configured to cause the client device 106 to display a prompt for authentication credentials on a display of the client device 106.

[0052] After receiving input from the user defining the authentication credentials, the client device 106 sends a credentials message 622 including the authentication credentials to the approval service 608. The approval service 608 then passes the credentials to the authentication provider 609 via message 624, which in some embodiments is similar to the authentication provider 609 described above for authentication. Figure 1 The second authentication system 116 discussed. Based on these credentials, the authentication provider 609 approves or disapproves access to the specified branch and communicates the decision to the approval service 608 via a result message 626.

[0053] The authentication provided by the authentication provider 609 is generally not branch specific, but rather indicates whether the provided credentials are valid within the authentication system managed by the authentication provider 609. To authenticate the credentials, the authentication provider 609 compares the credentials to an authentication database or data store. The authentication database or data store includes credentials that are separate and different from those necessary to access repository services and / or other enterprise resources (e.g., different from the enterprise authentication data store 110) in general. The result of the authentication is provided to the approval service via a result message 626.

[0054] In some embodiments, the approval service 608 performs one or more additional confirmations, approvals, or checks 628 to determine whether the user is approved to access the branch. For example, in some embodiments, the approval service 608 determines whether to approve the pull request based on the path or file in the document repository that the user is attempting to access, the time of day, the location of the client device 106, the amount of data accessed by the pull request message 610, or other parameters. The approval service 608 then sends an approval result message 630 to the repository service 606. The repository service 606 then completes the pull request based on the approval result message 630 and notifies the client device 106 of the result based on the completed pull request message 632. In some embodiments, the repository service 606 implements a "git" server.

[0055] Figure 7 is a flow chart of a method for authenticating a branch of a version control system. Figure 7 One or more functions discussed with method 700 are performed by hardware processing circuitry. For example, in some embodiments, instructions (e.g., instructions 824 discussed below) stored in a memory (e.g., memory 804 and / or 806 discussed below) configure a hardware processing circuitry (e.g., hardware processor 802 discussed below) to perform one or more of the functions of method 700. Thus, in some embodiments, method 700 is a device-implemented method.

[0056] After start operation 702, method 700 moves to operation 704. In operation 704, the first account is authenticated. The authentication is based on first authentication credentials. The first account authentication of operation 704 compares the first authentication credentials with credentials in a first authentication data store. For example, in some embodiments, the first authentication credentials (e.g., account name, password) are compared with a first authentication data store similar to enterprise authentication data store 110, as described above with respect to Figure 1 The first authentication data storage device stores data that associates the first account with a first set of authentication credentials (e.g., account name, account password, account secondary password). In some embodiments, the authentication of operation 704 provides access to enterprise resources, such as the above-mentioned authentication of Figure 1 In some embodiments, the authentication of operation 704 also provides access to at least a portion of a document repository (e.g., document repository 104). For example, in the example, the first authentication of operation 704 provides access to the document repository 104 described above. Figure 5 The second branch 520 is discussed instead of the access of the first branch 501 .

[0057] In operation 706, a request is received from the first account. The request is to submit a document to the document repository. In some embodiments, the request includes one or more fields of the message portion 400 discussed above. The request identifies the branch to which access is requested. In an example embodiment, the request accesses Figure 5 The first branch 501 of operation 704 is accessed, and the user requesting access has access rights to the second branch 520 via the first authentication of operation 704.

[0058] In operation 708, a branch of the document repository is identified. For example, in some embodiments, the request is decoded or parsed to identify the branch. In some embodiments, the request includes one or more fields discussed above with respect to message portion 400. For example, in some embodiments, the branch is indicated by branch identifier field 408.

[0059] In operation 710, it is determined that a second authentication is required to access the branch. For example, in some embodiments, operation 710 identifies a branch in branch table 301. A mapping of the branch to a security policy is then determined (e.g., via branch table 301). The security policy indicates that additional authentication is necessary (e.g., in some embodiments, via security policy table 311 and / or authentication identifier field 314). As described above, in various embodiments, whether a second authentication is necessary depends on multiple factors. For example, as described above, some embodiments determine the second authentication based on the location of the client device requesting access to the branch. In some embodiments, a condition may indicate that a client device within a specific geographic area is not required to perform a second authentication to access the branch, while a second client device outside the specific geographic area is required to perform a second authentication to access the same branch. Some embodiments define certain locations or areas where a second authentication is unconditionally required. For example, some embodiments define that any client device within a defined geographic area must perform a second authentication.

[0060] Some embodiments condition the second authentication on the amount of data requested for access (e.g., via the data size field 318). Thus, if an account requests access to an amount of data that exceeds a specified predefined limit (e.g., the entire operating system kernel code base), a second authentication is required. If the amount of data requested is below the predefined limit, some embodiments do not require a second authentication when accessing a branch. These various policies may also be combined in various embodiments (e.g., client devices within a specific region requesting access to data greater than a predefined data limit require a second authentication).

[0061] In operation 714, a second authentication is performed. The second authentication is based on a second authentication data store (e.g., comparing enterprise authentication data store 110 and second authentication data store 118) that is different from the authentication data store used to perform the first authentication of operation 704. Thus, while the first authentication data store stores a first association between the first account and the first authentication credentials, the second authentication data store stores a different second association between the first account and the second authentication credentials.

[0062] In at least some embodiments, performing the second authentication includes exchanging messages with an authentication service. For example, in some embodiments, an approval service (e.g., running on approval server 124) acts as a proxy between the client device (e.g., 106) and an authentication service (e.g., running on second authentication system 116 in some embodiments). Thus, in some embodiments, performing the second authentication includes: receiving, via the approval service, an authentication request from the client device (e.g., Figure 6 622 discussed above), and then the approval service requests authentication from the authentication service (e.g., Figure 6 In some embodiments, the approval service requests the second authentication from the authentication service (eg, and the authentication system) without any message exchange between the approval service and the client device.

[0063] In operation 716, based on the second authentication, the document is submitted to the document repository. If the second authentication is successful, some embodiments submit the document, and if the second authentication is unsuccessful, the document is not approved for submission, so submission is prohibited. After operation 716 is completed, method 700 moves to end operation 718.

[0064] Some embodiments of method 700 process multiple requests to submit documents. In various embodiments, each of the multiple requests comes from a first account or a different second account. In some embodiments, each of the multiple requests indicates a branch, and method 700 determines whether the branch requires additional authentication in a manner similar to that described above for operation 710. If so, method 700 performs additional authentication, wherein access to the branch, if access to the branch is required, is conditional on whether the authentication is successful. Note that in some disclosed embodiments, one or more requests processed by method 700 do not submit (write) a document to a document repository but rather read a document from a document repository (e.g., a "checkout" operation). As described above for Figure 3 As described, in some embodiments, security policy table 311 provides definitions of access types that require additional authentication (eg, via field 316).

[0065] Figure 8A block diagram of an example machine 800 is shown on which any one or more of the techniques (e.g., methods) discussed herein may be performed. In alternative embodiments, the machine 800 may operate as a standalone device or be connected (e.g., via a network) to other machines. In a networked deployment, in a server-client network environment, the machine 800 may operate as a server machine, a client machine, or both. In an example, the machine 800 may be used as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. The machine 800 is a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a smart phone, a network appliance, a network router, a switch or bridge, a server computer, a database, a conference room device, or any machine capable of executing (sequentially or otherwise) instructions that specify actions to be performed by the machine. In various embodiments, the machine 800 may perform the instructions described above with respect to Figure 1-Figure 7 Further, while only a single machine is shown, the term “machine” should also be understood to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), and other computer cluster configurations.

[0066] As described herein, examples may include or may operate on: a logic unit or multiple components, modules, or mechanisms (hereinafter referred to as "modules"). A module is a tangible entity (e.g., hardware) that is capable of performing a specified operation and is configured or arranged in a certain manner. In one example, a circuit is arranged (e.g., intrinsically or relative to an external entity such as other circuits) as a module in a specified manner. In an example, the whole or part of one or more computer systems (e.g., a separate client or server computer system) or one or more hardware processors are configured by firmware or software (e.g., instructions, application parts, or applications) to operate to perform a specified operation. In an example, the software may reside on a non-temporary computer-readable storage medium or other machine-readable medium. In an example, when executed by the underlying hardware of the module, the software causes the hardware to perform a specified operation.

[0067] Thus, it should be understood that the term "module" includes a tangible entity that is physically constructed, specifically configured (e.g., hardwired) or temporarily (e.g., temporarily) configured (e.g., programmed) to operate in a particular manner, or to perform part or all of any operations described herein. Considering examples in which modules are temporarily configured, each of these modules need not be instantiated at any one time. For example, where a module includes a general-purpose hardware processor configured using software, the general-purpose hardware processor is configured as various different modules at different times. The software can configure the hardware processor accordingly, for example, to constitute a particular module at one time and to constitute a different module at another different time.

[0068] The machine (e.g., computer system) 800 may include a hardware processor 802 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 804, and a static memory 806, some or all of which may communicate with each other via a connection 808 (e.g., a bus). The machine 800 may also include a display unit 810, an alphanumeric input device 812 (e.g., a keyboard), and a user interface (UI) navigation device 814 (e.g., a mouse). In an example, the display unit 810, the input device 812, and the UI navigation device 814 are touch screen displays. The machine 800 may additionally include a storage device (e.g., a drive unit) 816, a signal generating device 818 (e.g., a speaker), a network interface device 820, and one or more sensors 821 (e.g., a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensor). The machine 800 may include an output controller 828 (e.g., a serial (e.g., Universal Serial Bus (USB), parallel or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection) to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0069] The storage device 816 may include a machine-readable medium 822 on which is stored one or more sets of data structures or instructions 824 (e.g., software) embodying or used by any one or more of the techniques or functionality described herein. The instructions 824 may also reside, completely or at least partially, within the main memory 804, within the static memory 806, or within the hardware processor 802 during execution of the instructions by the machine 800. In one example, one or any combination of the hardware processor 802, the main memory 804, the static memory 806, or the storage device 816 may constitute a machine-readable medium.

[0070] Although machine-readable medium 822 is illustrated as a single medium, the term “machine-readable medium” may include a single medium or multiple media (eg, a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 824 .

[0071] The term "machine-readable medium" may include any medium capable of storing, encoding or carrying instructions for execution by the machine 800, and causing the machine 800 to perform any one or more of the techniques in the present disclosure, or capable of storing, encoding or carrying data structures used by or associated with these instructions. Non-limiting examples of machine-readable media may include solid-state memory and optical and magnetic media. Specific examples of machine-readable media may include: non-volatile memory (e.g., semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM))) and flash memory devices; magnetic disks (e.g., internal hard disks and removable disks); magneto-optical disks; random access memory (RAM); solid-state drives (SSD); and CD-ROM and DVD-ROM disks. In some examples, the machine-readable medium may include non-temporary machine-readable media. In some examples, the machine-readable medium may include machine-readable media that is not a transient propagation signal.

[0072] The instructions 824 may also be sent or received over a communication network 826 using a transmission medium via the network interface device 820. The machine 800 may communicate with one or more other machines using any of a variety of transmission protocols, such as frame relay, Internet Protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (e.g., HTTP), etc. Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile phone network (e.g., a cellular network), a plain old telephone (POTS) network, and a wireless data network (e.g., known as a wireless network). The Institute of Electrical and Electronics Engineers (IEEE) 802.11 series of standards, known as 802.16 family of standards), IEEE 802.15.4 family of standards, Long Term Evolution (LTE) family of standards, Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, and the like. In an example, the network interface device 820 may include one or more physical jacks (e.g., Ethernet, coaxial cable, or telephone jacks) or one or more antennas connected to the communication network 826. In an example, the network interface device 820 may include multiple antennas to use at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) technology for wireless communication. In some examples, the network interface device 820 may use multi-user MIMO technology for wireless communication.

[0073] As described herein, examples may include or may operate on the following: a logic unit or multiple components, modules or mechanisms. A module is a tangible entity (e.g., hardware) that can perform a specified operation and is configured or arranged in a certain manner. In an example, a circuit is arranged (e.g., intrinsically or relative to an external entity such as other circuits) as a module in a specified manner. In an example, the whole or part of one or more computer systems (e.g., a separate client or server computer system) or one or more hardware processors are configured by firmware or software (e.g., instructions, application parts or applications) to operate to perform a specified operation. In an example, the software may be located on a machine-readable medium. In an example, when executed by the underlying hardware of the module, the software causes the hardware to perform the specified operation.

[0074] Thus, it should be understood that the term "module" includes a tangible entity that is physically constructed, specifically configured (e.g., hardwired) or temporarily (e.g., temporarily) configured (e.g., programmed) to operate in a particular manner, or to perform part or all of any operations described herein. Considering examples in which modules are temporarily configured, each of these modules need not be instantiated at any one time. For example, where a module includes a general-purpose hardware processor configured using software, the general-purpose hardware processor is configured as various different modules at different times. The software can configure the hardware processor accordingly, for example, to constitute a particular module at one time and to constitute a different module at another different time.

[0075] Various embodiments are implemented in whole or in part in software and / or firmware. The software and / or firmware may take the form of instructions contained in or on a non-transitory computer-readable storage medium. Those instructions may then be read and executed by one or more processors to enable the operations described herein to be performed. The instructions may have any suitable form, such as, but not limited to, source code, compiled code, interpreted code, executable code, static code, dynamic code, etc. Such a computer-readable medium may include any tangible, non-transitory medium for storing information in a form readable by one or more computers, such as, but not limited to, a read-only memory (ROM), a random access memory (RAM), a disk storage medium, an optical storage medium, a flash memory, and the like.

[0076] Example 1 is a method, comprising: receiving a request from an account to submit a document to a document repository; decoding the request based on the first authentication; identifying a branch of the document repository based on the decoding; determining that the branch requires a second authentication; in response to the required second authentication, performing a second authentication on the account via a second authentication system; and submitting the document to the first branch of the document repository based on the second authentication.

[0077] In Example 2, the inventive subject matter of Example 1 optionally includes: receiving a second request from the account to submit a second document to the document repository; based on the first authentication, performing a second decoding on the second request; based on the second decoding, identifying a second branch of the document repository; determining that the second authentication is not required to access the second branch; and based on the first authentication, submitting the second document to the second branch of the document repository.

[0078] In Example 3, the inventive subject matter of any one or more of Examples 1-2 optionally includes: wherein the first authentication system is configured to associate the account with a first set of credentials, and the second authentication system is configured to associate the account with a second set of credentials.

[0079] In Example 4, the inventive subject matter of any one or more of Examples 1-3 optionally includes: wherein, determining that the first branch requires the second authentication includes: identifying a branch policy associated with the first branch; and based on the branch policy, determining that the first branch requires the second authentication.

[0080] In Example 5, the inventive subject matter of Example 4 optionally includes: wherein, performing the second authentication via the second authentication system includes: querying a network service.

[0081] In Example 6, the inventive subject matter of Example 5 optionally includes identifying the network service based on the branching strategy.

[0082] In Example 7, the inventive subject matter of any one or more of Examples 1-6 optionally includes: wherein the first authentication system is configured to control access to enterprise resources, and the second authentication system is configured to control access to a data center.

[0083] Example 8 is a system comprising: a hardware processing circuit; and one or more hardware memories storing instructions, which, when executed, configure the hardware processing circuit to perform operations including: receiving a request from an account to submit a document to a document repository; decoding the request based on the first authentication; identifying a branch of the document repository based on the decoding; determining that the branch requires a second authentication; in response to the required second authentication, performing a second authentication on the account via a second authentication system; and submitting the document to the first branch of the document repository based on the second authentication.

[0084] In Example 9, the inventive subject matter of Example 8 optionally includes operations further including: receiving a second request from the account to submit a second document to the document repository; based on the first authentication, performing a second decoding on the second request; based on the second decoding, identifying a second branch of the document repository; determining that the second authentication is not required to access the second branch; and based on the first authentication, submitting the second document to the second branch of the document repository.

[0085] In Example 10, the inventive subject matter of any one or more of Examples 8-9 optionally includes: wherein the first authentication system is configured to associate the account with a first set of credentials, and the second authentication system is configured to associate the account with a second set of credentials.

[0086] In Example 11, the inventive subject matter of any one or more of Examples 8-10 optionally includes: wherein, determining that the first branch requires the second authentication includes: identifying a branch policy associated with the first branch; and based on the branch policy, determining that the first branch requires the second authentication.

[0087] In Example 12, the inventive subject matter of Example 11 optionally includes: wherein, performing the second authentication via the second authentication system includes: querying a network service.

[0088] In Example 13, the inventive subject matter of Example 12 optionally includes: the operation further includes: identifying the network service based on the branching strategy.

[0089] In Example 14, the inventive subject matter of any one or more of Examples 8-13 optionally includes: wherein the first authentication system is configured to control access to enterprise resources, and the second authentication system is configured to control access to a data center.

[0090] Example 15 is a non-transitory computer-readable storage medium comprising instructions that, when executed, configure a hardware processing circuit to perform operations comprising: receiving a request from an account to submit a document to a document repository; decoding the request based on the first authentication; identifying a branch of the document repository based on the decoding; determining that the branch requires a second authentication; in response to the required second authentication, performing a second authentication on the account via a second authentication system; and submitting the document to the first branch of the document repository based on the second authentication.

[0091] In Example 16, the inventive subject matter of Example 15 optionally includes operations further including: receiving a second request from the account to submit a second document to the document repository; based on the first authentication, performing a second decoding on the second request; based on the second decoding, identifying a second branch of the document repository; determining that the second authentication is not required to access the second branch; and based on the first authentication, submitting the second document to the second branch of the document repository.

[0092] In Example 17, the inventive subject matter of any one or more of Examples 15-16 optionally includes: wherein the first authentication system is configured to associate the account with a first set of credentials, and the second authentication system is configured to associate the account with a second set of credentials.

[0093] In Example 18, the inventive subject matter of any one or more of Examples 15-17 optionally includes: wherein, determining that the first branch requires the second authentication includes: identifying a branch policy associated with the first branch; and based on the branch policy, determining that the first branch requires the second authentication.

[0094] In Example 19, the inventive subject matter of Example 18 optionally includes: wherein the second authentication via the second authentication system includes: querying a network service.

[0095] In Example 20, the inventive subject matter of Example 19 optionally includes: the operation further includes: identifying the network service based on the branching strategy.

[0096] In Example 21, the inventive subject matter of any one or more of Examples 15-20 optionally includes: wherein the first authentication system is configured to control access to enterprise resources, and the second authentication system is configured to control access to a data center.

Claims

1. A method implemented by a device, comprising: Performing a first authentication on an account that is to access the document repository via a first authentication system; receiving a request from the account to submit a document to the document repository; Based on the first authentication, decoding the request; Based on the decoding, identifying a first branch of the document repository; determining that the first branch requires a second authentication; In response to the required second authentication, performing a second authentication on the account via a second authentication system; as well as Based on the second authentication, the document is submitted to the first branch of the document repository.

2. The method according to claim 1, further comprising: receiving, from the account, a second request to submit a second document to the document repository; Based on the first authentication, performing a second decoding on the second request; Based on the second decoding, identifying a second branch of the document repository; determining that a second authentication is not required to access the second branch; as well as Based on the first authentication, the second document is submitted to the second branch of the document repository.

3. The method according to claim 1, wherein: The first authentication system is configured to associate the account with a first set of credentials, and the second authentication system is configured to associate the account with a second set of credentials.

4. The method according to claim 1, wherein: Determining that the first branch requires the second authentication includes: identifying a branching strategy associated with the first branch, and Based on the branch policy, it is determined that the first branch requires the second authentication.

5. The method according to claim 4, wherein: Performing the second authentication via the second authentication system includes: querying a network service. The method of claim 5 , further identifying the network service based on the branching policy.

7. The method according to claim 1, wherein: The first authentication system is configured to control access to enterprise resources and the second authentication system is configured to control access to a data center.

8. A computing system comprising: Hardware processing circuit; as well as One or more hardware memories storing instructions that, when executed, configure the hardware processing circuitry to perform operations including: Performing a first authentication on an account that is to access the document repository via a first authentication system; receiving a request from the account to submit a document to the document repository; Based on the first authentication, decoding the request; Based on the decoding, identifying a first branch of the document repository; determining that the first branch requires a second authentication; In response to the required second authentication, performing a second authentication on the account via a second authentication system; as well as Based on the second authentication, the document is submitted to the first branch of the document repository.

9. The system of claim 8, wherein the operations further comprise: receiving, from the account, a second request to submit a second document to the document repository; Based on the first authentication, performing a second decoding on the second request; Based on the second decoding, identifying a second branch of the document repository; determining that the second authentication is not required to access the second branch; as well as Based on the first authentication, the second document is submitted to the second branch of the document repository.

10. The system according to claim 8, wherein: The first authentication system is configured to associate the account with a first set of credentials, and the second authentication system is configured to associate the account with a second set of credentials.

11. The system according to claim 8, wherein: Determining that the first branch requires the second authentication includes: identifying a branching strategy associated with the first branch, and Based on the branch policy, it is determined that the first branch requires the second authentication.

12. The system according to claim 11, wherein: Performing the second authentication via the second authentication system includes: querying a network service.

13. The system of claim 12, the operations further comprising: The network service is also identified based on the branching policy.

14. The system according to claim 8, wherein: The first authentication system is configured to control access to enterprise resources and the second authentication system is configured to control access to a data center.

15. A non-transitory computer-readable storage medium comprising instructions that, when executed, configure a hardware processing circuit to perform operations comprising: Performing a first authentication on an account that is to access the document repository via a first authentication system; receiving a request from the account to submit a document to the document repository; Based on the first authentication, decoding the request; Based on the decoding, identifying a first branch of the document repository; determining that the first branch requires a second authentication; In response to the required second authentication, performing a second authentication on the account via a second authentication system; as well as Based on the second authentication, the document is submitted to the first branch of the document repository.

16. The non-transitory computer-readable storage medium of claim 15, the operations further comprising: receiving, from the account, a second request to submit a second document to the document repository; Based on the first authentication, performing a second decoding on the second request; Based on the second decoding, identifying a second branch of the document repository; determining that the second authentication is not required to access the second branch; as well as Based on the first authentication, the second document is submitted to the second branch of the document repository.

17. The non-transitory computer-readable storage medium of claim 15, wherein: The first authentication system is configured to associate the account with a first set of credentials, and the second authentication system is configured to associate the account with a second set of credentials.

18. The non-transitory computer-readable storage medium of claim 15, wherein: Determining that the first branch requires the second authentication includes: identifying a branching strategy associated with the first branch, and Based on the branch policy, it is determined that the first branch requires the second authentication.

19. The non-transitory computer-readable storage medium of claim 18, wherein: Performing the second authentication via the second authentication system includes: querying a network service.

20. The non-transitory computer-readable storage medium of claim 19, the operations further comprising: The network service is also identified based on the branching policy.

Images