IP Library Granted Patent US 10,841,103
Granted Patent B2
US 10,841,103 · App. 15/923,197 · Granted Nov 17, 2020

Relying party certificate validation when client uses relying party's IP address

Inventors: Chandan R. Reddy (Redmond, WA); Kahren Tevosyan (Kirkland, WA); Hieu Trung Nguyen (Seattle, WA)
H04L9/3265H04L9/3213H04L9/3226H04L9/3268H04L61/1511H04L63/0823
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 10,841,103
App. No.
15/923,197
Granted
Nov 17, 2020
Kind
B2
Abstract

Aspects of the technology described herein enable a client device to access a web service in a claims-based identity environment thorough an Internet Protocol (IP) address, rather than the web service's domain name service (DNS). In a claims-based identity environment, a client device will authenticate a relying party's server SSL certificate before providing the token to the relying party by following an authentication process. Current authentication processes include a name-chaining operation, which compares a subject field of a token provided with the Uniform Resource Identifier (URI) used to request the resource (e.g., RP application). When the IP address is used as the URI, then the URI in the certificate will not match the URI in the request and the authentication will fail. Accordingly, aspects of the technology use an alternative authentication method that allows access to a web service through an IP address, when the default client-side token validation is DNS-name based.

Claims (49)

1. A method for authenticating a user, the method comprising:

sending, from a client application, an access request to a Uniform Resource Identifier (URI) of a relying party, wherein URI is an Internet Protocol (IP) address of the relying party, and wherein a default URI for the relying party is a domain name service (DNS) name;

receiving, at the client application, a response from the relying party that includes authentication metadata that includes an address for a security token service (STS) trusted by the relying party;

sending, from the client application, a request for a security token to access the relying party to the STS;

receiving, at the client application, the security token to access the relying party from the STS, wherein the security token comprises a certificate for the relying party;

validating the certificate using Public Key Infrastructure (PKI) chain validation through a secondary authentication process, wherein a step in the secondary authentication process comprises comparing a DNS name from an audience Uniform Resource Identifier (URI) field in the security token with a subject field or subject alternative name (SAN) field in the certificate for the relying party; and

upon successful validation of the security token, communicating, from the client application, the security token to the relying party.

2. The method of claim 1 , wherein the certificate is a Secure Sockets Layer (SSL) certificate.

3. The method of claim 1 , wherein the authentication metadata also includes a security realm of the relying party.

4. The method of claim 1 , wherein the security token comprises a claim for the user of the client application.

5. The method of claim 1 , wherein the client application is a web browser.

6. The method of claim 1 , wherein the method further comprises:

determining that the request is addressed to an Internet Protocol (IP) address of the relying party rather than a domain name service (DNS) name; and

in response to said determining, using the secondary authentication process rather than a primary authentication process that compares the subject field or the SAN of the certificate for the relying party with the URI of the relying party used in the request.

7. The method of claim 1 , wherein the method further comprises:

determining that the URI of the relying party does not match the subject field or SAN in the certificate for the relying party;

determining that the request is addressed to an Internet Protocol (IP) address rather than a DNS name; and

using the secondary authentication process rather than a primary authentication process that compares the subject field of the certificate for the relying party with the URI of the relying party used in the request.

8. One or more computer storage media storing computer-useable instructions that, when used by one or more computing devices, cause the one or more computing devices to perform operations comprising:

sending, from a client application, an access request to a Uniform Resource Identifier (URI) of a relying party, wherein URI is an Internet Protocol (IP) address of the relying party, and wherein a default URI for the relying party is a domain name service (DNS) name;

receiving, at the client application, a response from the relying party that includes authentication metadata that includes an address for a security token service (STS) trusted by the relying party;

sending, from the client application, a request for a security token to access the relying party to the STS;

receiving, at the client application, the security token to access the relying party from the STS, wherein the security token comprises a certificate for the relying party;

validating the security token using Public Key Infrastructure (PKI) chain validation through an authentication process, wherein a step in the authentication process comprises comparing a DNS name from an audience Uniform Resource Identifier (URI) field in the security token with a subject field or subject alternative name (SAN) in the certificate for the relying party; and

