Increasingly, services and communication are achieved over the Internet and the World-Wide Web (WWW). Geographical location is becoming irrelevant with respect to network connectivity. Furthermore, the physical devices used by individuals to communicate and conduct business are increasingly becoming transparent through machine virtualization techniques and miniaturization.
In a Virtual Desktop Infrastructure (VDI) system, virtual machines are spawned or instantiated on demand. The identity of a virtual machine is established when it is instantiated. In a typical VDI system, after the Virtual Machine (VM) is instantiated, a user gets access to the console through either a Remote Desktop Protocol (RDP) or a Virtual Network Computing (VNC) protocol over a secure tunnel. The VM identity (typically the Internet Protocol (IP) address and communication port number combination) keeps changing when the VM goes up and down, so do the identities of the resources on the virtual machines. It is a challenge to transfer the resource (for example a file) on these VMs to other machines in a virtual cloud in a secure manner while adhering to policies. It is also challenging to retrieve a resource that is present on the VM from an external system.
Another challenging scenario is that in a VDI system, it is too big a task for an administrator to manage the access policies for the resources on the VMs. It becomes a common requirement that the owner of the VM needs to decide which resources should be shared and which ones should not be. Think of a Windows® user sharing a file on his/her system and setting read/write permission for a particular user or group of users. In a VDI system, it is a challenge to do the same task if the user who is accessing a shared/permitted resource is from an external system (external to the VM).
In various embodiments, techniques for sharing virtual machine (VM) resources are presented. More specifically, and in an embodiment, a method for sharing a VM resource is taught. A request for creating an artifact for a resource is received; the request is received from a requestor of a VM and the resource is available form that VM. The artifact is created as a logical reference to the resource and the logical reference is dynamically resolved to a particular location for the resource within an executing instance of the VM when the artifact is subsequently provided by a requesting principal, who is external to the VM. Finally, the artifact is supplied to the requestor within the VM; the requestor subsequently shares the artifact with the requesting principal for the requesting principal to use to gain access to the resource being shared from the VM.
A “resource” includes a user, service, system, device, directory, data store, groups of users, files, 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 electronically assigned to an entity for purposes of uniquely (although not always and dependent on the context) identifying that entity. An identity is formulated from one or more identifiers, which can be public, secret, and/or trusted. The identifiers are used to verify or rely on an assigned identity. Identifiers can be verified and/or relied upon based on verifying one or more secrets and/or trust relationships. Once verified, an identity can be used for providing statements of roles and/or permissions that the identity has in relation to resources. So, an “identifier” is information, which may be private and/or trusted and which 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), assertions, tokens, user identifier and password pair, account number, retina scan, fingerprint, face scan, etc.
A “virtual machine” (VM) may be viewed as a logical processing environment overlaid or superimposed on a physical device. The VM is a logical machine that is independent of its physical process environment or physical machine. It may include its own operating system (OS), its own file system (FS), its own directory services, etc., which may each be different from the physical processing environment.
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® operating system products, directory-based products and other products 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 non-transitory computer-readable storage media and processed on the machines 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
According to an embodiment, the identity sharing facilitation service is provided from the perspective of a third-party authentication facilitation service that is implemented external to any particular instance of a VM but is accessible over a network connection to each instance of the VM's.
At 110, the identity sharing facilitation service receives a request to create an artifact for a resource. The request is received from a requestor (user or automated service) of a VM and the resource is only available within the context or environment of the VM. The artifact is a set of information this is used to identify the resource, verify access to the resource, and identify security and/or policies to enforce when access to the resource is requested. Some example information of the contents of an artifact is provided below with reference to the
According to an embodiment, at 111, the identity sharing facilitation service parses the request to acquire a unique identifier for the VM and a relative path or offset for a relative location to the resource within the context of the VM. The request is also parsed for an identifier or identity of a requesting principal (subsequent resource (user or automated service) that attempts to access the resource outside the context or environment of the VM). It may also be that the requestor provides, within the request, a role(s) that the requesting principal is associated with or even a list of available requesting principals that can access the resource.
Continuing with the embodiment of 111 and at 112, the identity sharing facilitation service also parses from the request access limitations that are to be levied by the requestor on access to the resource. The requestor can also identify whether the resource is available for caching or can be managed and acquired via a cache.
It is noted that within the context of the discussion for the
At 120, the identity sharing facilitation service creates the artifact as a logical reference to the resource. The logical reference is dynamically resolved at runtime to a particular physical location on the network for acquiring access to the resource within the VM. So, the particular location is within executing instances of the VM. It is noted that this particular location can change as the VM is terminated and re-instantiated. So, the particular location can change. The logical reference is one that at runtime resolves to the then-existing particular location for the resource.
In an embodiment, at 121, the identity sharing facilitation service assembles the artifact to include a variety of information, such as but not limited to: authentication and authorization policies for enforcement when the artifact is presented by the requesting principal; a relative location that resolves to the logical reference; a requesting principal identity for the requesting principal (the entity attempting to subsequent acquire access to the resource outside the context or environment of the VM); and a requestor identity (the sharing entity's identity).
Continuing with the embodiment of 121 and at 122, the identity sharing facilitation service also encrypts and/or digitally signs all or selective portions of the artifact. So, just the identity sharing facilitation service is capable of decrypting and verifying some parts of the artifact, such as the logical reference.
Still continuing with the embodiment of 122, the identity sharing facilitation service can also send the encrypted and/or signed artifact to a VM access layer and the VM access layer can assist in providing the logical reference and digitally signs some portions of the artifact. The VM access layer then returns its signed portion of the artifact back to the identity sharing facilitation service.
At 130, the identity sharing facilitation service supplies the artifact to the requestor within the VM. The requestor then subsequently shares the artifact with the requesting principal for the requesting principal to later use for purposes of gaining access to the resource, which is being shared from within the context or environment of an executing instance of the VM.
According to an embodiment, at 131, the identity sharing facilitation service pushes the artifact to a requestor portal that the requestor interacts with and the requestor uses to download the artifact for sharing with the requesting principal.
In another situation, at 132, the identity sharing facilitation service instructs the requestor to deliver the artifact to the requesting principal via a specific communication channel.
Continuing with one aspect or situation of the embodiment at 132, the specific communication channel is an out-of-band communication that the requestor uses to communicate the artifact to the requesting principal. The out-of-band communication can include an email communication, a web site communication where the requesting principal can download the artifact, a text message having the artifact or details on how the requesting principal can acquire the artifact, and/or an instant message having the artifact or details on how the requesting principal can acquire the artifact.
In one case, at 140, the identity sharing facilitation service subsequently receives the artifact back from the requesting principal after the requestor shares the artifact with the requesting principal. The identity sharing facilitation service then decrypts portions of the artifact to verify permissions of the requesting principal for access to the resource and to dynamically and in real time resolve the particular location of the resource within a then-existing executing instance of the VM. Next, the identity sharing facilitation service facilitates a connection between the requesting principal to the resource located at the particular location within the VM.
Continuing with the embodiment of 140 and at 141, the identity sharing facilitation service determines that the VM is not loaded and processing when the requesting principal delivers the artifact to gain access to the resource. In response to this situation, the identity sharing facilitation service instantiates or causes to be instantiated the VM and its corresponding resource (that is being shared) on a machine and then the particular location is resolved for the requesting principal to gain access to the resource. The processing at 140 and 141 assume that the requesting principal is properly authenticated and verified for access via the artifact; if such authentication fails then access to the resource is denied.
The VM access layer service represents another aspect for externally sharing a VM resource. That is, the VM access layer service is another entity that interacts with the identity sharing facilitation service, represented by the method 100 of the
At 210, the VM access layer service receives access details from an identity service for a resource that is to be shared externally from a context or environment of a VM. Here, the identity service may be viewed as the identity sharing facilitation service represented by the method 100 and discussed above with reference to the
In an embodiment, at 211, the VM access layer service is initially configured when it is started as a VM access layer that is interposed between instantiations of VMs, including the VM having the resource, and the VM access layer processes and handles all transactions directed to and from the VMs for purposes of enforcing access restrictions to the VMs and their resources. This aspect of the VM access layer service is discussed in greater detail below with reference to the
At 220, the VM access layer service creates a dynamic resource reference for the resource and a policy for managing and controlling access to the resource. The dynamic resource reference identifies a local location for the resource within the VM and the dynamic resource reference is dynamically and in real time resolved to a particular physical location for the resource when a requesting principal (entity trying to later access the resource outside the context and environment of the VM) requests shared access to the resource. So, the method 100 of the
In a particular situation, at 221, the VM access layer service digitally signs the dynamic resource reference and the policy for subsequent verification by an identity service, such as the identity sharing and facilitation service represented by the method 100 of the
In an embodiment, at 222, the VM access layer service assembles the dynamic resource reference as a pseudo access point that is represented in a Uniform Resource Locator (URL) link or a Uniform Resource Identifier (URI) link.
Continuing with the embodiment of 222 and at 223, the VM access layer service generates the URL or URI link as a relative location within the VM and that is dependent on the particular location of the VM when a requesting principal attempts to access the resource, which is being shared. Again, it is noted that the particular location is resolved at runtime when the requesting principal subsequently asks for the resource.
At 130, the VM access layer service sends the dynamic resource reference and the policy back to the identity service for subsequent delivery to a requesting principal, who is located external to the context or environment of the VM.
The VM resource sharing system 300 includes a VM 301 and a VM access manager 302. Each of these and their interactions with one another will now be discussed in turn.
The VM 301 includes a resource that is to be externally shared from the VM 301. The VM 301 is implemented in a non-transitory computer-readable storage medium and is to execute on a processor (physical machine). Example aspects associated with the VM 301 was provided in detail above with respect to the methods 100 and 200 of the
The VM 301 is configured to share the resource with external resources that process outside an environment or a context of the VM 301. The VM 301 interacts directly or indirectly with an identity service, such as the method 100 of the
According to an embodiment, the VM 301 is also configured to communicate the relative location via out-of-band communications with the external resources, such as emails, web site locations, text message, and/or instant messages.
The VM access manager 302 is implemented in a non-transitory computer-readable storage medium and executes on a different processor (different physical machine from that which is associated with the VM 301). Example processing details associated with the VM access manager 302 were presented in detail above with respect to the method 200 of the
The VM access manager 302 is configured to provide a relative location for the resource within the VM 301 to the VM 301 (directly or indirectly) for the VM 301 to share with the external resources. Again, the relative location is configured to be dynamically resolved at runtime when the external resources present the relative location.
Furthermore, the VM access manager 302 is configured to also enforce access restrictions against transactions made by the external resources for the resource within the VM 301.
According to an embodiment, the VM access manager 302 is configured to dynamically initiate or start the VM 301 on the physical machine or a different physical machine when the external resources request the resource, via the relative location. The VM access manager 302 determines that the VM 301 is not instantiated and not running when the request is made for the resource and thusly starts the VM so access to the resource can be obtained.
In another situation, the VM access manager 302 is configured to facilitate authentication of each request made by the external resources for the resource before establishing a connection between the external resources and the resource of the VM 301.
The techniques presented herein describe an identity structure (referred to as an artifact or VDI artifact) to a VDI resource so that the resource can be located independent of the VM that is hosting the resource.
The techniques presented herein also describe a mechanism by which authentication and authorization policies can be applied while accessing the VDI resource.
The techniques presented herein also describe a system for generating the VDI artifact for a particular resource, verifying the VDI artifact, and enforcing the policy while accessing the associated resource.
Referring now to the
At 1, a User1 (requestor) establishes a remote connection to a VDI cloud and accesses his/her VM using RDP. This process includes the following steps (which are not shown in the
At 2, the User1 chooses to share a resource and the VDI creator is launched.
At 3, the artifact creation request is made to the IDP. Resource details are provided in the request.
At 4, the artifact is created by the IDP (the details of the VDI artifact creation are given below with reference to the
At 5, the created VDI artifact is pushed to the user1's accessible area in the user portal.
At 6, the User1 accesses the portal from his/her physical machine (in this case from a browser) and downloads the artifact to the local machine for publishing or for distribution to the external system.
At 7, the User1 shares the artifact with User2 via an out-of-band communication, such as through e-mail.
At 8, the User2 (requesting principal) clicks on the artifact (which is a URL) and which will take the user to the IDP. The IDP dereferences (or decodes) the artifact and associates the resource to a particular VM. (Note that if the VM does not exist, a request is sent to VDI cloud for spawning an instance of the VM—this is not shown in the
At 9, if the artifact requires authentication, the User2 is forced to authenticate at the IDP. After successful authentication and artifact verification (the details of VDI Artifact verification described above and below herein), the IDP sends the details of the resource to VAP via the back channel. The details include the authorization policy.
At 10, after receiving the details of the resource, the VAP creates a pseudo access point or a dynamic resource (for example, https://vap.mycompany.com/dynamic-resources?id=ASLDw93929lj98s38n) and generates a policy for this resource. The policy encompasses the authentication and authorization requirements sent by IDP. The location of the dynamic resource is sent back to IDP.
At 11, the IDP redirects the User2 to the dynamically created resource on the VAP.
At 12, the VAP enforces the authorization policies and lets the User2 access the resource.
VDI Artifact Structure:
http//idp.mycompany.com/vdi-artifact?<VDI Artifact XML payload>
The VDI artifact is, in an embodiment, an Extensible Markup Language (XML) payload created at the IDP and has the following contents:
Artifact Data:
<Artifact Type>—This artifact can be a bearer-token type or holder-of-the-key-token type. If the artifact is not bearer-token type, then the Resource Data is encrypted by the public key of the IDP. The IDP can decrypt the Resource Data later on.
Owner Data:
<Owner Identifier>—signed by private key of the Owner IDP can verify the ownership of the artifact using the public key of the Owner.
Alternatively, Owner identifier payload contains the owner data signed by private key of the IDP. This mechanism does eliminate the need for IDP to go to the user VM to get the owner payload signed.
Receiver Data:
<Receiver Identifier>—If the artifact is not bearer-token type, <Receiver Identifier> will hold the receiver information, which is encrypted by the public key of the IDP.
<Authentication Type>—The authentication type for the receiver authentication.
<Authentication Timeout>—The period for which the receiver will remain authenticated.
Resource Data:
<VM Identifier>—Unique identifier for the machine in the VDI cloud. This unique identifier will be dereferenced to an IP address at run time (or access time).
<Resource relative location>—http://<VM>/path (or) ftp://<VM/path (or) scp VM:/path (or) SMB VM:/path, etc.
<Access permitted Time>—The time of the day at which the resource can be accessed.
<Cache Flags>—If VAP can cache the data or not.
VDI artifact is created at IDP as all the information is available there except:
the VM on which the resource resides; and
the resource details.
At 1, the User launches the VDI creator App and inputs the following:
At 2, a request is made to the IDP to create a VDI artifact. The request contains the information of the VM's unique identity on which the resource is located and is added to the above data. The IDP analyzes the request and creates the content of the artifact which includes the following:
The IDP puts all the payloads together as the required artifact and sends it back to the VDI creator App for signing. The VDI creator App signs it with the private key of the user and sends it back to IDP.
After receiving the signed artifact, the IDP pushes it to the user's portal for user to download it and share it.
Artifact Verification:
When an artifact has arrived, the IDP verifies the artifact content by validating the signature embedded it in by using the public key of the owner or by using its own public key depending on how the artifact owner data is generated. Anyone who holds the public key of the owner or IDP can verify that this artifact belongs to the owner; however, the content of the artifact can only be decrypted by the IDP as it is encrypted by using its public key.
The mechanisms and techniques presented herein provide for a variety of benefits, such as but not limited to:
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.
The Abstract is provided to comply with 37 C.F.R. §1.72(b) and will allow the reader to quickly ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.
In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.
This application is a divisional of U.S. patent application Ser. No. 12/728,115, filed on Mar. 19, 2010, now issued as U.S. Pat. No. 8,831,993, which is incorporated herein by reference in its entirety.
Number | Name | Date | Kind |
---|---|---|---|
6058395 | Buzaglo et al. | May 2000 | A |
6748470 | Goldick | Jun 2004 | B2 |
6895501 | Salowey | May 2005 | B1 |
7313605 | Iloglu et al. | Dec 2007 | B2 |
7356818 | Carollo et al. | Apr 2008 | B2 |
7389399 | Terrell et al. | Jun 2008 | B2 |
7421533 | Zimmer et al. | Sep 2008 | B2 |
7609167 | Light et al. | Oct 2009 | B1 |
7617498 | Lumsden | Nov 2009 | B1 |
7660917 | Freking et al. | Feb 2010 | B2 |
7730030 | Xu | Jun 2010 | B1 |
7865724 | Alvarado et al. | Jan 2011 | B2 |
7904608 | Price | Mar 2011 | B2 |
7975270 | Ferri et al. | Jul 2011 | B2 |
8024407 | Harwood et al. | Sep 2011 | B2 |
8102781 | Smith | Jan 2012 | B2 |
8335902 | Feathergill | Dec 2012 | B1 |
8533724 | Theimer et al. | Sep 2013 | B1 |
8656018 | Keagy et al. | Feb 2014 | B1 |
8831993 | Burch et al. | Sep 2014 | B2 |
20020032634 | Abrams et al. | Mar 2002 | A1 |
20020143897 | Patil | Oct 2002 | A1 |
20040039926 | Lambert | Feb 2004 | A1 |
20040097267 | Pecen et al. | May 2004 | A1 |
20060212937 | Natarajan | Sep 2006 | A1 |
20070006230 | Neiger | Jan 2007 | A1 |
20070028238 | Bennett | Feb 2007 | A1 |
20070106769 | Liu | May 2007 | A1 |
20070136579 | Levy et al. | Jun 2007 | A1 |
20070245348 | Araujo | Oct 2007 | A1 |
20070283359 | Demsey et al. | Dec 2007 | A1 |
20070294676 | Mellor et al. | Dec 2007 | A1 |
20080070557 | Paila et al. | Mar 2008 | A1 |
20080077765 | Illikkal | Mar 2008 | A1 |
20080104079 | Craig | May 2008 | A1 |
20080114860 | Keys et al. | May 2008 | A1 |
20080134177 | Fitzgerald | Jun 2008 | A1 |
20080163254 | Cota-Robles | Jul 2008 | A1 |
20080168184 | Freedman | Jul 2008 | A1 |
20080222638 | Beaty | Sep 2008 | A1 |
20080244576 | Kwon et al. | Oct 2008 | A1 |
20080244579 | Muller | Oct 2008 | A1 |
20080244595 | Eilam et al. | Oct 2008 | A1 |
20090019509 | Horn et al. | Jan 2009 | A1 |
20090089527 | Schoenberg | Apr 2009 | A1 |
20090106347 | Harwood et al. | Apr 2009 | A1 |
20090216828 | Gebhart | Aug 2009 | A1 |
20090276784 | Grieve et al. | Nov 2009 | A1 |
20090282472 | Hamilton, II et al. | Nov 2009 | A1 |
20090327471 | Astete | Dec 2009 | A1 |
20100027552 | Hill | Feb 2010 | A1 |
20100037307 | Sandland et al. | Feb 2010 | A1 |
20100058334 | Mohindra et al. | Mar 2010 | A1 |
20100083148 | Finn et al. | Apr 2010 | A1 |
20100125798 | Brookhart | May 2010 | A1 |
20100169884 | Bogin | Jul 2010 | A1 |
20100241763 | Chan | Sep 2010 | A1 |
20100325284 | Heim | Dec 2010 | A1 |
20110010325 | Brillhart et al. | Jan 2011 | A1 |
20110128281 | Bhogal et al. | Jun 2011 | A1 |
20110131509 | Brillhart et al. | Jun 2011 | A1 |
20110231840 | Burch et al. | Sep 2011 | A1 |
20110314462 | Clark | Dec 2011 | A1 |
Entry |
---|
“Initializing and Managing a Virtual Machine”, Sandia National Laboratories, all pages, [Online]. Retrieved from the internet: <http://www.cs.sandia.gov/cplant/doc/runtimeAdmin1—0/node4.html>, (Jun. 25, 2001). |
“Microsoft Computer Dictionary”, 5th Edition, Microsoft Press, Redmond, WA, (2002), p. 484. |
“The Elements of Style”, 3rd Edition, Macmillan Publishing Co., Inc., New York, N.Y, (1979), p. 40. |
Number | Date | Country | |
---|---|---|---|
20140366096 A1 | Dec 2014 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 12728115 | Mar 2010 | US |
Child | 14468927 | US |