CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims priority to provisional application serial number 63/048,973 filed July 7, 2020, titled “System and Method for Simplifying User Authentication Workflows” and provisional application serial number 63/052,017 filed July 15, 2020, titled “A System and Method of Implementing a Series of Actions with Interdependencies,” the entire content of which are incorporated herein by reference thereto.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[0002] Not applicable.

BACKGROUND OF THE INVENTION

Field of the Invention

[0003] The present invention relates to the field of network-based software deployments. More particularly, the invention relates to a system and method for configuring and deploying software infrastructure and providing controlled access to services made available by the software infrastructure to end users.

Background of the Invention

[0004] The world of network software deployment has evolved significantly over time. Historically, companies or organizations would operate in siloed environments in which developers worked exclusively on their machines to produce source code, which would then be sent to system administrators and operators for deployment. This approach typically requires system administrators to reconstruct a close approximation of the developers’ environment and ultimately deploy software to hand-crafted servers that are custom configured for the job, which proved to be time consuming, costly, and unreliable. Evolving from these historical practices, two complimentary shifts emerged in network software deployment - the cloud, and DevOps culture - which together enable an ability to push configuration further back in the deployment process such that build servers may be responsible for producing immutable images containing complete, ready- to-deploy software.

[0005] Accompanying these shifts, purpose-built tooling has been developed to enable delivery teams to build, test, configure, deploy, and monitor cloud-based applications. Typically, a variety of complimentary tools are often used together in these processes, referred to as a toolchain, rather than a single general-purpose application. Understanding how these toolchains have evolved, along with common frustrations associated with their use, includes an understanding of the fundamental concepts underpinning the shifts in network software deployment, including high availability, autoscaling, load balancing, containerization, orchestration, role-based access control, and continuous integration / continuous deployment.

[0006] High availability is intended to address a fundamental assumption that hardware and infrastructure failures will happen. More specifically, for example, any individual machine may fail at any time, or an entire availability zone within a cloud data center may fail at any time. Considering these risks, it is unlikely that two machines might fail at the same time, and very unlikely that three might fail at the same time. Similarly, it is unlikely that two availability zones might fail at the same time, and very unlikely that three availability zones might fail at the same time. While a practice of deploying a service on at least three machines in three different availability zones may succeed in meeting high availability objectives, typically allocating an entire machine to serve one third of the load of an application is wasteful, and managing such complex deployments is not a trivial endeavor.

[0007] Autoscaling technologies address significant and sometimes rapid shifts in traffic loads to which an application may be subjected. For example, an application may experience a sudden spike in traffic which subsides soon thereafter. A properly deployed autoscaling application would be capable of detecting the increase in load, automatically increase the capacity for the application to service the load, initiate an alert if the demanded capacity exceeds an expected range (which may indicate a software bug or an attempt at exploiting a security vulnerability), and automatically decrease capacity when the load decreases as a means of optimizing operating costs. Ideally, autoscaling would be implemented to handle common fluctuations in load without the need for operator intervention, unless load patterns are indicative of exceptional or potentially costly scenarios. [0008] Multi-machine implementations that are employed to meet high availability and autoscaling objectives give rise to a complimentary need to balance traffic loads among the multiple machines. Load balancing in effectively implemented systems may be able to intelligently route traffic to the appropriate machine(s) within a cluster, and the appropriate network interfaces within those machines, during fluctuations in overall traffic loads as well as during outages which may occur due to machine or infrastructure failures, or network errors. Load balancing may include monitoring the health of each application and its deployment on an individual machine, and may further employ ingress rules to redirect traffic to an appropriate destination.

[0009] In recent history, virtual machines have been used as a means of meeting high availability or autoscaling objectives. A virtual machine typically emulates a full computer system, including not only a particular application or set of applications, but also a dedicated instance of an operating system, and a single physical machine might host more than one virtual machine. Thus, a physical machine hosting one or more virtual machines may typically have several instances of operating systems running on the physical hardware - one operating system for the physical machine, and another for each virtual machine running on that physical hardware - thus burdening the machine with duplicative processing overhead.

[0010] More recently, however, containerization has emerged as a technique to package an application together with its dependencies (additional software or software libraries on which it depends) into a single image called a container that can be concurrently hosted on a physical machine without the additional overhead of running multiple operating systems on the machine. Containers are typically thought of as light-weight in comparison to virtual machines since they allow system resources to be shared between containers, and thus can be started more rapidly than a virtual machine since they are less resources intensive.

[0011] In practice an individual container can be started and shut down on-demand, and a deployment of an application may comprise a plurality of containers running on a plurality of physical machines across a plurality of availability zones in order to meet high availability and autoscaling objectives. Orchestration has thus emerged as a process of maintaining a set of cloud machines, monitoring their health, deploying containers onto each of those machines, and routing traffic within the cluster of machines. Automating such highly complex orchestration needs holds substantial advantages over attempting to achieve similar levels of orchestration manually. [0012] Ensuring security across containerized deployments of an application can be achieved through enforcement of role-based access controls which restrict system access to authorized users. Roles may be created for various functions within an organization, such as those surrounding maintaining a physical machine, a cluster of machines, or an availability zone. Similarly, different roles may be defined for maintaining an application, a container image, or managing orchestration of a deployed application. Individuals within the organization may then be assigned to perform a role, with the ability to perform other roles being denied through enforcement of the access controls. In large organizations, operational complexities may arise in activating or de-activating security access as an individual moves around, leaves, or progresses in their career with the organization.

[0013] As the applications themselves, and their associated code bases, have grown in complexity, the process of developing software has also experienced fundamental shifts in how developers coordinate their collaborative efforts in producing source code and deploying the resulting applications. A technology called Git has been developed as an open-source solution to facilitate development of the Linux kernel, providing version control for maintaining the large distributed development project. Git technology has been widely adopted across the development community for use in conjunction with a variety of projects varying in scope and size, allowing changes to the codebase to be tracked through branches which may be cloned to enable parallel development efforts or pushed to a protected branch for deployment. Largely enabled by Git, continuous integration (Cl) comprises a process of automatically performing build and test actions on a codebase, typically for each push to a master branch or for periodic pull / merge requests. Complementing Cl, continuous deployment (CD) comprises a process of automatically performing a deployment of a new version of code, either via a push to a protected deployment branch, or via manual operator action. By fully automating both Cl and CD, the risk of operator error may be dramatically reduced, leading to more reliable services.

