TECHNIQUES FOR IDENTITY-ENABLED INTERFACE DEPLOYMENT

Abstract

Techniques for providing identity-enabled interfaces for deployment are presented. Specifically, an agent of an enterprise infrastructure authenticates and acquires an agent identity for interacting with a cloud processing environment. Once the agent is deployed in the cloud processing environment, enterprise policy can be enforced within the cloud processing environment on actions occurring within the cloud. The agent acts as an Application Programming Interface between the enterprise and the cloud processing environment. The reverse is also achievable, where a cloud deploys an agent to the enterprise to deploy a cloud interface within the enterprise for policy enforcement.

Description

BACKGROUND

The Internet is rapidly evolving to include an operational mode called Cloud Computing and Cloud Storage. The intent of these new modes is the reduction of enterprise data centers and the excess capacity contained in such. In order to provide services to customers, the enterprise is often compelled to host high levels of excess capacity (sometimes over 80%) to take care of unanticipated traffic (e.g., a national emergency such as 9/11) and anticipated traffic (e.g., the Christmas consumer buying season). The cloud operational characteristics allow an enterprise to quickly utilize computing and storage capacity in the cloud when increases in traffic or some other increase in the need for computing and storage resources is needed. However, this capability must be supported by an appropriate API by cloud providers, which heretofore is unavailable.

SUMMARY

In various embodiments, techniques for identity-enabled interface deployment are presented. More specifically, and in an embodiment, a method for interface deployment is provided.

Particularly, a cloud agent is configured for deployment within a target cloud environment. The cloud agent is configured within an enterprise environment. The cloud agent is authenticated and a cloud agent identity is obtained. Next, an expiration condition is assigned to the cloud agent identity that when satisfied renders the cloud agent identity invalid and the cloud agent is deployed to the target cloud environment for enforcement of enterprise policy within the target cloud environment, via the cloud agent.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an architecture for identity-enabled interface deployment within a cloud network, according to an example embodiment.

FIG. 2 is a method for identity-enabled interface deployment, according to an example embodiment.

FIG. 3 is a diagram of another method for identity-enabled interface deployment, according to an example embodiment.

FIG. 4 is a diagram of an identity-enabled interface deployment system, according to an example embodiment.

DETAILED DESCRIPTION

A “resource” includes a user, service, system, device, directory, data store, groups of users, combinations of these things, etc. A “principal” is a specific type of resource, such as an automated service or user that acquires an identity. A designation as to what is a resource and what is a principal can change depending upon the context of any given network transaction. Thus, if one resource attempts to access another resource, the actor of the transaction may be viewed as a principal.

An “identity” is something that is formulated from one or more identifiers and secrets that provide a statement of roles and/or permissions that the identity has in relation to resources. An “identifier” is information, which may be private and permits an identity to be formed, and some portions of an identifier may be public information, such as a user identifier, name, etc. Some examples of identifiers include social security number (SSN), user identifier and password pair, account number, retina scan, fingerprint, face scan, etc.

A “processing environment” defines a set of cooperating computing resources, such as machines, storage, software libraries, software systems, etc. that form a logical computing infrastructure. A “logical computing infrastructure” means that computing resources can be geographically distributed across a network, such as the Internet. So, one computing resource at network site X and be logically combined with another computing resource at network site Y to form a logical processing environment.

The phrases “processing environment,” “cloud processing environment,” and the term “cloud” may be used interchangeably and synonymously herein.

Moreover, it is noted that a “cloud” refers to a logical and/or physical processing environment as discussed above.

The phrase “cloud network” refers to a network of cloud processing environments logically being managed as a single collective network.

The embodiments herein provide techniques so that a Cloud Management Application Programming Interface (API) can be used by an enterprise to provide identity, role, and other such mechanisms via the API so that workloads in the cloud can be positively identified and the appropriate policies applied within the cloud.

Various embodiments of this invention can be implemented in existing network architectures. For example, in some embodiments, the techniques presented herein are implemented in whole or in part in the Novell® network and proxy server products, operating system products, cloud-based products or services, directory-based products and other products and/or services distributed by Novell®, Inc., of Waltham, Mass.

