Cardspace history validator

• US 8,079,069 B2
• Filed: 03/24/2008
• Issued: 12/13/2011
• Est. Priority Date: 03/24/2008
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Burch, Lloyd Leon, Vedula, Srinivas
• Primary Examiner(s): Smithers, Matthew
• Application Number:
  US12/054,137
• Publication Number:
  US 20090241178A1
• Time in Patent Office: 1,359 Days
• Field of Search: 713/173
• US Class Current: 726/9
• CPC Class Codes: G06F 21/6218 to a system of files or objects, e.g. local or distributed file system or database

Abstract

Before a relying party grants a client access to a resource, the last use of the security token by the client to access the resource of the relying party can be verified. Verification can be accomplished by comparing the last time the client sent the security token to the relying party with the last time the relying party received the security token from the client. If the last use of the security token is not verified, the possibility exists that the security token has been fraudulently used by a third party.

Claims

1. An apparatus (105), comprising:

a receiver (210) to receive a security policy (150) from a relying party (130);

a card selector (205) to select an information card (220) responsive to said security policy (150);

a data store (225) to store a last time (230) the apparatus (105) sent a security token (160) responsive to said selected information card (220) to said relying party (130); and

a transmitter (215) to transmit to said relying party (130) said security token (160), wherein said relying party (130) grants access to a resource (315) if a last transmission of the security token (160) to the relying party (130) was verified.

2. An apparatus (105) according to claim 1, wherein:

the receiver (210) is operative to receive said security policy (150) from said relying party (130), said security policy (150) including a request (405) for a last time (230) the apparatus (105) sent said security token (160) to said relying party (130); and

the apparatus (105) further comprises an adder (240) to add to said security token (160) said last time (230, 505) said apparatus (105) sent said security token (160) to said relying party (130).

3. An apparatus (105) according to claim 2, wherein the adder (240) is operative to add said last time (230, 505) said apparatus (105) sent said security token (160) to said relying party (130) to said security token (160) before said security token (160) is transmitted from the apparatus (105) to said relying party (130).

4. An apparatus (105) according to claim 1, further comprising a data store updater (235) to store a current time that said security token (160) was transmitted from the apparatus (105) to said relying party (130).

5. An apparatus (130), comprising:

a transmitter (310) to transmit a security policy (150) to a client (105) responsive to a request from said client (105) for access a resource (315);

a receiver (305) to receive said request from said client (105) for said resource (315) and to receive a security token (160) from said client (105) responsive to said security policy (150); and

a data store (325) to store a current time that said security token (160) was received by the apparatus (130) from said client (105),

wherein the apparatus (130) is operative to grant said client (105) access to said resource (315) if a last transmission of the security token (160) to the apparatus (130) was verified.

6. An apparatus (130) according to claim 5, wherein:

the transmitter (310) is operative to transmit said security policy (150) to said client (105) responsive to said request from said client (105) for access to said resource (315), said security policy (150) including a request (405) for a last time (230) said client (105) sent said security token (160) to the apparatus (130);

the receiver (305) is operative to receive said security token (160) from said client (105) responsive to said security policy (150), said security token (160) including said last time (230, 505) said client (105) sent said security token (160) to the apparatus (130); and

the apparatus (130) further comprises an access granter (320) to grant access to said resource (315) if a last time (330) the apparatus (130) received said security token (160) corresponds to said last time (230, 505) said client (105) sent said security token (160) to the apparatus (130).

7. An apparatus (130) according to claim 6, further comprising a signature verifier (355) to verify a digital signature (510) applied to said security token (160) by said client (105).

8. An apparatus (130) according to claim 5, further comprising a policy store (335) to store a policy (340, 345, 350) to apply if said last transmission of said security token (160) to the apparatus (130) was not verified.

25. An apparatus (130) according to claim 5, further comprising a data store updater to store a current time that said security token (160) was received by the apparatus (105) from said client (105).

9. A method to verify use of an information card (220), comprising:

requesting (705) access to a resource (315) from a relying party (130);

receiving (710) at a client (105) a security policy (150) from the relying party (130);

identifying (720) an information card (220) that satisfies the security policy (130);

transmitting (765) a security token (160) from the client (105) to the relying party (130); and

accessing (785) the resource (315) from the relying party (130) if a last transmission of the security token (160) to the relying party (130) was verified.

10. A method according to claim 9, wherein:

receiving (710) at a client (105) a security policy (150) from the relying party (130) includes receiving (715) at the client (105) the security policy (150) from the relying party (130), the security (150) policy including a request (405) for a last time (230) the client (105) sent the security token (160) to the relying party (130); and

the method further comprises adding (750) to the security token (160) the last time (230, 505) the client (105) sent the security token (160) to the relying party (130).