[0014] Tying these concepts together, the term DevOps is often used to describe the collective efforts surrounding software development and the operation of the infrastructure on which the software may be hosted or deployed. DevOps toolchains typically comprise a variety of individual tools which together enable a cross-functional mode of working in such environments. This world of software tooling is difficult to navigate. Often deployed as services available through the infrastructure, setting up the tools coherently, configuring them to cooperate, and ensuring stability is not only challenging, but costly for modem DevOps organizations. More so, setting up and managing controlled access to these resources and services among superusers, administrators, developers, operators, end users, and other DevOps participants may present a substantial challenge, especially if undertaken manually, and may present significant security vulnerabilities where access credentials are available outside the system.

[0015] Further complicating these environments, often times there may be a need to implement a large number of add-on components alongside the desired infrastructure in order to allow the system as a whole to be feature-rich and observable. These add-on components themselves may necessitate that additional levels of controlled access privileges be securely distributed among a team of participants responsible for implementing, operating, or monitoring the overall environment, thus introducing additional usability and security concerns.

[0016] Further still, additional complications may arise when deploying software infrastructure at least in part on a cloud-based platform of computing services such as Amazon Web Services ^® . Commonly referred to as AWS ^® , complexities may be encountered where identity and access management on the AWS ^® platform needs to be synchronized with roles or groups which may be configured across one or more 3 ^rd party identity providers, which may further lead to inefficient practices of on-boarding users or potential security vulnerabilities associated with off-boarding users, for example following termination.

[0017] Consequently, there is a need for a system and method of configuring and deploying software infrastructure which coordinates and automates the setup of the infrastructure, reduces the risk of security vulnerabilities which may be exploited, and provides an organization with a cost- effective means of fully utilizing modem DevOps tooling.

BRIEF SUMMARY OF SOME OF THE PREFERRED EMBODIMENTS [0018] These and other needs in the art are addressed in one embodiment by a system and method for configuring and deploying software infrastructure which may further comprise a system and method of implementing a series of actions with interdependencies. These and other needs in the art are addressed in another embodiment by a system and method for simplifying user authentication and authorization workflows.

[0019] The method for configuring and deploying software infrastructure may comprise a plurality of sequential or non-sequential method steps which may be performed by an implementation team and a configuration and deployment system having shared objectives of creating, deploying, initializing, or modifying software infrastructure.

[0020] The system for configuring and deploying software infrastructure may comprise a configuration and deployment system comprising an installer and a user interface. The user interface may be implemented as a web-based user interface, as a command-line interface, or combinations thereof. The configuration and deployment system may further comprise system and method of implementing a series of actions with interdependencies, which enables a central means of coordinating the installation or provisioning of software infrastructure components in view of configurations or dependencies which may overlap.

[0021] The system for simplifying user authentication and authorization workflows may comprise a credentials management system, further comprising a credentials management system server and a credentials management system client. The method of simplifying user authentication and authorization workflows may comprise the credentials management system server receiving configurations from an implementation team and communicating with the credentials management system client, one or more 3 ^rd party identity providers, and a cloud-based platform of computing services.

[0022] Together, the systems and methods described herein may offer a number of advantages over prevailing practices in the art by automating the configuration and deployment of software infrastructure and streamlining the procedures through which the software infrastructure may be created, configured, and maintained. The system and methods described herein may offer additional significant advantages over prevailing practices by automating management of the authorizations through which end users may access services available on the software infrastructure, resulting in a substantially more secure infrastructure environment.

[0023] The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter that form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and the specific embodiments disclosed may be readily utilized as a basis for modifying or designing other embodiments for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent embodiments do not depart from the spirit and scope of the invention as set forth in the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS [0024] For a detailed description of the preferred embodiments of the invention, reference will now be made to the accompanying drawings in which:

[0025] Figure 1 illustrates a method for configuring and deploying software infrastructure;

[0026] Figure 2 illustrates an overview of a system and method of simplifying user authentication and authorization workflows;

[0027] Figure 3 illustrates an embodiment of a method through which an end user may be authenticated to execute one or more API commands;

[0028] Figure 4 illustrates an embodiment of a method through which an end user may obtain a list of roles available to the end user to execute one or more API commands; and [0029] Figure 5 illustrates an embodiment of a method through which an end user may be authorized execute one or more API commands by assuming a role.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0030] Fig. 1 depicts method 100 for configuring and deploying software infrastructure. Method 100 comprises individual method steps performed by implementation team 110 and configuration and deployment system 120, which through application of method 100 may result in the design, configuration, modification, and/or deployment of software infrastructure 140, and additionally allow controlled access of one or more end users 130 to one or more network services available on software infrastructure 140.

[0031] Implementation team 110 may be in communication with configuration and deployment system 120 and vice-versa, and configuration and deployment system 120 may be in communication with software infrastructure 140 and vice-versa. Similarly, end user 130 may be in communication with configuration and deployment system 120 and vice versa, which may allow end user 130 to be in communication with software infrastructure 140.

[0032] Implementation team 110 may be comprised of one or more persons who may be responsible for determining the scope and architecture of software infrastructure 140. Implementation team 110 may further comprise one or more objectives which may be desired, preferred, suggested, recommended, or mandated to be achieved. Examples of such objectives may include, but not be limited to, high availability, autoscaling, load balancing, cost optimization, access control, segregation-of-duties, continuous integration, or continuous deployment objectives, or combinations thereof.

[0033] Software infrastructure 140 may comprise software, hardware, or a suitable combination of software and hardware which may cause to be available or modify one or more network services that enable hosting one or more applications on software infrastructure 140, while meeting objectives which may include, but not be limited to, high availability, autoscaling, load balancing, cost optimization, access control, or similar objectives, or combinations thereof. The one or more network services available on software infrastructure 140 may further comprise services which enable continuous integration or continuous deployment workflows for developing, testing, deploying, upgrading, modifying, or maintaining the one or more hosted applications, or add-on components which enhance the feature set or observability of software infrastructure 140.