upon successful validation of the security token, communicating, from the client application, the security token to the relying party.

9. The media of claim 8 , wherein the authentication process does not include a step of comparing the Internet Protocol (IP) address of the relying party to the subject field in the certificate for the relying party.

10. The media of claim 8 , wherein the method further comprises:

determining that the URI of the relying party does not match the subject field in the certificate for the relying party;

determining that the request is addressed to an Internet protocol (IP) address rather than a DNS name; and

using the authentication process rather than a default authentication process that requires the URI of the relying party to match the subject field or the SAN in the certificate for the relying party.

11. The media of claim 8 , wherein the relying party provides a web service.

12. The media of claim 8 , wherein the authentication metadata also includes a security realm of the relying party.

13. The media of claim 8 , wherein the certificate is a Secure Sockets Layer (SSL) certificate.

14. The media of claim 8 , wherein the security token comprises a claim for a user of the client application.

15. A method for authenticating a user, the method comprising:

sending, from a client application, an access request to a Uniform Resource Identifier (URI) of a relying party, wherein URI is an Internet Protocol (IP) address of the relying party, and wherein a default URI for the relying party is a domain name service (DNS) name;

receiving, at the client application, a response from the relying party that includes authentication metadata that includes an address for a security token service (STS) trusted by the relying party and a security realm of the relying party;

sending, from the client application, a request for a security token to access the relying party to the STS;

receiving, at the client application, the security token from the STS and a public certificate for the relying party, wherein the security token comprises a SSL certificate for the relying party;

validating the SSL certificate through an authentication process that comprises comparing the SSL certificate for the relying party and the public certificate for the relying party; and

upon successful validation of the security token, communicating, from the client application, the security token to the relying party.

16. The method of claim 15 , wherein the validation comprises determining that one or more designated fields in the SSL certificate for the relying party match one or more designated fields in the public certificate for the relying party.

17. The method of claim 16 , wherein a designated field is a certificate signature.

18. The method of claim 15 , wherein the authentication process does not include a step of comparing the Internet Protocol (IP) address of the relying party to the subject field in the SSL certificate for the relying party.

19. The method of claim 15 , wherein the method further comprises:

determining that the URI of the relying party does not match the subject field in the SSL certificate for the relying party;

determining that the request is addressed to an Internet Protocol (IP) address rather than a DNS name; and

using the authentication process rather than a default authentication process that requires the URI of the relying party to match the subject field or subject alternative name (SAN) in the certificate for the relying party.

20. The method of claim 15 , wherein the security token comprises a claim for the user of the client application.

Assignments (4)
CORRECTIVE ASSIGNMENT TO CORRECT THE CONVEYING PARTY PREVIOUSLY RECORDED AT REEL: 045959 FRAME: 0673. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Recorded Jan 15, 2019
From: NGUYEN, HIEU TRUNG
To: MICROSOFT TECHNOLOGY LICENSING, LLC
Reel/Frame 048076/0709 →
CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNOR NAME PREVIOUSLY RECORDED AT REEL: 045959 FRAME: 0673. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Recorded Jan 15, 2019
From: NGUYEN, HIEU TRUNG
To: MICROSOFT TECHNOLOGY LICENSING, LLC
Reel/Frame 048076/0738 →
CORRECTIVE ASSIGNMENT TO CORRECT THE CHANGE FROM WILL BE FILED TO FILED ON MARCH 16, 2016 AND GIVEN APPLICATION NO. 15/923,197. PREVIOUSLY RECORDED ON REEL 045959 FRAME 0673. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Recorded Jan 15, 2019
From: REDDY, CHANDAN R.
To: MICROSOFT TECHNOLOGY LICENSING, LLC
Reel/Frame 049191/0597 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jun 1, 2018
From: TEVOSYAN, KAHREN; REDDY, CHANDAN R.; HGUYEN, HIEU TRUNG
To: MICROSOFT TECHNOLOGY LICENSING, LLC
Reel/Frame 045959/0673 →
Continuity (1)
Related Publication 20190288859A1 · Sep 19, 2019