Also, the techniques presented herein are implemented in machines, such as processor or processor-enabled devices. These machines are configured to specifically perform the processing of the methods and systems presented herein. Moreover, the methods and systems are implemented and reside within a non-transitory and computer-readable or processor-readable storage media and processed on the machines (processing devices) configured to perform the methods.

Of course, the embodiments of the invention can be implemented in a variety of architectural platforms, devices, operating and server systems, and/or applications. Any particular architectural layout or implementation presented herein is provided for purposes of illustration and comprehension only and is not intended to limit aspects of the invention.

It is within this context that embodiments of the invention are now discussed within the context of FIGS. 1-4.

FIG. 1 is a diagram of an architecture for identity-enabled interface deployment within a cloud network, according to an example embodiment. It is noted that the architecture is presented for purposes of illustration and that other arrangements are possible to achieve the beneficial teachings presented herein and below.

Again, embodiments and components of the architecture are implemented, programmed, and reside in a non-transitory computer-readable medium that executes on one or more processors that are specifically configured to process the components described herein and below.

The FIG. 1 shows an embodiment in terms of the architecture diagram contained in the Distributed Management Task Force (DMTF) Cloud Management Architecture white paper (DSP-IS0102_1.0.0). All 400-level diagram elements are provided and integrated in a novel manner by the embodiments presented herein to enhance and improve on the DMTF teachings.

An administrator 405 or Configuration mechanism 407 provides information to the Agent Console 410 concerning Agents 420 that are to interact with the various cloud providers via a Cloud Service Provider (CSP) Interface 220.

In an embodiment, the Agent Console 410 authenticates with the Identity Provider of Identity Service (IDP) 160 via 406 with credentials provided by the administrator 405 or Configuration 407. The authentication causes the crafting of an identity (e.g., SAML assertion) that contains the rights, permissions, roles, etc. that the Agent Console 410 is allowed to operate with.

Implicit in, but not shown in, the FIG. 1 is the presence of a Policy Decision Point (PDP) that evaluates each action in terms of the identity and the rights, permissions, roles, etc. contained within the identity.

The Agent Console 410, using information provided by the administrator 405 or Configuration 407 starts, stops, clones, etc. Agent 420 and provides operational events via 407 such that the Agent 420 is able to interact with a Cloud Provider as detailed below.

The Agent 420 communicates with the IDP 160 and authenticates via credentials obtained via 407. Successful authentication provides the Agent 420 with an identity (e.g., SAML assertion) that contains rights, permissions, roles, etc. that the Agent 420 is allowed to operate with. Also contained within the identity is a TTL (Time-To-Live setting) or some other expiration specification. If the Agent 420 is expected to operate longer than the expiration specification, an event is sent to Event Timer 430 via 431 that serves to allow Event Timer 430 to provide an event to Agent 420 and/or Agent Console 410 and/or Network Operations Center (NOC) Situation Display 440 that results in credentials being provided to Agent 420 so that a new authentication can be affected via 421, which extends the expiration specification.

In an embodiment, the NOC Situation Display 440 receives events via 441 and 442, which are displayed in the NOC operational display to allow NOC personnel to perform the appropriate activities (e.g., provide new credentials to Agent 420, etc.).