[0034] Configuration and deployment system 120 may be implemented in software, hardware, or a combination of software and hardware. In embodiments, configuration and deployment system 120 may comprise a software application which may further comprise an installer and a user interface which may allow controlled access of one or more end users 130 to the one or more network services available on software infrastructure 140. The installer of configuration and deployment system 120 may receive from implementation team 110 one or more configurations enabling configuration and deployment system 120 to create, deploy, initialize, or modify software infrastructure 140 in a manner that meets the objectives of implementation team 110.

[0035] In embodiments, configuration and deployment system 120 may further comprise a system and method for implementing a series of actions with interdependencies. Each of the one or more network services or components comprising software infrastructure 140 may require its own declaration of necessary resources which may further require declaration of the configurations of such resources. Further, each of the one or more network resources or components may require declaration of necessary resources or configurations which overlap with other such network resources or components. Examples of overlapping resources may include, but not be limited to, an identity provider or a service provider, which may be internal or external to software infrastructure 140, and which may require declaration of a Transport Layer Security (TLS) certificate or a domain name through which they may communicate with other network services. The system and method for implementing a series of actions with interdependencies may allow configuration and deployment system 120 to retain a centralized set of configurations that may allow software infrastructure 140 to be created, deployed, initialized, or modified based upon the centralized set of configurations.

[0036] Further still, through the system and method for implementing a series of actions with interdependencies, configuration and deployment system 120 may employ dependency graph analysis to determine in which order it may be necessary to install the network services, components, or their dependencies. In constructing the dependency graph, embodiments of the configuration and deployment system 120 may leverage an embedded Domain Specific Language (eDSL) using category theoretic applicative and monadic composition.

[0037] By unifying the configurations of software infrastructure 140 within configuration and deployment system 120 and generating service-, resource-, or component-specific configurations through configuration and deployment system 120 in this manner, differing avenues of accessing the network services available on software infrastructure 140 may result in substantially similar or identical security policy enforcement. In addition to creating, deploying, initializing, or modifying software infrastructure 140, configuration and deployment system 120 may thus additionally function as an internal identity provider serving each of the one or more network services available on software infrastructure 140.

[0038] As used herein, “software” may comprise one or more lines of code, files, processes, threads of execution, subroutines, agents, applications, virtual machines, containers, pods, clusters, services, resources, or objects acting in isolation or in coordination with other such software, and may be stored on, operate on, execute on, or be accessible on hardware as defined herein.

[0039] As used herein, “hardware” may comprise one or more discrete components, processors, integrated circuits, computing devices, or servers, operating in isolation or in coordination with other such hardware across one or more data centers, availability zones, regions, or other scope- based or geographic-based combinations of hardware, or combinations of hardware and software. Hardware may further comprise volatile memory, non-volatile memory, random access memory (RAM), or read-only memory (ROM).

[0040] As used herein, “configurations” may comprise one or more settings, parameters, dependencies, interdependencies, actions, series of actions, manifests, or key-value pairs which may be included in one or more lists, files, configuration files, setting files, manifest files, initialization files, registries, or combinations thereof. [0041] As used herein, “allow controlled access” and its derivative forms “allowing controlled access” and “allowed controlled access” may comprise authentication or authorization, or combinations thereof, wherein authentication may comprise identifying who or what an entity is, and authorization may comprise what an entity is allowed to do, and wherein an entity may comprise a person, a machine, an application, or a service, or groups or combinations thereof. Conversely, “limiting access” and its derivative forms “limited access” and “access limitations” may comprise restricting an entity’s privileges to only those which the entity is authorized to perform. Collectively, an authentication and its associated authorization may be referred to herein as an “access profile.” Examples of authentication in simple systems may include a person providing a combination of username and password which uniquely identify the user, while in more complex systems an example of authentication may comprise provision of security credentials for a user or access profile which may comprise a token, a key, a key file, a public key, a private key, two-factor authentication (2FA) or combinations thereof. Examples of authorization may include an authority, an allowed activity, a permission, or a policy, or sets, groupings, or combinations thereof which may comprise a “role”. Examples of a permission may include view, write, execute, modify, create, read, update, or delete. Examples of roles may include, but not be limited to, a “monitor” role having view or read-only permissions, or a “test” role having only execute permissions. The relationship between permissions and roles may be one-to-one or many- to-one, while die relationship between roles and groups may be one-to-one, one-to-many, many-to- one, or many-to-many. Additionally, each of the one or more roles may be authorized to grant permissions to one or more network services, resources, or objects. For example, a “Project A Admin” role may be authorized to grant write permission to “Project A” resources, but not be authorized to grant write permission to “Project B” resources.

[0042] As used herein, “network services” may comprise software, hardware, or combinations of software and hardware which provide services, resources, or objects available for access by one or more entities or end users via a network, and wherein such services, resources, or objects may be physically or virtually internal or external to software infrastructure 140. Further, “network services” may comprise additional components or add-on components which extend or enhance the usability or operational efficiency of such services, objects, or resources, or the combined system as a whole, and may also comprise service providers or relying parties, either or which may be internal or external to software infrastructure 140. Examples of network services may include, but not be limited to, DNS hosting services, public cloud services, private cloud services, virtual private cloud services, virtualization services, containerization services, container orchestration services, networking services, routing services, load balancing services, storage services, database services, hosting services, log aggregation services, analytic services, visualization services, continuous integration services, or continuous deployment services. Trade names providing specific examples of such services may include Docker containerization services, Kubemetes container orchestration services, Loki log aggregation services, Grafana analytics and visualization services, ArgoCD continuous deployment services, or Istio routing services.

