Brian Campbell
2017-04-03 11:51:59 UTC
Below is the Token Binding demo that I mentioned and said I share on the
list during the Friday meeting in Chicago.
---------- Forwarded message ----------
From: Brian Campbell <***@pingidentity.com>
Date: Fri, Mar 24, 2017 at 3:11 PM
Subject: Token Binding Demo Online
To: IETF Tokbind WG <***@ietf.org>
I put up a demonstration of some token binding functionality that I wanted
to share. There are a few parts to it, which I'll attempt to describe
below.
At https://unbearable-bc.ping-eng.com:3000/open/ is a token binding capable
reverse proxy (of sorts) that is proxying requests to http://httpbin.org/
with a little path rewriting. If you go to https://unbearable-bc.ping-
eng.com:3000/open/headers with a token binding (-10 to -13) capable
browser, for example, you should see the a dump of the request headers
including "Sec-Token-Binding".
The reverse proxy is also set up with some access control and will proxy
from https://unbearable-bc.ping-eng.com:3000/ to http://httpbin.org/ but
require an authenticated session to do so. And it's using OpenID Connect
Token Bound Authentication
<http://openid.net/specs/openid-connect-token-bound-authentication-1_0.html>
with an IDP at https://token-provider-bc.ping-eng.com:9031 to authenticate
users.
So, for example, if you go to https://unbearable-bc.ping-
eng.com:3000/headers without a session you will be redirected to the
authorization endpoint at that IDP and presented with a login page. Use
USERNAME: brian and PASSWORD: Test5555 on that page. After login, you'll be
sent back to the relying party via the Form Post Response Mode
<https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html> where
the ID Token is sent though the browser. If you grab that token and decode
it, there should be a confirmation method claim that has the hash of the
Token Binding ID used with the relying party (i.e. "cnf": {"tbh":
"...hash..."}).
The relying party sets up its own session from the OIDC SSO, which is a
cookie named PA.unbearable that is a JWT. The page at
https://unbearable-bc.ping-eng.com:3000/headers will dump the headers
including that cookie. If you decode that JWT, you should also see that the
local session is token bound with the confirmation method claim.
Things will still work when using a non token binding capable browser but
none of the tokens will be token bound.
As a reminder, you can enable Token Binding in Chrome by putting
chrome://flags/#enable-token-binding into the address bar. Chrome and Chrome
Canaryâ are what I've been using to play with this. I'm hopping someone
with the TB enabled Edge/IE can poke around on this demo too.
list during the Friday meeting in Chicago.
---------- Forwarded message ----------
From: Brian Campbell <***@pingidentity.com>
Date: Fri, Mar 24, 2017 at 3:11 PM
Subject: Token Binding Demo Online
To: IETF Tokbind WG <***@ietf.org>
I put up a demonstration of some token binding functionality that I wanted
to share. There are a few parts to it, which I'll attempt to describe
below.
At https://unbearable-bc.ping-eng.com:3000/open/ is a token binding capable
reverse proxy (of sorts) that is proxying requests to http://httpbin.org/
with a little path rewriting. If you go to https://unbearable-bc.ping-
eng.com:3000/open/headers with a token binding (-10 to -13) capable
browser, for example, you should see the a dump of the request headers
including "Sec-Token-Binding".
The reverse proxy is also set up with some access control and will proxy
from https://unbearable-bc.ping-eng.com:3000/ to http://httpbin.org/ but
require an authenticated session to do so. And it's using OpenID Connect
Token Bound Authentication
<http://openid.net/specs/openid-connect-token-bound-authentication-1_0.html>
with an IDP at https://token-provider-bc.ping-eng.com:9031 to authenticate
users.
So, for example, if you go to https://unbearable-bc.ping-
eng.com:3000/headers without a session you will be redirected to the
authorization endpoint at that IDP and presented with a login page. Use
USERNAME: brian and PASSWORD: Test5555 on that page. After login, you'll be
sent back to the relying party via the Form Post Response Mode
<https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html> where
the ID Token is sent though the browser. If you grab that token and decode
it, there should be a confirmation method claim that has the hash of the
Token Binding ID used with the relying party (i.e. "cnf": {"tbh":
"...hash..."}).
The relying party sets up its own session from the OIDC SSO, which is a
cookie named PA.unbearable that is a JWT. The page at
https://unbearable-bc.ping-eng.com:3000/headers will dump the headers
including that cookie. If you decode that JWT, you should also see that the
local session is token bound with the confirmation method claim.
Things will still work when using a non token binding capable browser but
none of the tokens will be token bound.
As a reminder, you can enable Token Binding in Chrome by putting
chrome://flags/#enable-token-binding into the address bar. Chrome and Chrome
Canaryâ are what I've been using to play with this. I'm hopping someone
with the TB enabled Edge/IE can poke around on this demo too.