hope or hype: a look at the next generation of identity standards

Hope or Hype?A Look at the Next Generation of

Identity Standards

OpenID Connect, OAuth, JOSE and JWT may be the new kids on the block but many experts and visionaries have already

anointed them to replace SAML. Is the wheel being needlessly reinvented or is genuine progress on the horizon?

Brian Campbell

CIS Napa

July 2013

@__b_cbackground and layout of slides specially designed for

@lpeterman & @NishantK

BACKSTORYA Tale of Two (okay maybe more) Protocols

http://flic.kr/s/aHsjziVAwV

It was the best of times…

http://flic.kr/s/aHsjAP3nKo

SAML is DEAD!

it was the worst of times…

“Craig Burton is one of the

leading visionaries and analysts in the

computer industry.”*

* http://www.linkedin.com/in/burtonian

SAML

Stan and Kyle are fictional characters from the TV show South Park. I presume the show’s creators, Trey Parker & Matt Stone, are rich enough and busy enough

not to bother suing me over unlicensed use in some nerdy computer presentation.

@craigburton

it was the age of foolishness…

WTF “SAML is dead”? I’ve got a mortgage to

pay…

*Disclaimer: I work with these guys at Ping

But I just started this

job!

@paulmadsen

@ian13550

it was the age of wisdom …

*http://blogs.kuppingercole.com/kearns/2012/07/31/the-death-and-life-of-a-protocol/

SAML is dead:• Doesn't mean it’s

bad or not useful.

• It means it is not the future.

Dave "Crusty Curmudgeon”*

Kearns

* @dak3Burton quotes:• “SAML is the Windows XP of Identity. No funding. No innovation.

People still use it. But it has no future.”• “No one is putting money into SAML development. No one is

writing new SAML code. SAML is dead.”

it was the epoch of belief…

• OpenID Connect• simple JSON/REST-based interoperable identity protocol built on top of the OAuth

2.0 family of specifications. • design philosophy: “make simple things simple and make complicated things

possible.”• Wins 2012 European Identity and Cloud Award

• “OpenID Connect the award[ed] Best Innovation/New Standard this year. What’s most impressive is that this elegantly simple design resulted from the cooperation of such a diverse global set of contributors. I expect OpenID Connect to have a substantial positive impact on usable, secure identity solutions both for traditional computing platforms and mobile devices. My congratulations to the OpenID Foundation!” - Dave Kearns

• “spurs global economic growth by enabling simple and secure exchange of verified attributes from multiple sources at Internet scale.”

http://openid.net/2012/04/18/openid-connect-wins-2012-european-identity-and-cloud-award/

it was the epoch of incredulity…

May, 2010: Conceptual

Debut of Connect

time elapses

February, 2012: 1st

Implementer’s Drafts

March 2012 time elapsesMay, 2013: 2nd Implementer’s

Drafts…?

https://twitter.com/__b_c/status/181884679513833473

three nerds holding a blurry piece of paper...

*Disclaimer: this guy also ‘works’ for Ping

And I know these guys reasonably well from various initiatives

http://www.thread-safe.com/2012/04/openid-connect-wins-2012-european.html

“The OpenID Connect specifications are

expected to be completed in the second

half of 2012.”

@selfissued@_nat_en @ve7jtb

we were all going direct to Heaven, we were all going direct the other way

on your deathbed, you will receive total consciousness

*I did actually receive permission to use this photo

@JasonABonds

in short, the period was so far like the present period

Another Look

JOSEWebFinger

OAuth

Connect

OAuth Refresher

Client

ResourceServer

Get an access token

Use an access token

AuthorizationServer

Authorization Endpoint

Token Endpoint

Important Stuff

Where the magic

happens

Discovery

OpenID Connect is built on OAuth

ClientRelying Party

ResourceServer

Get an access token

& an ID Token (JWT)

Use an access token

AuthorizationServer

Identity Provider orIDP or

OpenID Provider orOP

Authorization Endpoint

Token Endpoint

Important Stuff

Userinfo Endpoint

Registration Endpoint

JWKS Endpoint

JWKS Endpoint

Validate (JWT)

ID Token

/.well-known /webfinger /openid-configuration

Check Session IFrame

End Session Endpoint

jot or not?

The JWTeyJraWQiOiI1IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJodHRwczpcL1wvaWRwLmV4YW1wbGUuY29tIiwKImV4cCI6MTM1NzI1NTc4OCwKImF1ZCI6Imh0dHBzOlwvXC9zcC5leGFtcGxlLm9yZyIsCiJqdGkiOiJ0bVl2WVZVMng4THZONzJCNVFfRWFjSC5fNUEiLAoiYWNyIjoiMiIsCiJzdWIiOiJCcmlhbiJ9.SbPJIx_JSRM1wluioY0SvfykKWK_yK4LO0BKBiESHu0GUGwikgC8iPrv8qnVkIK1aljVMXcbgYnZixZJ5UOArg

The Header{"kid":"5","alg":"ES256"}