[0043] Returning to Fig. 1, method 100 begins at method step 111, with implementation team 110 determining the scope and architecture of software infrastructure 140. Characteristics of the scope and architecture may comprise which network services may be preferred or necessary to meet the objectives of implementation team 110, and which permissions, roles, and groups may be preferred or necessary for end users to be allowed controlled access to those network services. The scope and architecture of software infrastructure 140 may involve one or more access profiles having permissions to access, configure, modify, start, shut down, launch, initialize, stop, suspend, hibernate, view, administer, replicate, or cause to run the software, hardware, or combination of software and hardware comprising software infrastructure 140.

[0044] Implementation team 110 continues to apply the method along a first branch by identifying one or more permissions that may be desired in order for one or more end users 130 to access the network services of software infrastructure 140. Implementation team 110 progresses the method along this branch to include mapping the one or more permissions to one or more roles and mapping the one or more roles to one or more groups at method step 113. These one or more groups may be specified by, or stored within, one or more 3 ^rd party identity providers. In embodiments, the one or more 3 ^rd party identity providers may allow “single sign on” authentication of end user 130 via one or more authentication protocols, whereby authentication of end user 130 through the 3 ^rd party identity provider may convey to end user 130 one or more privileges associated with one or more groups to which end user 130 has been mapped. A variety of 3 ^rd party identity providers are known in the art, for example Microsoft Active Directory or Okta. Similarly, a variety of authentication protocols are known in the art, for example OAuth, OpenID Connect, Security Assertion Markup Language (S AML), or Lightweight Directory Access Protocol (LDAP). [0045] At 114, implementation team 110 completes this branch of the method by assigning one or more end users 130 to the one or more groups that were mapped by implementation team 110 at method step 113. It should be noted that the permissions, roles, groups, or end user assignments may not be static over the service period of software infrastructure 140. These steps of the method may be re-performed at any time based upon events which may occur during the service period of software infrastructure 140. For example, a new network service may be made available on software infrastructure 140, thus involving new permissions, roles, groups, and assignments to be created, or one or more end users 130 may be re-assigned among the one or more groups, or an end user 130 may be revoked access to one or more network services.

[0046] After determining the scope and architecture of software infrastructure 140 at method step 111, implementation team 110 may progress the method along a second branch by creating a superuser account at method step 115 for each of one or more on-premise or cloud service providers. As used herein, “superuser” refers to a special type of authorization which includes an unlimited set of permissions over the on-premise or cloud service. For example, in one embodiment of the method, implementation team 110 may create a superuser account with Amazon Web Services ^® , known as the Root user. In an alternate embodiments of the method, implementation team 110 may create a superuser account with Microsoft ^® Azure, Google ^® Cloud, or similar service providers.

[0047] Method 100 may continue along this second branch, with the following method steps being performed by configuration and deployment system 120. At 121, the method continues with configuration and deployment system 120 obtaining the authentication credentials of the superuser account created at 115 for each of the one or more on-premise or cloud service providers. The superuser authentication credentials are stored securely within configuration and deployment system 120, and will enable configuration and deployment system 120 to create, initialize, activate, start, configure, alter, suspend, hibernate, shut down, or terminate one or more network services available through the one or more on-premise or cloud service providers, and will further enable configuration and deployment system 120 to create, alter, or terminate one or more delegated access profiles which may comprise one or more authorizations associated with one or more authentications. In embodiments, the superuser authentication credentials may comprise secure tokens or keys which authorize configuration and deployment system 120 to access an application programming interface (API) made available by the on-premise or cloud service provider. [0048] The installer of configuration and deployment system 120 may continue the method at 122 by creating or modifying software infrastructure 140, which may comprise one or more network services, through each of the one or more superuser accounts obtained at 121. The creating or modifying of software infrastructure 140 may be performed based upon the one or more configurations passed to configuration and deployment system 120 at method step 116. In embodiments where configuration and deployment system 120 may be creating software infrastructure 140, completion of method step 122 may result in a “bare-bones” platform ready for initialization, wherein the platform may comprise one or more network services. As used herein, “bare-bones” may comprise an initial configuration of software infrastructure 140 and/or the one or more network services available on software infrastructure 140. Method 100 may then continue at method step 123, with configuration and deployment system 120 configuring software infrastructure 140 for federated authentication based upon one or more configurations passed to configuration and deployment system 120 at method step 117. In embodiments, performance of method step 123 may result in configuration and deployment system 120 creating a plurality of access profiles, wherein the access profiles may correspond to a variety of authorizations requiring authentication in order to allow controlled access to hardware, software, combinations of hardware and software, network services, applications, or combinations thereof deployed on software infrastructure 140. In embodiments the plurality of authorizations requiring authentication may further comprise superuser or root-level access to one or more network services or applications deployed on software infrastructure 140.

[0049] In embodiments, performance of method steps 122 and 123 may result in configuration and deployment system 120 receiving from the one or more on-premise or cloud service providers one or more configurations corresponding to one or more network services.

[0050] Through this method, authentication credentials for each of the one or more access profiles created or modified by configuration and deployment system 120 are retained within configuration and deployment system 120. Having these access credentials thus retained within configuration deployment system 120, the method progresses now to providing a means of allowing controlled access for one or more end users 130 to the one or more network services comprising software infrastructure 140.

[0051] As previously mentioned, configuration and deployment system 120 may comprise a user interface which may allow controlled access of one or more end users 130 to the one or more network services available on software infrastructure 140. In embodiments, the user interface may be implemented as a web-based user interface, as a command-line interface, or combinations thereof. In embodiments, the web-based user interface may be in communication with the command-line interface or vice-versa. Additionally, in embodiments, the web-based user interface may employ features such as long polling and one or more single-use nonce values to securely transfer authentication credentials as described below.

[0052] As previously mentioned, configuration and deployment system 120 may function as an internal identity provider serving each of the one or more network services available on software infrastructure 140. In such embodiments, configuration and deployment system 120 may coalesce multiple 3 ^rd party identity providers into a single source of authentication validation within software infrastructure 140, and thus enable service providers to allow end users 130 to sign in from different organizations, even if those service providers do not support such functionality themselves.