11. A method according to claim 10, wherein adding (750) to the security token (160) the last time the client (105) sent the security token (160) to the relying party (130) includes adding (750) to the security token (160) the last time (230, 505) the client (105) sent the security token (160) to the relying party (130) before transmitting the security token (160) from the client (105) to the relying party (130).

12. A method according to claim 9, further comprising storing (790) a current time that the security token (160) was transmitted from the client (105) to the relying party (130).

13. A method to verify use of an information card (220), comprising:

receiving (1105) a request from a client (105) to access a resource (315) at a relying party (130);

transmitting (1115) a security policy (150) to the client (105);

receiving (1125) a security token (160) from the client (105); and

granting (1135) access to the resource (315) by the relying party (130) if a last reception of the security token (160) from the client (105) was verified.

14. A method according to claim 13, wherein:

transmitting (1115) a security policy (150) to the client (105) includes transmitting (1115, 815) the security policy (150) to the client (105), the security policy including a request (405) for a last time (230) the client (105) sent the security token (160) to the relying party (130);

receiving (1125) a security token (160) from the client (105) includes receiving (1125) the security token (160) from the client (105), the security token (160) including the last time (230, 505) the client (105) sent the security token (160) to the relying party (130); and

granting (1135) access to the resource (315) by the relying party (130) includes verifying (1155, 845) that a last time (330) the relying party (130) received the security token (160) corresponds the last time (230, 505) the client (105) sent the security token (160) to the relying party (130).

15. A method according to claim 13, further comprising applying (865) a policy (340, 345, 350) if the last transmission of the security token (160) to the relying party (130) was not verified.

16. A method according to claim 13, further comprising storing (1140) a current time that the security token (160) was received from the client (105) by the relying party (130).

26. A method according to claim 14, further comprising verifying (825) a digital signature (510) applied to the security token (160) by the client (105).

17. An article, comprising a storage medium, said storage medium having stored thereon instructions that, when executed by a machine, result in:

requesting (705) access to a resource (315) from a relying party (130);

receiving (710) at a client (105) a security policy (150) from the relying party (130);

identifying (720) an information card (220) that satisfies the security policy (130);

transmitting (765) a security token (160) from the client (105) to the relying party (130); and

accessing (785) the resource (315) from the relying party (130) if a last transmission of the security token (160) to the relying party (130) was verified.

18. An article according to claim 17, wherein:

receiving (710) at a client (105) a security policy (150) from the relying party (130) includes receiving (715) at the client (105) the security policy (150) from the relying party (130), the security (150) policy including a request (405) for a last time (230) the client (105) sent the security token (160) to the relying party (130); and

said storage medium has stored thereon further instructions that, when executed by the machine, result in adding (750) to the security token (160) the last time (230, 505) the client (105) sent the security token (160) to the relying party (130).

19. An article according to claim 18, wherein adding (750) to the security token (160) the last time the client (105) sent the security token (160) to the relying party (130) includes adding (750) to the security token (160) the last time (230, 505) the client (105) sent the security token (160) to the relying party (130) before transmitting the security token (160) from the client (105) to the relying party (130).

24. An article according to claim 17, wherein said storage medium has stored thereon further instructions that, when executed by the machine, result in storing (790) a current time that the security token (160) was transmitted from the client (105) to the relying party (130).

20. An article, comprising a storage medium, said storage medium having stored thereon instructions that, when executed by a machine, result in:

receiving (1105) a request from a client (105) to access a resource (315) at a relying party (130);

transmitting (1115) a security policy (150) to the client (105);

receiving (1125) a security token (160) from the client (105); and

granting (1135) access to the resource (315) by the relying party (130) if a last reception of the security token (160) from the client (105) was verified.

21. An article according to claim 20, wherein:

transmitting (1115) a security policy (150) to the client (105) includes transmitting (1115, 815) the security policy (150) to the client (105), the security policy including a request (405) for a last time (230) the client (105) sent the security token (160) to the relying party (130);

receiving (1125) a security token (160) from the client (105) includes receiving (1125) the security token (160) from the client (105), the security token (160) including the last time (230, 505) the client (105) sent the security token (160) to the relying party (130); and

granting (1135) access to the resource (315) by the relying party (130) includes verifying (1155, 845) that a last time (330) the relying party (130) received the security token (160) corresponds the last time (230, 505) the client (105) sent the security token (160) to the relying party (130).

22. An article according to claim 20, wherein said storage medium has stored thereon further instructions that, when executed by the machine, result in applying (865) a policy (340, 345, 350) if the last transmission of the security token (160) to the relying party (130) was not verified.

23. An article according to claim 20, wherein said storage medium has stored thereon further instructions that, when executed by the machine, result in storing (1140) a current time that the security token (160) was received from the client (105) by the relying party (130).

27. An article according to claim 21, further comprising verifying (825) a digital signature (510) applied to the security token (160) by the client (105).