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:
RELATED APPLICATIONS 
       [0001]    The present disclosure is: a non-provisional filing of, is co-pending with, and claims priority under 35 U.S.C. 119(e) to U.S. Provisional Patent Application Ser. No. 61/364,632, filed on Jul. 15, 2010, entitled: “Identity-Enabled Management Interface,” the disclosure of which is incorporated by reference herein and below in its entirety. 
     
    
     BACKGROUND 
       [0002]    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 
       [0003]    In various embodiments, techniques for identity-enabled interface deployment are presented. More specifically, and in an embodiment, a method for interface deployment is provided. 
         [0004]    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 
         [0005]      FIG. 1  is a diagram of an architecture for identity-enabled interface deployment within a cloud network, according to an example embodiment. 
           [0006]      FIG. 2  is a method for identity-enabled interface deployment, according to an example embodiment. 
           [0007]      FIG. 3  is a diagram of another method for identity-enabled interface deployment, according to an example embodiment. 
           [0008]      FIG. 4  is a diagram of an identity-enabled interface deployment system, according to an example embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0009]    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. 
         [0010]    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. 
         [0011]    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. 
         [0012]    The phrases “processing environment,” “cloud processing environment,” and the term “cloud” may be used interchangeably and synonymously herein. 
         [0013]    Moreover, it is noted that a “cloud” refers to a logical and/or physical processing environment as discussed above. 
         [0014]    The phrase “cloud network” refers to a network of cloud processing environments logically being managed as a single collective network. 
         [0015]    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. 
         [0016]    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. 
         [0017]    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. 
         [0018]    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. 
         [0019]    It is within this context that embodiments of the invention are now discussed within the context of  FIGS. 1-4 . 
         [0020]      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. 
         [0021]    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. 
         [0022]    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. 
         [0023]    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 . 
         [0024]    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. 
         [0025]    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. 
         [0026]    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. 
         [0027]    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. 
         [0028]    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.). 
         [0029]    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&#39;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&#39;s infrastructure and that is used with other requests from Agent  420  to the CSP Interface  220 . 
         [0030]    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&#39;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 . 
         [0031]    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.). 
         [0032]    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. 
         [0033]    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. 
         [0034]    With the invention, a secure and identity-enabled processing environment can be established between an enterprise and a cloud provider. 
         [0035]      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. 
         [0036]    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. 
         [0037]    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 . 
         [0038]    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 ). 
         [0039]    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. 
         [0040]    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. 
         [0041]    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. 
         [0042]    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. 
         [0043]    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. 
         [0044]    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. 
         [0045]    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. 
         [0046]    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. 
         [0047]    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. 
         [0048]    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. 
         [0049]      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. 
         [0050]    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. 
         [0051]    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 . 
         [0052]    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&#39;s security manager. 
         [0053]    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. 
         [0054]    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   
         [0055]    In an embodiment, at  331 , the enterprise interface deployment manager obtains the enterprise token in an encrypted format. 
         [0056]    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. 
         [0057]    At  340 , the enterprise interface deployment manager uses, via the security manager, the enterprise token to enforce cloud policy within the enterprise environment. 
         [0058]    In an embodiment, at  350 , the enterprise interface deployment manager uses a PDP manager to enforce the cloud policy within the enterprise environment. 
         [0059]    In another situation, at  360 , the enterprise interface deployment manager operates the security manager as a particular cloud environment interface within the enterprise environment. 
         [0060]    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. 
         [0061]      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. 
         [0062]    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. 
         [0063]    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. 
         [0064]    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 . 
         [0065]    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 . 
         [0066]    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. 
         [0067]    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 . 
         [0068]    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 . 
         [0069]    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 . 
         [0070]    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.