[0053] An end user 130 wishing to access one or more of the network services available on software infrastructure 140 may sign-in at method step 131 to the one or more 3 ^rd party identity providers through which end user 130 was assigned to one or more groups at method step 114. The sign-in may be initiated through either the web based user interface or the command-line interface, and may comprise deferring to the one or more 3 ^rd party identity providers to validate the authentication credentials of end user 130 which may then securely transmit the results of the validation to configuration and deployment system 120. In alternate embodiments, the validation of the authentication credentials of end user 130 may be performed through a separate user interface, for example one which may be associated with one of the one or more 3 ^rd party identity providers.

[0054] The one or more 3 ^rd party identity providers may then authenticate end user 130, and upon successfully being authenticated, an authentication token may be passed from the 3 ^rd party identity provider to configuration and deployment system 120 at step 133 of the method. The token may comprise authorization credentials associated to end user 130. In embodiments, the authorization credentials may comprise a unique identifier associated with the end user 130, one or more groups to which end user 130 was assigned at method step 114, an expiration timestamp, or cryptographic signatures providing verification that the token is authentic, or combinations thereof. In embodiments, the authentication and passing of the authentication token to configuration and deployment system 120 may be performed in a manner that is transparent to end user 130. In this manner, end user 130 may sign in once (“single sign-on”) in order to access each of the one or more network services which end user 130 has been granted authorization to access, and wherein such authorization may comprise only the permissions associated to the end user 130.

[0055] Having received the authentication token at method step 124, configuration and deployment system 120 determines the permissions available to the user to access the one or more network services available on software infrastructure 140 based upon the authentication credentials conveyed via the authentication token. In embodiments, configuration and deployment system 120 may determine the permissions available to end user 130 based upon the one or more groups included in the authorization token.

[0056] In embodiments, configuration and deployment system 120 may be configured to reject the authorization token if configuration and deployment system 120 determines that the authentication token is not valid or has expired. In embodiments, configuration and deployment system 120 may be configured to validate the authentication token, wherein the validation may be based upon cryptographic signatures which the authentication token may comprise, cryptographic signatures retained within configuration and deployment system 120, or combinations thereof. Similarly, configuration and deployment system 120 may be configured to reject an authentication token if a predetermined amount of time has elapsed since the authentication token was generated, which may be based upon an expiration timestamp which the authentication token may comprise. In embodiments, configuration and deployment system 120 may be further configured to reject an authentication token based upon a configurable expiration window. For example, configuration and deployment system 120 may be configured to reject an authentication token after about 30 minutes of the token being generated, to about 8 hours of the token being generated.

[0057] Upon determining that the authentication token should not be rejected, at method step 126 configuration and deployment system 120 may pass a request of end user 130 to access one or more of the network services available on software infrastructure 140 to one or more authentication services available within configuration and deployment system 120, which may comprise alternate embodiments of method step 125.

[0058] An intended outcome of method step 125 is that the request of end user 130 is securely authenticated to the desired network service available on software infrastructure 140. Access to the one or more network services which may provide functionality to end user 130 may be restricted based upon permissions which may be expressed by the one or more groups to which end user 130 has been assigned, which may me designated within the authentication token. Authentication of the user request to a particular network service may take the form of one of several embodiments. In a first embodiment, the network service may accept the authentication token received by configuration and deployment system 120 from the one or more 3 ^rd party authentication providers. In a second embodiment, the network service may require additional authorization information to be included with the authorization token, or in place of the authorization token. In a third embodiment, the network service may require that configuration and deployment system 120 impersonate an access profile, which may require impersonation information to be included with the authorization token, or in place of the authorization token. In alternate embodiments, the additional authorization information or impersonation information may take the form of HTTP headers, for example authorization HTTP headers or impersonation HTTP headers. Either of the first, second, or third embodiments may be performed through methods which may comprise use of a reverse proxy. Separately, either of the first, second, or third embodiments may be performed through methods which may comprise access by end user 130 via the web-based user interface, the command-line interface, or combinations thereof.

[0059] Upon successfully authenticating end user 130 to the desired network service, the request of end user 130 is passed to the authenticated network service at method step 127, and access to the authenticated network service may be granted to end user 130 via method step 134, such that end user 130 may access the authenticated network service at method step 132.

[0060] The method 100 just described may offer a number of advantages over prevailing conventional practices in the art. By automating the configuration and deployment of software infrastructure, the access profiles through which authentication may be required to access network services may be controlled by configuration and deployment system 120. In this manner, software infrastructure 140 may be configured, deployed, and maintained in a manner which may provide a more stable environment, and may thus reduce or eliminate downtime across the environment. Similarly, maintaining or implementing changes across the environment may be performed in a manner which may be more stable, less labor-intensive, and thus more cost effective.

[0061] Further advantages include that by automating the creation of network service access profiles or changes thereto, retaining the associated service-level access credentials within configuration and deployment system 120, and requiring end users to first authenticate in to configuration and deployment system 120 in order to be granted access to the network services available on software infrastructure 140, application of the methods just described may result in a substantially more secure environment. Further, these aspects of method 100 configuration and deployment system 120 enable an automated cascading of new, amended, or updated user-level access limitations which may be associated to one or more end users 130 across each of the one or more network services available on software infrastructure 140.

[0062] Under certain circumstances it may me desirable to deploy software infrastructure in whole or in part on Amazon Web Services ^® (or “AWS ^® ”). AWS® may offer a range of cloud- based services which may, for example, include storage services, database services, compute services, networking services, load balancing services, container services, analytics services or other cloud-based services which may be accessible via an Application Programming Interface (API).

[0063] In allowing users controlled access to these services, AWS ^® may provide an identity and access management service such as AWS ^® IAM, which may enable configuration of one or more security policies, roles, users, or user groups which may be used to limit access to the services via one or more credentials. For example, a security policy may specify that access to a specific service, such as a database, be limited to read access. That policy may then be associated to a user, or to a role. Similarly, a user group may be defined, and one or more roles or one or more users may be associated to the user group. In this manner, AWS ^® IAM may enable credentials having granular access privileges to be made available to a user, a role, a group, or combinations thereof. Providing further context to the methods that follow, AWS ^® may assign an Amazon ^® Resource Name (or “ARN”) to any resource which exists on the AWS ^® platform, including users, policies, groups, user groups, or services, wherein the ARN may be accessed through a string of characters uniquely identifying the ARN. For example, a policy which provides read only access to AWS ^® Direct Connect via the AWS ^® Management Console may have an Amazon ^® Resource Name of “am:aws:iam::aws:policy/AWSDirectConnectReadOnly Access”.

