RE: [EXTERNAL] Re: Patch to add support to the OpenConnect client to send RFC6750 style bearer tokens during establishment of the TLS tunnel.

Mon, 27 Jan 2020 09:40:27 -0800 

The RFC6750 does define 3 options for encoding the bearer token in the HTTP 
request:
https://tools.ietf.org/html/rfc6750

2.1.  Authorization Request Header Field
Example:
     GET /resource HTTP/1.1
     Host: server.example.com
     Authorization: Bearer mF_9.B5f-4.1JqM

2.2.  Form-Encoded Body Parameter
Example:
     POST /resource HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     access_token=mF_9.B5f-4.1JqM

2.3.  URI Query Parameter
Example:
     GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
     Host: server.example.com

Given that the OIDC token (encoded as a JWT) can be large, especially if the 
group claim is added, I thought the best option would be 2.1 as some HTTP 
servers have issues with very long URI's.

None of these options seem to patch what GlobalProtect is doing though. 

Regards,
Alan Jowett

-----Original Message-----
From: Daniel Lenski <[email protected]> 
Sent: Sunday, January 26, 2020 11:38 PM
To: David Woodhouse <[email protected]>
Cc: Alan Jowett <[email protected]>; 
[email protected]
Subject: [EXTERNAL] Re: Patch to add support to the OpenConnect client to send 
RFC6750 style bearer tokens during establishment of the TLS tunnel.

On Wed, 2020-01-22 at 20:05 +0000, Alan Jowett wrote:
> OpenConnect folks,
>
> Patch to add support to the OpenConnect client to send RFC6750 style bearer 
> tokens during establishment of the TLS tunnel.
>
> Background:
> My team is working on a feature to support using OpenID Connect tokens 
> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fope
> nid.net%2Fspecs%2Fopenid-connect-core-1_0.html&amp;data=02%7C01%7CAlan
> .Jowett%40microsoft.com%7Cc2723a399d0744cbef1f08d7a2f39054%7C72f988bf8
> 6f141af91ab2d7cd011db47%7C1%7C0%7C637157039293873057&amp;sdata=uB5EMEnIrkZ%2BTYzpqA4H0Y%2B4y7grtpEpOF9QZvaocQs%3D&amp;reserved=0)
>  to authenticate and authorize clients connecting to an OpenConnect server. 
> There are growing list of OpenID Connect providers that this should work 
> with, making this change fairly broadly applicable.

Looks like Alan added an issue here:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fopenconnect%2Fopenconnect%2Fissues%2F99&amp;data=02%7C01%7CAlan.Jowett%40microsoft.com%7Cc2723a399d0744cbef1f08d7a2f39054%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637157039293873057&amp;sdata=p%2FdLROYhz9B9lZt3uGqNgzSsGZ2uTV8KczHqXxqdtyE%3D&amp;reserved=0

I'll point out that this is in some ways similar to the "alternative secret" 
junk that I have to do for GlobalProtect+SAML to work. What the two have in 
common is that authentication uses some alternative cookie field instead of the 
usual password field — and this field can't be autodetected from the "normal" 
authentication forms sent by the server.

If I've got that right, then hopefully we can unify the API for these 
"alternative secrets". What we're currently doing with GP+SAML is jamming 
":ALT_SECRET_FIELD" onto the end of the URL path, and parsing it out from there:
    
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fopenconnect%2Fopenconnect%2Fblob%2Fmaster%2Fauth-globalprotect.c%23L573-582&amp;data=02%7C01%7CAlan.Jowett%40microsoft.com%7Cc2723a399d0744cbef1f08d7a2f39054%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637157039293873057&amp;sdata=9SZYL4K9GWUj1XhX%2F0VjPdWtKgwqDLT83S%2F9nFYt66I%3D&amp;reserved=0

That's fairly horrid… it'd be good to have a uniform mechanism to specify this 
via the command-line AND the libopenconnect API.

-Dan
_______________________________________________
openconnect-devel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Reply via email to