The Payload{"iss":"https:\/\/idp.example.com","exp":1357255788,"aud":"https:\/\/sp.example.org","jti":"tmYvYVU2x8LvN72B5Q_EacH._5A","acr":"2","sub":"Brian"}

The Signature[computery junk]

JSON Web Token (JWT) & JSON Web Signature (JWS)

eyJraWQiOiI1IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJodHRwczpcL1wvaWRwLmV4YW1wbGUuY29tIiwKImV4cCI6MTM1NzI1NTc4OCwKImF1ZCI6Imh0dHBzOlwvXC9zcC5leGFtcGxlLm9yZyIsCiJqdGkiOiJ0bVl2WVZVMng4THZONzJCNVFfRWFjSC5fNUEiLAoiYWNyIjoiMiIsCiJzdWIiOiJCcmlhbiJ9.SbPJIx_JSRM1wluioY0SvfykKWK_yK4LO0BKBiESHu0GUGwikgC8iPrv8qnVkIK1aljVMXcbgYnZixZJ5UOArg

it’s not the size of your token…

<Assertion Version="2.0" IssueInstant="2013-01-03T23:34:38.546Z” ID="oPm.DxOqT3ZZi83IwuVr3x83xlr" xmlns="urn:oasis:names:tc:SAML:2.0:assertion” xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <Issuer>https://idp.example.com</Issuer> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/> <ds:Reference URI="#oPm.DxOqT3ZZi83IwuVr3x83xlr"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>8JT03jjlsqBgXhStxmDhs2zlCPsgMkMTC1lIK9g7e0o=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>SAXf8eCmTjuhV742blyvLvVumZJ+TqiG3eMsRDUQU8RnNSspZzNJ8MOUwffkT6kvAR3BXeVzob5p08jsb99UJQ==</ds:SignatureValue> </ds:Signature> <Subject> <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">Brian</NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData NotOnOrAfter="2013-01-03T23:39:38.552Z" Recipient="https://sp.example.org"/> </SubjectConfirmation> </Subject> <Conditions NotOnOrAfter="2013-01-03T23:39:38.552Z" NotBefore="2013-01-03T23:29:38.552Z"> <AudienceRestriction> <Audience>https://sp.example.org</Audience> </AudienceRestriction> </Conditions> <AuthnStatement AuthnInstant="2013-01-03T23:34:38.483Z" SessionIndex="oPm.DxOqT3ZZi83IwuVr3x83xlr"> <AuthnContext> <AuthnContextClassRef>2</AuthnContextClassRef> </AuthnContext> </AuthnStatement></Assertion>

JWT

SAML

• Web safe encoding w/ no canonicalization– Because canonicalization is a four letter word

(especially when you spell it c14n)

• Simpler• Improved Interoperability & (hopefully)

More Secure • Eliminates entire classes of attacks

– XSLT Transform DOS, Remote Code Execution, and Bypass– C14N Hash Collision w/ & w/out comments– Entity Expansion Attacks– XPath Transform DOS and Bypass– External Reference DOS– Signature Wrapping Attacks*

it’s how you use it

* http://www.google.com/about/appsecurity/hall-of-fame/reward/

JSON Web Key (JWK)

JWT/JWS Header{"kid":"5","alg":"ES256"}

{"keys":[ {"kty":"EC", "kid":"4", "x":"LX-7aQn7RAx3jDDTioNssbODUfED_6XvZP8NsGzMlRo", "y":"dJbHEoeWzezPYuz6qjKJoRVLks7X8-BJXbewfyoJQ-A", "crv":"P-256"}, {"kty":"EC", "kid":"5", "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU", "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0", "crv":"P-256"}, {"kty":"EC", "kid":"6", "x":"J8z237wci2YJAzArSdWIj4OgrOCCfuZ18WI77jsiS00", "y":"5tTxvax8aRMMJ4unKdKsV0wcf3pOI3OG771gOa45wBU", "crv":"P-256"}]}

• Why the ID Token?– Access Token is a message to the protected

resource about authorization– ID Token is a message to the client about user

authentication

• Motivation and consequence– Sharing/misusing a regular AT isn’t particularly

harmful or enticing– Unless it can be used to access at the client

• Which is exactly what the ID Token is for and it has built in protections

• Buy why two?– Connect didn’t really have the liberty to

encroach on the access token

two is better than one

• JSON based & more RESTafarian friendly

• Simplicity (esp. in JW* or JW[STEAK])• API & SSO together• Better support for mobile• Shifted burden of complexity• Webfinger based Discovery• Provider Configuration Info at a “well-

known” location• Defined interaction sequence for client

registration• Keys included with but decoupled from

discovery/registration • Totally new approach to SLO / session

management

hope for the other 99%

So… in conclusion,

is it hope or hype?

Brian Campbell

CIS Napa

July 2013

@__b_c

Hope or Hype?

“yes”(Sorry)

SAMLAny Questions?

Brian Campbell

CIS Napa

July 2013

@__b_c