[0064] Despite the flexibility and level of convenience in providing this approach, deploying software infrastructure in whole or in part on AWS may introduce a level of complexity where the assignment of users to roles and/or groups may be preferred to be managed through one or more 3rd party identity providers. Synchronizing role and group assignments among a plurality of users across multiple platforms may introduce opportunities for errors and omissions to expose software infrastructure deployed on AWS ^® to security risks or operational interruptions or inefficiencies. [0065] The descriptions that follow detail methods and systems for simplifying user authentication and authorization workflows, in particular making available one or more credentials to one or more end users to execute AWS ^® API commands wherein authentication of the one or more users may be performed by one or more 3rd party identity providers.

[0066] As used herein, “execute AWS ^® API commands” or equivalent terminology may comprise starting, stopping, or causing to be performed any form of process, command, directive, system call, operation, query, or request which may be directed to one or more ARNs and which may be issued to or through one or more AWS ^® accounts 240.

[0067] Fig. 2 illustrates an overview of method 200 which may be implemented in hardware, software, or a combination of hardware and software, and which may enable one or more end users 230 to execute one or more AWS ^® API commands without requiring each end user 230 to hold user-specific AWS ^® security credentials. Method 200 comprises individual method steps performed by implementation team 210 and credentials management system 220, which may further comprise credentials management system server 222 and credentials management system client 224, each of which may be implemented in hardware, software, or a combination of hardware and software. In embodiments, implementation team 210 may determine a scope and architecture of an AWS ^® deployment, which may result in one or more desired or preferred configurations.

[0068] Through application of method 200, implementation team 210, credentials management system server 222, and credentials management system client 224 may enable end user 230 to execute one or more API commands through one or more Amazon Web Services ^® accounts 240. In embodiments, method 200 may further comprise one or more 3rd party identity providers 250, which may authenticate end user 230 in order to grant end user 230 access to execute the one or more AWS ^® API commands through the credentials management system client 224.

[0069] In embodiments, implementation team 210 may be in communication with credentials management system server 222 through the one or more configurations, and credentials management system server 222 may be in communication with credentials management system client 224 and vice-versa. In embodiments, credentials management system server 222 may be in communication with one or more 3rd party identity providers 250 and vice-versa, and credentials management system server 222 may be in communication with one or more Amazon Web Services ^® accounts 240 and vice-versa. In embodiments, one or more end users 230 may be in communication with credentials management system client 224 and vice-versa. Similarly, one or more end users 230 may be in communication with one or more 3rd party identity providers 250 and vice-versa.

[0070] In embodiments, communications between credentials management system server 222 and the one or more 3rd party identity providers 250 may be implemented using any known communications protocol or framework. For example, credentials management system server 222 may communicate with the one or more 3rd party identity providers 250 and vice-versa using OpenID Connect, OAuth, LDAP, Kerberos, or other standard or proprietary authentication workflow protocols. Further, authentication information may be exchanged between the one or more 3rd party identity providers 250 and credentials management system server 224 via any known method, for example through a security token. In embodiments, the security token may comprise authorization credentials associated to end user 230, which may further comprise, for example, a unique identifier associated with the end user 230, zero or more groups to which end user 230 may have been assigned by implementation team 210, an expiration timestamp, cryptographic signatures providing verification that the token is authentic, or combinations thereof. [0071] In embodiments, communications between credentials management system server 222 and credentials management system client 224 may be implemented using any known communications protocol or framework. For example, credentials management system server 222 may communicate with credentials management system client 224 and vice-versa utilizing remote procedure call frameworks such as gRPC, RESTful HTTPS APIs, or proprietary protocols or frameworks. Further, authentication or authorization information may be exchanged between credentials management system server 222 and credentials management system client 224 via any known method, for example through a security token. In embodiments, the token may comprise authentication or authorization credentials associated to end user 230 as described above.

[0072] In embodiments, communications between credentials management system server 222 and the one or more Amazon Web Services ^® accounts 240 may be implement using any communications protocol or framework supported by Amazon Web Services ^® .

[0073] In embodiments, end user 230 may be in communication with credentials management system client 224 and vice-versa via a command-line interface, end user 230 may be in communication with credentials management system server 222 and vice-versa via a web-based interface, and end user 230 may be in communication with the one or more 3rd party identity providers and vice-versa via a web-based interface or other interface supported by the one or more 3rd party identity providers.

[0074] In embodiments, method 200 may further comprise the embodiments of method steps illustrated by Figs. 3-5, wherein Fig. 3 illustrates an embodiment of a method through which an end user 230 may be authenticated to execute one or more AWS ^® API commands, Fig. 4 illustrates an embodiment of a method through which an end user 230 may obtain a list of roles available to the end user 230 which may allow the end user 230 to execute one or more AWS ^® API commands, and Fig. 5 illustrates an embodiment of a method through which an end user 230 may be authorized to execute one or more AWS ^® API commands by assuming a role which may allow the end user 230 to execute the one or more AWS ^® API commands.

[0075] Fig. 3 illustrates an embodiment of a method 300 through which an end user 230 may be authenticated to execute one or more AWS ^® API commands. An intended outcome of method 300 is that an end user 240 may be authenticated to credentials management system 220, which may be required before end user 230 may be able to execute one or more AWS ^® API commands. In embodiments, the intended outcome of method 300 may be achieved when a valid and current security token associated to the end user 230 is cached within the credentials management system 220 for subsequent reference.

