Controlling exposure of sensitive data and operation using process bound security tokens in cloud computing environment

• US 9,531,538 B2
• Filed: 12/11/2015
• Issued: 12/27/2016
• Est. Priority Date: 01/21/2013
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Chang, John Y-C., CHao, Ching-Yun, Chiu, Bertrand Be-Chung, Park, Ki Hong
• Primary Examiner(s): TURCHEN, JAMES R
• Application Number:
  US14/966,114
• Publication Number:
  US 20160099808A1
• Time in Patent Office: 382 Days
• US Class Current: 1/1
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/0815 providing single-sign-on or federations
• CPC Class Codes: H04L 63/0823 using certificates cryptographic mechanisms or cryptographic arrangements for entity authentication involving certificates H04L9/3263
• CPC Class Codes: H04L 65/61 for supporting one-way streaming services, e.g. Internet radio
• CPC Class Codes: H04L 67/01 Protocols
• 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/3247 involving digital signatures

Abstract

Exposure of sensitive information to users is controlled using a first security token containing user identity and user credentials to represent the user who requests services, and a second security token containing two other identities, one identifying the token issuer and the other identifying the owning process. When requesting services, the token-owning process sends a security token to indicate who is making the request, and uses its key to digitally sign the request. The token-owning process signs the request to indicate that it endorses the request. A receiving server accepts a request if (1) the token-owning process endorses the request by signing the request; (2) the token is valid (token is signed by its issuer and the digital signature is verified and unexpired); (3) user entity, which can be a real user or a deployment or a server process, that is represented by the token has the authorization to access the specified resources; and (4) the token-owning process is authorized to endorse the user entity represented by the token to access the specified resources.

Claims

1. A method for controlling exposure of sensitive data using process-bound security tokens comprising:

receiving by an owning process from a requester a set of user authentication credentials to create a request message to access or communicate to a targeted server, wherein the owning process and the requester are separate computing entities;

creating and signing with a first token issuer cryptographic key a first security token that is owned by the owning process;

sending by the owning process to a downstream server the first security token and the request message;

endorsing the request message by the downstream server by attaching a second security token representing the downstream server, wherein the second security token is signed by a second token issuer cryptographic key;

sending by the downstream server the endorsed request message to the targeted server;

responsive to one or more security verifications of the endorsed request message, issuing by the targeted server a user token;

returning the user token to the owning process;

storing and associating by the owning process the user token with a single sign-on token, wherein the single sign-on token is separate from the user token;

sending by the owning process the associated single sign-on token to the requester identified by the user authentication credentials;

thereby preventing exposure of the user token to the requester.

2. The method as set forth in claim 1 wherein the source of the request comprises a user device.

3. The method as set forth in claim 1 wherein the source of the request comprises a user process.

4. The method as set forth in claim 3 wherein the second security token comprises an identification of the token issuer, and comprises an identification of the owning process.

5. The method as set forth in claim 1 further comprising:

subsequent to the sending of the single sign-on cookie to the source of the request, receiving a second request by the inlet server for access to or communication with the target server, wherein the second request has the single sign-on attached;

looking up by the server process the user token associated with the attached single sign-on cookie; and

forwarding the second request with the user token to the key server.

6. The method as set forth in claim 5 wherein further comprising:

endorsing the second request by attaching the second security token signed by the second cryptographic key;

sending the endorsed second request to the targeted server.

7. The method as set forth in claim 6 further comprising:

responsive to one or more security verifications of the endorsed second request, performing by the targeted server a requested access, usage of a resource, or performance of a service according to the second request.

8. The method as set forth in claim 7 further comprising:

responsive to results generation by the access, usage, or service performance, returning the results to the server process with the user token attached;

detaching by the server process the user token from the results;

forwarding to the source of the second request the results and the single sign-on cookie.

9. A computer program product for controlling exposure of sensitive data using process-bound security tokens comprising:

a computer-readable storage memory which is not a propagating signal per se;

program instructions embodied by the computer-readable storage memory which cause a processor to, when executed, perform the steps of;

receiving by an owning process from a requester a set of user authentication credentials to create a request message to access or communicate to a targeted server, wherein the owning process and the requester are separate computing entities;

creating and signing with a first token issuer cryptographic key a first security token that is owned by the owning process;

sending by the owning process to a downstream server the first security token and the request message;

endorsing the request message by the downstream server by attaching a second security token representing the downstream server, wherein the second security token is signed by a second token issuer cryptographic key;

sending by the downstream server the endorsed request message to the targeted server;

responsive to one or more security verifications of the endorsed request message, issuing by the targeted server a user token;

returning the user token to the owning process;

storing and associating by the owning process the user token with a single sign-on token, wherein the single sign-on token is separate from the user token;

sending by the owning process the associated single sign-on token to the requester identified by the user authentication credentials;

thereby preventing exposure of the user token to the requester.

10. The computer program product as set forth in claim 9 wherein the source of the request comprises a user device.

11. The computer program product as set forth in claim 9 wherein the source of the request comprises a user process.

12. The computer program product as set forth in claim 11 wherein the second security token comprises an identification of the token issuer, and comprises an identification of the owning process.

13. A system for controlling exposure of sensitive data using process-bound security tokens comprising:

a computing system having a processor;

a computer-readable storage memory which is not a propagating signal per se;

program instructions embodied by the computer-readable storage memory which cause the processor to, when executed, perform the steps of;

receiving by an owning process from a requester a set of user authentication credentials to create a request message to access or communicate to a targeted server, wherein the owning process and the requester are separate computing entities;

creating and signing with a first token issuer cryptographic key a first security token that is owned by the owning process;

sending by the owning process to a downstream server the first security token and the request message;

endorsing the request message by the downstream server by attaching a second security token representing the downstream server, wherein the second security token is signed by a second token issuer cryptographic key;

sending by the downstream server the endorsed request message to the targeted server;

responsive to one or more security verifications of the endorsed request message, issuing by the targeted server a user token;

returning the user token to the owning process;

storing and associating by the owning process the user token with a single sign-on token, wherein the single sign-on token is separate from the user token;

sending by the owning process the associated single sign-on token to the requester identified by the user authentication credentials;

thereby preventing exposure of the user token to the requester.

14. The system as set forth in claim 13 wherein the source of the request comprises a user device.

15. The system as set forth in claim 13 wherein the source of the request comprises a user process.

16. The system as set forth in claim 15 wherein the second security token comprises an identification of the token issuer, and comprises an identification of the owning process.