Method and apparatus for token-based container chaining

• US 8,566,918 B2
• Filed: 08/15/2011
• Issued: 10/22/2013
• Est. Priority Date: 08/15/2011
• Status: Active Grant

• Current Assignee: Bank of America Corp.
• Original Assignee: Bank of America Corp.
• Inventors: Radhakrishnan, Rakesh
• Primary Examiner(s): Colin, Carl
• Assistant Examiner(s): ZHAO, DON GORDON
• Application Number:
  US13/209,935
• Publication Number:
  US 20130047240A1
• Time in Patent Office: 799 Days
• Field of Search: 726 1- 36, 713150-194
• US Class Current: 726/9
• CPC Class Codes: G06F 21/335 for accessing specific resources, e.g. using Kerberos tickets
• CPC Class Codes: G06F 21/577 Assessing vulnerabilities and evaluating computer system security
• CPC Class Codes: G06F 2221/2115 Third party
• CPC Class Codes: H04L 63/0807 using tickets, e.g. Kerberos cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213
• CPC Class Codes: H04L 63/083 using passwords cryptographic mechanisms or cryptographic arrangements for entity authentication using a predetermined code H04L9/3226
• CPC Class Codes: H04L 63/105 Multiple levels of security
• CPC Class Codes: H04L 9/088 Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms network architectures or network communication protocols for using time-dependent keys in a packet data network H04L63/068
• CPC Class Codes: H04L 9/3213 using tickets or tokens, e.g. Kerberos network architectures or network communication protocols for entities authentication using tickets in a packet data network H04L63/0807
• CPC Class Codes: H04L 9/3234 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token network architectures or network communication protocols for supporting authentication of entities using an additional device in a packet data network H04L63/0853

Abstract

According to one embodiment, an apparatus may intercept a request to access a resource represented by a resource token. The apparatus may receive a hard token representing identification information of a device. The apparatus may determine, based at least in part upon the hard token and the resource token, at least one token-based rule specifying compliance criteria required to consume the resource. The apparatus may receive at least one token representing compliance information of the device in response to a request for compliance information of the device. The apparatus may then compare the compliance information against the compliance criteria to determine that the device is capable of consuming the resource. The apparatus may then generate a compliance token representing the determination that the device is capable of consuming the resource, and communicate the compliance token to facilitate the provisioning of a container to the device.

Claims

1. An apparatus for container provisioning in a token-based environment, comprising a processor that executes instructions to:

intercept a request from a device to access a resource, the resource represented by a resource token;

receive a hard token from a token provider in response to a request for identification information of the device, the hard token representing the identification information of the device;

determine at least one token-based rule based at least in part upon the hard token and the resource token, the at least one token-based rule specifying compliance criteria required to consume the resource;

receive at least one token from the token provider in response to a request for compliance information of the device, the at least one token representing the compliance information of the device, wherein the compliance information indicates capabilities of the device to consume the resource;

compare the compliance information against the compliance criteria to determine that the device is capable of consuming the resource;

generate a compliance token representing the determination that the device is capable of consuming the resource;

communicate the compliance token to facilitate the provisioning of a container to the device, the container facilitating access to the resource, wherein the container includes a virtual machine executable by the device;

correlate the hard token and the compliance token to a session token representing a session in response to the determination that the device is capable of consuming the resource, the session facilitating access by the device to the resource;

determine whether at least one of a hardware update and a firmware update associated with the device occurs during the session; and

communicate a response to the device indicating that access should be denied, wherein the response is based on an impact of at least one of the hardware update and the firmware update.

2. The apparatus of claim 1, the processor further operable to:

determine whether an application change occurs during the session;

communicate a response to the device, wherein the response is based on the impact of the application change.

3. The apparatus of claim 1, the processor further operable to release the container if the session terminates.

4. The apparatus of claim 1, wherein the hard token represents identification information from layer 2 of the Open Systems Interconnection stack.

5. The apparatus of claim 1, wherein the compliance information of the device comprises at least one of firmware version, operating system version, and hardware specifications of the device.

6. A method for container provisioning in a token-based environment, comprising:

intercepting, by a processor, a request from a device to access a resource, the resource represented by a resource token;

receiving, by the processor, a hard token from a token provider in response to a request for identification information of the device, the hard token representing the identification information of the device;

determining, by the processor, at least one token-based rule based at least in part upon the hard token and the resource token, the at least one token-based rule specifying compliance criteria required to consume the resource;

receiving, by the processor, at least one token from the token provider in response to a request for compliance information of the device, the at least one token representing the compliance information of the device, wherein the compliance information indicates capabilities of the device to consume the resource;

comparing, by the processor, the compliance information against the compliance criteria to determine that the device is capable of consuming the resource;

generating, by the processor, a compliance token representing the determination that the device is capable of consuming the resource;

communicating, by the processor, the compliance token to facilitate the provisioning of a container to the device, the container facilitating access to the resource, wherein the container includes a virtual machine executable by the device;

correlating, by the processor, the hard token and the compliance token to a session token representing a session in response to the determination that the device is capable of consuming the resource, the session facilitating access by the device to the resource;

determining, by the processor, whether at least one of a hardware update and a firmware update associated with the device occurs during the session; and

communicating, by the processor, a response to the device that access should be denied, wherein the response is based on an impact of at least one of the hardware update and the firmware update.

7. The method of claim 6, further comprising:

determining, by the processor, whether an application change occurs during the session;

communicating a response to the device, wherein the response is based on the impact of the application change.

8. The method of claim 6, further comprising releasing the container if the session terminates.

9. The method of claim 6, wherein the hard token represents identification information from layer 2 of the Open Systems Interconnection stack.

10. The method of claim 6, wherein the compliance information of the device comprises at least one of firmware version, operating system version, and hardware specifications of the device.

11. One or more computer-readable non-transitory storage media embodying software that is operable when executed to:

intercept, by a processor, a request from a device to access a resource, the resource represented by a resource token;

receive, by the processor, a hard token from a token provider in response to a request for identification information of the device, the hard token representing the identification information of the device;

determine, by the processor, at least one token-based rule based at least in part upon the hard token and the resource token, the at least one token-based rule specifying compliance criteria required to consume the resource;

receive, by the processor, at least one token from the token provider in response to a request for compliance information of the device, the at least one token representing the compliance information of the device, wherein the compliance information indicates capabilities of the device to consume the resource;

compare, by the processor, the compliance information against the compliance criteria to determine that the device is capable of consuming the resource;

generate, by the processor, a compliance token representing the determination that the device is capable of consuming the resource;

communicate, by the processor, the compliance token to facilitate the provisioning of a container to the device, the container facilitating access to the resource, wherein the container includes a virtual machine executable by the device;

correlate, by the processor, the hard token and the compliance token to a session token representing a session in response to the determination that the device is capable of consuming the resource, the session facilitating access by the device to the resource;

determine, by the processor, whether at least one of a hardware update and a firmware update associated with the device occurs during the session; and

communicate, by the processor, a response to the device indicating that access should be denied, wherein the response is based on the impact of at least one of the hardware update and the firmware update.

12. The media of claim 11 embodying software further operable when executed to:

determine whether an application change occurs during the session;

communicate a response to the device, wherein the response is based on the impact of the application change.

13. The media of claim 11 embodying software further operable when executed to release the container if the session terminates.

14. The media of claim 11, wherein the hard token represents identification information from layer 2 of the Open Systems Interconnection stack.

15. The media of claim 11, wherein the compliance information of the device comprises at least one of firmware version, operating system version, and hardware specifications of the device.