[0076] Method 300 may begin at method step 302 when an end user 230 enters into credentials management system client 224 an instruction for credentials management system client 224 to execute. In embodiments, credentials management system client 224 my determine whether the instruction is relevant based on an end user 230 entering a client application name of credentials management system client 224 preceding a command desired to be executed by the end user 230. For example, end user 230 may enter “zehut roles” into a command line interface used to access the credentials management system client 224, wherein “zehut” may be recognized by credentials management system client 224 as the client application name of credentials management system client 224, and “roles” may be able to be interpreted by credentials management system 224 as a request to display a listing of roles available to the end user 230.

[0077] At method step 304, upon recognizing the client application name having been entered, credentials management system client 224 may establish a connection to communicate with credentials management system server 222. Next, at method step 306, credentials management system client 224 may determine whether a cached security token is available to be accessed or referenced by credentials management system client 224.

[0078] In certain embodiments, upon determining at method step 306 that a cached security token may be available, credentials management system client 224 may proceed to execute the command entered by an end user 230. For example, if an end user 230 may have entered “zehut roles” at the command line, upon determining that a cached security token is available credentials management system client 224 may proceed to display a listing of roles available to the end user 230.

[0079] In alternate embodiments, upon determining at method step 306 that a cached security token is available, the method may proceed down one of two separate branches.

[0080] Along a first branch following method step 306, credentials management system client 224 may next determine at method step 308 whether the security token is current and valid. In embodiments, within method step 308 the security token may be determined to be current if a timestamp included with the security token falls within an allowed window of time since having been generated, wherein the allowed window of time may be predetermined by implementation team 210, or may comprise one or more configurations of credentials management system server 222. Similarly, in embodiments, within method step 308, the security token may be determined to be valid by attempting to execute the command desired to be executed by the end user 230. For example, the security token may be determined to not be valid if upon attempting to execute the command credentials management system client 224 receives a response indicating “unauthorized.”

[0081] If at method step 308 the security token is determined to be current and valid, the method proceeds to step 340, wherein credentials management system client 224 caches the security token for subsequent access or reference.

[0082] If credentials management system client 224 determines either (1) a cached security token is not available at method step 306, or (2) a cached security token is not current and valid at method step 308, method 300 may proceed to method step 310. An intended outcome of the method steps 310-338 may be to obtain a current and valid security token for the end user 230 which may then be cached by credentials management system client 224 for subsequent access or reference. [0083] At method step 310, credentials management system client 224 may make an unauthenticated request to obtain from credentials management system server 222 a new nonce value and confirmation URL which may be accessed by the end user 230 via a web browser or other appropriate interface for authenticating the end user 230. Upon receiving the request, at method step 312, credentials management system server 312 may generate a nonce value, which may be included as query string parameter of the confirmation URL, which credentials management system server 222 may subsequently pass to credentials management system client 224 at method step 314. Upon receiving the confirmation URL from credentials management system server 224, in embodiments, credentials management system client 222 may then launch or open a web browser pointing to the confirmation URL at method step 316. In alternate embodiments, credentials management system client 222 may instruct the end user 230 to open a browser pointing to the confirmation URL. In embodiments, credentials management system client 224 may also begin long polling credentials management system server 222 for exchanging a nonce for a security token at method step 318, which may be performed simultaneously with method step 316. In this manner, credentials management client 224 may be requesting credentials management server 222 to verify the identity of the end user 230, and will wait until the confirmation is received or the confirmation is otherwise aborted.

[0084] After accessing the confirmation URL containing the nonce at method step 320, the user may then be connected to and able to communicate with credentials management system server 222. The method may then proceed to method step 322, wherein credentials management system server 222 may determine whether the end user 230 may be authenticated to credentials management system server 222 with valid and non-expired server credentials. From here, the method may proceed through one of two alternate branches.

[0085] If the end user 230 is logged in to credentials management server 222, the method may proceed through a first branch to method step 322, wherein credentials management system server 222 may generate a new security token for the end user 230.

[0086] If the end user 230 is not logged in to credentials management system server 222, the method may proceed through a second branch, wherein credentials management system server 222 may at method step 324 (1) set a new session cookie to identify the web browser, (2) generate a redirect corresponding to a 3rd party identity provider 250 associated to the end user 230, setting appropriate values in the session for later verification, and (3) redirect the end user 230’s browser to the 3rd party identity provider 250 associated to the end user 230 for authentication. It should be noted that the 3rd party identity provider may be associated to the end user 230 via one or more configurations performed by implementation team 210 when configuring credentials management system server 222.

[0087] This second branch continues with method step 326, wherein the end user 230 may be authenticated by the 3rd party identity provider 250 after providing authentication credentials at method step 328, which upon successful completion may then redirect the end user 230’s browser to an authentication completion page, wherein security token and session data is validated at method step 330, and the session may be updated to contain the end user 230’s validated identifier, a set of groups to which the end user 230 may have been associated by implementation team 210, and an expiration timestamp which may be based upon configuration values. This second branch then proceeds to method step 332, wherein credentials management system server 222 may generate a new security token for the end user 230.

[0088] From method step 332, the method proceeds to method step 334, wherein credentials system server 222 may associate the confirmation nonce with the security token generated at method step 332. Proceeding to method step 336, credentials management system server 222 may pass the security token to credentials management system server 224, which upon being received at method step 338 completes the long polling initiated at method step 318. After the newly generated security token has been received and the long polling completed, credentials management system client 224 caches the security token at method step 340 for subsequent access or reference.

[0089] Method 300 thus concludes having a valid and current security token associated to the end user 230 that is cached within credentials management system client 220 for subsequent reference. Method 300 may subsequently proceed to alternate embodiments comprising method 400 as illustrated in Fig. 4, or method 500 as illustrated in Fig. 5.

[0090] Fig. 4 illustrates an embodiment of a method 400 through which an end user 230 may request a list of roles available to the end user 230 through which the end user 230 may be authorized to execute one or more AWS ^® API commands. Method 400 begins at method step 402 having a valid and current security token associated to the end user 230 cached within credentials management system client 222, which may have resulted as an outcome of method 300. In alternate embodiments, a cached security token may need to be loaded into credentials management system client 224. [0091] At method step 402, the end user 230 may enter instructions directed to credentials management system client 224 into a command line interface, requesting a listing of roles available to the end user 230. For example, the end user 230 may enter the command “zehut roles.” Method 400 proceeds to method step 404, where upon having recognized the command, credentials management system client 222 establishes communication with credentials management system server 222 and requests a listing of roles associated to the cached security token, passing the security token as part of the request.

