WO2022006472A1

WO2022006472A1 - A system and method for configuring and deploying software infrastructure

Info

Publication number: WO2022006472A1
Application number: PCT/US2021/040206
Authority: WO
Inventors: Michael SNOYMAN; Aron TRAURING; Christopher DONE
Original assignee: Fp Complete Corporation
Priority date: 2020-07-01
Filing date: 2021-07-01
Publication date: 2022-01-06

Abstract

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 modern DevOps tooling. One embodiment may comprise a method of delegating authentication across network service deployments, comprising receiving single sign-on login credentials for a user, authenticating the user's single sign-on credentials, enforcing user-access limitations throughout at least one network service for the user based on predetermined security policies, updating the user-access limitations based on a change in privileges assigned to the user, and cascading the updated user-access limitations throughout the at least one cloud service provider infrastructure.

Description

A System and Method for Configuring and Deploying Software Infrastructure

CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims priority to provisional application serial number 63/047,161 filed July 1, 2020, titled “A System and Method for Configuring and Deploying Software Infrastructure,” 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] 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 [0017] 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.

[0018] 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.

[0019] 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. [0020] 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.

[0021] 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 [0022] For a detailed description of the preferred embodiments of the invention, reference will now be made to the accompanying drawings in which:

[0023] Figure 1 illustrates a method for configuring and deploying software infrastructure.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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).

[0034] 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.

[0035] 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 the 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. [0036] 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.

[0037] 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.

[0038] 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 (SAML), or Lightweight Directory Access Protocol (LDAP).

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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. [0044] 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.

[0045] 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.

[0046] 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.

[0047] 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. [0048] 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.

[0049] 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.

[0050] 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. [0051] 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.

[0052] 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.

[0053] 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.

[0054] 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 maimer which may be more stable, less labor-intensive, and thus more cost effective.

[0055] 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.

[0056] 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.

Claims

CLAIMS What is claimed is:

1. A method of delegating authentication across a network services deployment, comprising: a. receiving single sign-on login credentials for a user; b. authenticating the user’s single sign-on credentials; c. enforcing user-access limitations throughout at least one network service for the user based on predetermined security policies; d. updating the user-access limitations based on a change in privileges assigned to the user; and e. cascading the updated user-access limitations throughout the network services deployment.

2. The method of claim 1, further comprising the user providing the single sign-on credentials through a user interface.

3. The method of claim 2, wherein the user interface comprises a web-based user interface.

4. The method of claim 2, wherein the user interface comprises a command line interface.

5. The method of claim 1, wherein the authenticating is performed by one or more 3^rd party identity providers.

6. The method of claim 5, wherein the authenticating further comprises transmitting a secure token.

7. The method of claim 6, wherein the secure token comprises a unique identifier for the user, one or more groups to which the user is assigned, an expiration timestamp, a cryptographic signature, or combinations thereof.

8. The method of claim 7, further comprising enforcing user-access limitations based upon the one or more groups to which the user is assigned.

9. The method of claim 6, wherein the enforcing further comprises providing the secure token to one or more network services available to the user.

10. The method of claim 9, further comprising including additional information with the secure token being provided.

11. The method of claim 10, wherein the additional information comprises authorization information.

12. The method of claim 10, wherein the additional information comprises impersonation information.

13. The method of claim 10, wherein the additional information comprises HTTP headers.

14. The method of claim 6, wherein the transmitting further comprises long polling.

15. The method of claim 6, wherein the transmitting further comprises employing one or more single-use nonce values.

16. The method of claim 6, further comprising rejecting a user’s single sign-on credentials.

17. The method of claim 15, wherein the rejecting is based upon a secure token that has expired.

18. The method of claim 16, wherein the secure token expired after about 30 minutes of being generated, to about 8 hours of being generated.

19. The method of claim 6, wherein the enforcing is performed by a configuration and deployment system functioning as an internal identity provider for the network services deployment.

20. The method of claim 5, wherein the authenticating comprises two-factor authentication (2FA).