The Agent 420 communicates securely (e.g., via SSL) with the Security Manager 225 within the CSP Interface 220 via the mechanism specified by the cloud provider (e.g., (Representational State Transfer (RESTful), REST-like, Simple Object Access Protocol (SOAP), Remote Procedure Call (RPC), etc.) requesting authentication of Agent 420 and does so by providing the identity obtained via 421. The identity is verified by Security Manager 225 by validating the identity (e.g., SAML assertion) via the IDP 260, which has a trust relationship previously established with the IDP 160. The trust relationship details the trust level that the cloud provider has with the enterprise so that the validity of the identity can be ascertained (e.g., verify the SAML assertion's digital signature) as well as validating the rights, permissions, roles, etc. that the Agent 420 is requesting to act under. The Security Manger 225 returns to the Agent 420 a token that is specific to the cloud provider's infrastructure and that is used with other requests from Agent 420 to the CSP Interface 220.

In an embodiment, The Security Manager 225 within the CSP Interface 220 communicates securely (e.g., via SSL) with the Agent 420 via the mechanism specified by the cloud provider (e.g., RESTful, REST-like, SOAP, RPC, etc.) requesting authentication of Security Manager 225 within the CSP Interface 220 and does so by providing an identity obtained from IDP 260 by the Security Manager 225. The identity is verified by Agent 420 by validating the identity (e.g., SAML assertion) via the IDP 160, which has a trust relationship previously established with the IDP 260. The trust relationship details the trust level the cloud provider has with the enterprise so that the validity of the identity can be ascertained (e.g., verify the SAML assertion's digital signature) as well as validating the rights, permissions, roles, etc. that the Security Manager 225 within the CSP Interface 220 is requesting to act under. The Agent 420 returns to the Security Manager 225 within the CSP Interface 220 a token that is specific to the enterprise infrastructure and that is used with other requests from Security Manager 225 within the CSP Interface 220 to the Agent 420.

If both of the previous processing scenarios are used then a bidirectional mechanism is established so that requests from the enterprise to the cloud provider and from the cloud provider to the enterprise can be processed while applying policy (via the PDP) to all requests. In either case (one way or two ways) all requests can be evaluated according to identity (rights, permissions, roles, etc.).

The token supplied as specified above may be a Globally Unique Identifier (GUID) or a more complex structure, which is provided with subsequent requests. Receiving processes can validate the request by establishing the relationship between the token and trust relationship (perhaps by a table look up or request to the IDP to verify). The intent is to replace the heavy-weight identity (e.g., SAML) process with something much easier and quicker to implement/process. The token may or may not be encrypted. If it is encrypted, the token can be encrypted via a symmetric key since the processing load of a symmetric key cryptogram is much less than that of an asymmetric cryptogram. Although if desired, the token in other embodiments can also be encrypted using asymmetric mechanisms as well.

Note that the token may have an expiration specification that is different from the identity expiration specification. This particular expiration specification is handled internal to the Agent 420 or Security Manager 225 within the CSP Interface 220 because the renewal of the token is based on the already established identity. However, if the identity expiration specification is to expire before the next token expiration, the mechanism specified above for obtaining a new identity is performed followed by the steps to obtain a new token.

With the invention, a secure and identity-enabled processing environment can be established between an enterprise and a cloud provider.

FIG. 2 is a method 200 for identity-enabled interface deployment, according to an example embodiment. The method 200 (herein after referred to as “cloud interface deployment manager”) is implemented, programmed, and resides within a non-transitory computer-readable storage medium. One or more processors of a network are specifically configured to execute the cloud interface deployment manager. The network may be wired, wireless, or a combination of wired and wireless.

At 210, the cloud interface deployment manager configures a cloud agent for deployment to a target cloud environment. The cloud agent is configured to process on the processors of the target cloud environment and to use interfaces that the target cloud environment uses.

At 220, the cloud interface deployment manager authenticates the cloud agent and obtains a cloud agent identity. This can occur in a variety of manners and through a variety of interactions as discussed above with reference to the FIG. 1.

For example, at 221, the cloud interface deployment manager interacts with a third-party identity service. Credentials are supplied for the cloud agent. In one case, the credentials are supplied to the identity service via an administrator that uses an agent console (as discussed and presented above with reference to the FIG. 1).

At 230, the cloud interface deployment manager assigns an expiration condition to the cloud agent identity. When the expiration condition is satisfied, the cloud agent identity becomes invalid or unusable.

According to an embodiment, at 231, the cloud interface deployment manager receives an event from a cloud agent that it will extend beyond the expiration condition. In response to this event, the cloud interface deployment manager re-authenticates the cloud agent to obtain a new and updated expiration condition that lasts for a length of time that the cloud agent anticipates to extend processing for.

In another case, at 232, the cloud interface deployment manager assigns the expiration condition as a time-to-live (TTL) attribute to the cloud agent identity.

At 240, the cloud interface deployment manager deploys the cloud agent to the target cloud environment for enforcement of enterprise policy within the target cloud environment.

In an embodiment, at 250, the cloud interface deployment manager requests, via the deployed cloud agent, a security token from a security manager of the target cloud environment. The security token is unique to the target cloud environment.

Continuing with the embodiment of 250 and at 251, the cloud interface deployment manager uses, via the deployed cloud agent, the security token with each request issued within the target cloud environment to validate each request and to enforce the enterprise policy with each request.

Continuing with the embodiment of 250 and at 252, the cloud interface deployment manager receives, via the deployed cloud agent, a token expiration condition with the security token. The security token becomes invalid for use within the target cloud environment when the token expiration condition is met.

Continuing with the embodiment of 252 and at 253, the cloud interface deployment manager identifies, via the deployed cloud agent, the token expiration condition as being different from the expiration condition of the cloud agent identity.

Still continuing with the embodiment of 250 and at 254, the cloud interface deployment manager recognizes, via the deployed cloud agent, the security token as a globally unique identifier for the target cloud environment.

Again continuing with the embodiment of 250 and at 255, the cloud interface deployment manager uses, via the deployed cloud agent, a cloud provider interface dictated by the target cloud environment to interact with the security manager of the target cloud environment.

FIG. 3 is a diagram of another method 300 for identity-enabled interface deployment, according to an example embodiment. The method 300 (herein after referred to as “enterprise interface deployment manager”) is implemented, programmed, and resides within a non-transitory computer-readable storage medium. One or more processors of a network are specifically configured to execute the cloud interface deployment manager.

The cloud interface deployment manager represented by the method 200 of the FIG. 2 is presented from the perspective of an enterprise deploying an interface for policy enforcement in a cloud environment. Whereas the enterprise interface deployment manager is presented from the perspective of a cloud interface being deployed in an enterprise environment. It is not that the two methods 200 and 300 are not mutually exclusive such that both can be operational to establish a bi-directional deployment of identity based interfaces.

At 310, the enterprise interface deployment manager interacts with a cloud agent. The cloud agent previously deployed to a cloud environment by an enterprise environment using a cloud provider interface. The mechanism for deploying the cloud agent was presented above with respect to the FIGS. 1 and 2.

At 320, the enterprise interface deployment manager requests that the cloud agent authenticate a security manager of the cloud environment to the enterprise environment. So, the deployed cloud agent is now authenticating a cloud provider's security manager.

According to an embodiment, at 321, the enterprise interface deployment manager authenticates the security manager to specific rights, roles, and permissions within the enterprise environment.

At 330, the enterprise interface deployment manager receives, via the security manager, an enterprise token that is specific to the enterprise environment. This is done in response to the successful authentication of the security manager as presented with the processing of 320.

In an embodiment, at 331, the enterprise interface deployment manager obtains the enterprise token in an encrypted format.

Continuing with the embodiment of 331 and at 332, the enterprise interface deployment manager uses a symmetric key to decrypt the encrypted format of the enterprise token.

At 340, the enterprise interface deployment manager uses, via the security manager, the enterprise token to enforce cloud policy within the enterprise environment.

In an embodiment, at 350, the enterprise interface deployment manager uses a PDP manager to enforce the cloud policy within the enterprise environment.

In another situation, at 360, the enterprise interface deployment manager operates the security manager as a particular cloud environment interface within the enterprise environment.

So, one can now see via the discussions of FIGS. 1-3 how policy can be enforced from an enterprise environment within a cloud environment and from a cloud environment within an enterprise environment. The policy is identity-enabled via the authentication and identity mechanisms presented above.

FIG. 4 is a diagram of an identity-enabled interface deployment system 400, according to an example embodiment. Components of the identity-enabled interface deployment system 400 are implemented, reside, and programmed within non-transitory computer-readable storage medium as instructions that are executed on one or more processors of a network. The network can be wired, wireless, or a combination of wired and wireless.

In an embodiment, the identity-enabled interface deployment system 400 implements, inter alia, portions of the architecture presented above with respect to the FIG. 1 and the methods 200 and 300 of the FIGS. 2 and 3, respectively.

The identity-enabled interface deployment system 400 includes an enterprise processing environment 401 and a cloud processing environment 402. Each of these components and their interactions with one another will now be discussed in turn.

The enterprise processing environment 401 includes a plurality of enterprise processing devices. Example processing associated with the enterprise processing environment 401 was presented above with respect to the FIGS. 1 and 2.

The enterprise processing environment 401 configures a cloud agent for deployment to the cloud processing environment for purposes of enforcing enterprise policy within the cloud processing environment 402.

According to an embodiment, the cloud agent acquires a cloud token that is specific to the cloud processing environment 402 from a security manager to enforce the enterprise policy.

The cloud processing environment 402 includes a plurality of cloud processing devices. Example processing associated with the cloud processing environment 402 was presented above with respect to the FIGS. 1 and 3.

The cloud processing environment 402 uses a security manager of the cloud processing environment 402 to interact with the cloud agent for purposes of enforcing cloud policy in the enterprise processing environment 401.

In an embodiment, the security manager acquires an enterprise token that is specific to the enterprise processing environment 401 from the cloud agent for purposes of enforcing the cloud policy within the enterprise processing environment 401.

The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. (canceled)

2. A method, comprising: authenticating, by a cloud agent, for operation within a cloud environment;obtaining, by the cloud agent, security policy for the cloud environment; andenforcing, by the cloud agent, the security policy within the cloud environment

3. The method of claim 2, wherein authenticating further includes obtaining a credential that expires when authenticating.

4. The method of claim 3, wherein obtaining further includes using a mechanism for obtaining a new credential when the credential expires and re-authenticating, by the cloud agent, for operating within the cloud environment.

5. The method of claim 2, wherein authenticating further includes obtaining a token when authenticating that is unique to the cloud environment and the cloud agent, wherein the token required for operation of the cloud agent within the cloud environment.

6. The method of claim 2, wherein authenticating further includes receiving a Time-To-Live setting that defines how long the cloud agent is permitted to process within cloud environment.

7. The method of claim 6, wherein enforcing further includes sending an even indicating by the cloud agent that the cloud agent expects to processing longer than a time identified in the TTL setting.

8. The method of claim 7, wherein sending further includes receiving a credential by the cloud agent in response to the event.

9. The method of claim 8 further comprising, detecting, by the cloud agent, a lapse in the time and re-authenticating, by the cloud agent, for processing within the cloud environment.

10. The method of claim 9, wherein detecting further includes obtaining, by the cloud agent, a new TTL with a new time for the cloud agent to process within the cloud environment.

11. The method of claim 2, wherein authenticating further includes receiving, by the cloud agent, a token in response to authenticating, wherein the token is encrypted and includes identity information for the cloud agent and an expiration specification that identifies conditions for which the authentication of the cloud agent expires for processing with the cloud environment.

12. A method, comprising: receiving a request for authentication of a cloud agent for processing within a cloud environment;providing the cloud agent with a token having encrypted identity information cloud agent and an expiration specification defining conditions that revoke authentication of the cloud agent in response to successful authentication of the cloud agent;obtaining a second request from the cloud agent subsequent to the successful authentication of the cloud agent requesting modification to the expiration specification; andsending the cloud agent, a new token having the modified expiration specification.

13. The method of claim 12 further comprising, receiving the new token from the cloud environment and re-authenticating the cloud agent for processing within the cloud environment in accordance with the modified expiration specification.

14. The method of claim 12, wherein providing further includes associating access rights for the cloud agent when processing within the cloud environment with the token.

15. The method of claim 14, wherein associating further includes identifying at least some access rights as permissions that authorize the cloud agent to authenticate other applications for processing within the cloud environment.

16. The method of claim 14, wherein associating further includes identifying at least some access rights as permissions that authorize the cloud agent to enforce security policies within the cloud environment.

17. The method of claim 14, wherein associating further includes identifying at least some access rights as permission that authorize the cloud agent to interact with an existing security manager of the cloud environment to augment security enforcement within the cloud environment.

18. The method of claim 12, wherein providing further includes augmenting the token with identify information that is unique to the cloud environment.

19. A system comprising: a server; andan identity manager configured to: i) execute on one or more processors of the server, ii) provide a mechanism for authenticating a cloud agent for enforcing security policy within a cloud environment, and iii) provide a mechanism for the cloud agent to extend authentication for enforcing the security policy within the cloud environment before a condition occurs that invalidates the cloud agent for enforcing security policy within the cloud environment.

20. The system of claim 19, wherein the mechanism at least in part includes an encrypted token identifying a unique identity for the cloud agent, a unique identity for the cloud environment, a credential, and the condition.

21. The system of claim 19, wherein the mechanism also includes access rights permitting the cloud agent to enforce additional security within the cloud environment beyond what is performed by an existing security manager that processes within the cloud environment.