[0092] Upon receiving the request from credentials management system client 224, credentials management system server 222 may verify that the token received is current and valid at method step 406. After confirming that the security token is current and valid, credentials management system server 222 may retrieve from the security token an identifier which may uniquely identify the end user 230, and may also retrieve from the security token a listing of one or more groups associated to the end user at method step 408. With this information credentials management system server 222 obtains a listing of one or more roles mapped to the end user 230 at method step 410. It should be noted that one or more roles may be mapped to each of one or more end users by implementation team 210, and such mapping may be passed to credentials management system server 222 by implementation team 210 via one or more configurations as described in method 200.

[0093] Credentials management system server 222 proceeds to pass the listing of roles associated to the end user 230 to credentials management system client 224, which upon being received at method step 412 are subsequently echoed or displayed to the end user 230 via the command line interface at method step 414.

[0094] It should be noted a user cannot execute any AWS ^® API commands without credentials. Fig. 5 illustrates an embodiment of method 500 through which an end user 230 may execute one or more AWS ^® API commands by assuming a role which may allow the end user 230 to execute the one or more AWS ^® API commands.

[0095] The methods through which a role may be assumed may be based upon configurations retained within credentials management system server 222, which may have been determined by implementations team 210. As part of method 200, after determining a scope and architecture of an AWS ^® deployment, implementation team 210 may obtain one or more server credentials for the deployment. Additionally, as part of determining the scope and architecture, implementation team 210 may determine that the deployment may comprise one or more ARNs which may be associated with the AWS ^® deployment, identified herein as method step 514, which may be assumable via the one or more server credentials. As part of method 200, implementation team 210 may pass the one or more server credentials and details of the ARNs to credentials management system server 222 through one or more configurations which may be retained in credentials management system server 222, depicted herein at method step 516.

[0096] Method 500 begins at method step 502 having a valid and current security token associated to the end user 230 cached within credentials management system client 222, which may have resulted as an outcome of method 300. In alternate embodiments, a cached security token may need to be loaded into credentials management system client 224.

[0097] At method step 502, the end user 230 may enter instructions to execute a command into a command line interface, directed to credentials management system client 224, while additionally specifying a role to be used to execute the command. Hereafter, the role specified by the end user 230 will be referred to as a “specified role”. Method 500 proceeds to method step 504, where upon having recognized the command, credentials management system client 222 establishes communication with credentials management system server 222 and requests a listing of roles associated to the cached security token, passing the security token as part of the request.

[0098] Upon receiving the request from credentials management system client 224, credentials management system server 222 may verify that the token received is current and valid at method step 506. After confirming that the security token is current and valid, credentials management system server 222 may retrieve from the security token an identifier which may uniquely identify the end user 230, and may also retrieve from the security token a listing of one or more groups associated to the end user at method step 508.

[0099] The method proceeds to method step 510, wherein credentials management system server 222 validates that at least one group associated to the end user 230 via the security token is included in a listing of groups approved for the specified role. In embodiments, credentials management system server 222 may instruct credentials management system client 224 to report an error to the end user 230 if the specified role is not in this manner accessible by the end user 230.

[00100] Method 500 then proceeds to method step 512, wherein credentials management system server 222 identifies the ARN name associated with the specified role. The method then proceeds to method step 518, wherein credentials management server 222 may access AWS ^® using the one or more server credentials and may then execute at method step 520 an AWS ^® Security Token Service AssumeRole API call, specifying (1) a session identifier which may include an identifier of the end user 230, which may be retained by AWS ^® for audit purposes, (2) a timeout value specified in the one or more configurations determined by implementation team 210 and retained in credentials management system server 222, and (3) the ARN identifier associated with the specified role.

[00101] At method step 522, AWS ^® may respond by providing temporary credentials, which may comprise an access key, a secret key, a session token, an expiry duration, or combinations thereof, to credentials management system server 222, which may then be passed to credentials management system client 224 at method step 524. Upon receiving the temporary credentials, credentials management system client 224 may cache the temporary credentials associated with the assumed role at method step 526 for subsequent access or reference by the end user 230. The method then proceeds to method step 528, wherein the command may be executed using the specified role in conjunction with the temporary credentials.

[00102] The results of executing the command may be reported to the end user 230. At method step 530 the method may conclude through one of two branches. If executing the command may result in an error, the credentials management system client 224 may generate an error message at method step 532, which may be subsequently presented to the end user 230 at method step 534. If executing the command was executed without error, the credentials management system client 224 may generate a message that the command was successfully executed at method step 536, which may be subsequently presented to the end user 230 at method step 538.

[00103] Methods 200 through 500 just described may offer a number of advantages over prevailing conventional practices of accessing AWS ^® services. For example, by enabling an end user to discover through the command line a listing of roles which may be available to the end user to execute AWS ^® API commands, methods 200 through 500 may introduce workflow efficiencies surrounding user on-boarding, especially where reliance upon a command line interface may be commonplace. Additionally, in environments where user authentication may be desired or preferred to be performed by one or more 3rd party identity providers, methods 200 through 500 may present advantages over alternate methods which require synchronization between one or more 3rd party identity providers and AWS ^® . Further, by providing a centralized means of off- boarding a user, methods 200 through 500 may offer sizable advantages over prevailing practices in minimizing security vulnerabilities where a user may need to be off-boarded, for example following termination.

[00104] It is to be understood that method 200, 300, 400, and 500 are not limited to AWS ^® but may be applied to any cloud-based platform. A cloud-based platform may include any cloud-based platform that carries out computing services.

[00105] This application incorporates by reference the disclosure of PCT/US2021/04206, titled “A System and Method for Configuring and Deploying Software Infrastructure” herein in its entirety.

[00106] Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations may be made herein without departing from the spirit and scope of the invention as defined by the appended claims.