Security Avalanche

Security Avalanche

Michele Leroux Bustamantemichelebusta@solliance.net

Hello World!1992

Hello World!

Hello World!1995-2007

RichClient

Web Services Web App

Web Services

1999 - 2007

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Transport Protocols

HTTPSHTTP SMTP

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

XMLXML Schema

XML XML Encryption

XML Digital Signatures

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

MessagingWS-Eventing

WS-Addressing SOAP

MTOM

sWa

WS-Transfer

WS-Enumeration

DIMEWSRF

WSN

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Met

adat

a

WS-Policy

WSDL

WS-PolicyAttachment

WS-Discovery

WS-MetadataExchange

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

ReliableMessaging

WS-RX

WS-RM Policy

WSRM

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Transactions

WS-TX

WS-CAF

WS-BusinessActivity

WS-Coordination

WS-AtomicTransaction

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

WorkflowWS-ChoreographyBPEL

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Man

agem

ent/

QO

S

WS-Manageability

WSDM

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Industry-Specific StandardsInsurance Law Enforcement

Financial Services Goverment

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Security

OASIS Web Services Security

WS-SecurityPolicy

WS-Federation

SAML

WS-SecureConversation

WS-Trust

WS-SX

WS*

HELL

WS-Eventing

WS-Addressing

SOAP

MTOM

sWa

WS-Transfer

WS-Enum

eration

DIME

WSNWS-ResourceTransfer

WSRF

OASIS Web Services Security

WS-SecurityPolicy

WS-Federation

SAML

WS-SecureConversation

WS-

Trus

t

WS-ReliableMessaging

WS-RM

Policy

WS-

Relia

bilit

y

WS-CAF

WS-BusinessActivity

WS-Coordination

WS-A

tom

icTr

ansa

ctio

n

WS-Policy

WSDL

WS-PolicyAttachment

WS-Discovery

WS-M

etadataExchange

Hello World!1992

RichClient

Web Services Web App

Web Services

iPhoneWindowsPhone 8

Windows8/Surface

RichClient

WindowsPhone 7

Android

iPad

Web API(mobile)

Web App

MobileBrowsers

Web API(business)

Web API(ajax)

2006 - 2013Open ID 1.0

Open ID 2.0

OpenID Connect1.0

Simple Web Token (SWT)

JSON Web Token (JWT)

OAuth 1.0a

OAuth WRAP

OAuth 2.0

SIMPLICITY WINS

Security Standards: Goals

• Single Sign-On (Passive Federation)• Partner Federation (home realm redirection)• Active Federation• Delegation (on behalf of)• Delegated Authorization

Session Agenda

• Review the relevant standards of today• Practical applications• Trends• Implementation and architecture scenarios

Passive Federation

Browser

WebApplication STS

LoginPage

1

2

5

3

4

Active Federation

STS Web Service

RichClient

1 2 3

WS-Federation

• HTTPS• SAML bearer tokens

– Signed by issuer– Unencrypted and no proof key– Requires transport protection

• Core Messages– SignIn request and response– Sign out and clean up

27

SignIn ResponseRequestedSecurityToken

SAML 2 Token

Attributes (Claims = name, role)

Subject Confirmation

Token Lifetime

Signature

WS-Federation

Browser

ActiveSTS

PassiveSTS

HTTP GETwa=wsignIn1.0wctx=[context]wreq=[tokentype]

RST RSTR

HTTP POSTwctx=[context]wresult=RSTR

RSTRRequestedSecurityToken

SAML 2 Token

Attributes (Claims = name, role)

Subject Confirmation

Token Lifetime

Signature

PassiveRP

Home Realm Discovery

1

Web Site(RP)

IP-STS(IdP)

Browser(requestor)

HTTP POSTwresult={Signin

Response}wctx=[context]

HTTP GETwa=wsignIn1.0wtrealm=[Uri]whr=[Uri]wreply=[Uri]wctx=[context]

2

SignIn ResponseRequestedSecurityToken

SAML 2 Token

Attributes (Claims = name, role)

Subject Confirmation

Token Lifetime

Signature

WS-Trust

• HTTPS or Message Security (WS-Security)• SAML holder-of-key tokens

– Signed by issuer– Encrypted for relying party– Includes proof key

• Core Messages (WS-Federation also uses)– RST and RSTR– Token validation, renewal or cancellation

30

ActiveSTS

Client

RST RSTR

WS-Trust / Issue()

RST

TokenType = SAML 2

Claims = name, role

RequestType = Issue

AppliesTo = /RelyingParty

RSTRLifetime

RequestedProofToken

RequestedSecurityToken

SAML 2 Token

Attributes (Claims = name, role)

Subject Confirmation

Token Lifetime

Signature

Proof Key

Proof Key

1

RP

Message Headers

SAML Token

Signature = Proof Key

2

3

Delegation / On Behalf Of

Client

Service

STS CredentialsWeb Application

Holder-of-key token

Bearer token

SAML

• Security Assertion Markup Language– OASIS standard– Several versions 1.0, 1.1, 2.0

• Describes an XML security token format and message exchange protocol– Tokens are also used in federated security

scenarios for web services– Message exchange is primarily browser-

based

SAML 2 SP-Initiated

Browser

ServiceProvider

IdentityProvider

(STS)

LoginPage

1

2

5

3

4

Claims

• Identity providers typically issue claims based on the user’s identity

Authenticate

Claims:Name=MicheleEmail=mlb@idesign.netIsOver21=trueRole=AdminRole=User

Credentials:UserName=mlbPassword =*******

Claims

• Applications may transform identity claims into application-specific claims

Transform

Application Specific Claims:LicenseKey=ABC12345Permission=CreatePermission=ReadPermission=UpdatePermission=Delete

Identity ProviderClaims:Name=MicheleEmail=mlb@idesign.netIsOver21=trueRole=AdminRole=User

Where are we now?

WS-Federation

WS-Trust

SAML 2

Motivation for OAuth

• No password sharing (valet key)• Reduced risk of compromised credentials• Ability to revoke access without changing

password

History

• OAuth 1.0a– Complicated workflows– Required signatures– BUT, no SSL required

• OAuth 2– Simplified workflows– Rely on SSL for transfer protection– Signatures NOT required

OAuth2 Participants

• Resource Owner• Client• Authorization Server• Resource Server

OAuth2 Abstract Flow

• Client requests authorization from Resource Owner to access resources

• Resource Owner grants access through Authorization Server

• Client uses access token to request resources from Resource Server

• Resource Server returns resource if access token is valid

OAuth 2 Abstract Flow

ResourceOwner

Client

Authorization Server

ResourceServer

Authorization Request

Authorization Response(return authorization

code/grant)

Authorization Request

Authorization Response

Access Token Request (send authorization code)

Access Token Response (return access_token / refresh_token)

Resource Request (send access_token)

Protected Resource

OAuth 2 Abstract Flow

ResourceOwner

Client

Authorization Server

ResourceServer

Authorization Request

Authorization Response

Authorization Request

Authorization Response

Access Token Request

Access Token Response

Resource Request

Protected Resource

IdentityProvider

Credentials

Authentication Token

Authorization Grant

• Represents Resource Owner authorization• Types of grants

– Authorization Code– Implicit – Resource Owner Password Credentials– Client Credentials

Endpoints

Client Authorization Server

RedirectionEndpoint

POST

TokenEndpoint

AuthorizationEndpoint

GET/POST

OAuth2 Flows

• Authorization Code Grant– Redirect based, web server redirect endpoint

• Implicit Grant– Browser based (JavaScript), Mobile

• Resource Owner Password Credentials Grant– Resource owner username/password known to client

• Client Credentials Grant– Application based

• Extension Grant

Authorization Code

• User agent redirection (I.e., browser)• Resource Owner must authenticate to

Authorization Server – Credentials never shared with Client– Authorization code sent to Client

• Client requests access token using authorization code– Access token never passed to user agent

Authorization Code Grant

ResourceOwner

Client

Authorization Server

ResourceServer

Authorization Request

Authorization Response

Authorization Request

Authorization Response

Access Token Request

Access Token Response

Resource Request

Protected Resource

Authorization Code Flow

Browser

ClientApplication

Authorization Server

LoginPage

1

2

5

3

4

ResourceServer

codestate*

grant_typecoderedirect_uriclient_id6

7Credentials

response_typeclient_idredirect_uri*scope*state*

codestate*

5

acess_tokentoken_typeexpires_in*scope*state*refresh_token*

Implicit

• Optimized for JavaScript clients• Access token issued to Client directly

– No authorization code (intermediate credential)– Access token may be visible to resource owner,

user agent

Implicit Grant

ResourceOwner

Client

Authorization Server

ResourceServer

Authorization Request

Access Token Response

Authorization Request

Access Token Response

Resource Request

Protected Resource

Implicit Flow

Browser

ClientApplication

Authorization Server

LoginPage

1

5

2

3

ResourceServer

access_token

Credentials

response_typeclient_idredirect_uri*scope*state*

4

acess_tokentoken_typeexpires_in*scope*state*

Resource Owner Password Credentials

• Resource Owner credentials supplied to request access token

• Client is tightly coupled to Resource Owner– High degree of trust– Client collects credentials to get access token

• Can exchange credentials for access token– Dispose of passwords in memory

Resource Owner Password Credentials Grant

ResourceOwner

Authorization Server

ResourceServer

Access Token Response

Resource Request

Protected Resource

Client

Resource Owner Password Credentials

Access Token Request

Resource Owner Password Credentials Grant

ClientApplication

Authorization Server

LoginPage

ResourceServer

3

7Credentials

grant_typeUsernamepasswordscope*

acess_tokentoken_typeexpires_in*scope*state*refresh_token*

1 2

Client Credentials

• Client is also Resource Owner• Present client credentials to request access

Client Credentials Grant

Authorization Server

ResourceServer

Access Token Response

Resource Request

Protected Resource

Client

Access Token Request

ResourceOwner

Client Credentials Grant

ClientApplication

Authorization Server

ResourceServer

1

2Credentials

grant_typeclient_id*scope*

acess_tokentoken_typeexpires_in*scope*state*refresh_token*

Extension Grant Flow

• Client requests access token by presenting a token and specifying its kind– I.e., OAuth-SAML2 specification

Client Registration

• Establishing trust with Authorization Server– Provide a client type– Provide a Url– Provide other optional information

• Required for public and for implicit grants

Client Profile Client Type

Web Application Confidential

User-Agent Based Public

Native Application Public

Client Authentication

• Clients may register a password (secret) with the Authorization Server

• Pass with Basic Authentication • If not supported, pass as form parameters

Client Authentication

• Basic Authentication (recommended)

• ParametersPOST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

POST /token HTTP/1.1 Host: server.example.comAuthorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Access Token

• Represents authorization to resources• May be signed• Format described by accompanying

specifications– I.e., SAML2, JWT

Access Token Response

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example",

"expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

Refresh Token

• Optional, Authorization Server decides• Sent to Authorization Server to retrieve another

access token– Different scope– Additional time

• If access token is expired, can use refresh token to request another one– Without prompting Resource Owner– Unless scope increases beyond what was approved

Facebook Examples

Authorization Request

GET https://www.facebook.com/dialog/oauth?client_id=438893679548466&redirect_uri=http%3A%2F%2Fdemo.snapboard.com%2FSnapBoardDemo%2FAccount%2FExternalLoginCallback%3F__provider__%3Dfacebook%26__sid__%3D9fbc4fb2ac434930a78e50c895271a0f&scope=email%20user_about_me%20user_birthday%20user_friends%20publish_actions HTTP/1.1

Response w/ Grant

GET http://demo.snapboard.com/SnapBoardDemo/Account/ExternalLoginCallback?__provider__=facebook&__sid__=9fbc4fb2ac434930a78e50c895271a0f&code=AQCxVpduOEybUZVpB74wFCzZZVCPgBfpnBj7tvxSDVGag9u9zV9yX268Wf0eB1rb6nZYmoFRlweasCIKksFQkwzEzE0aWYuzstA_ciHbhJSTmMb0ZsrlZ9jjXLMHrdirigIOz13WC8nW-gbXQzuwG1DmmJFEv2KtupZl8KMAIZBSVsu9aewPT5R2lNgSgfg_SW53Qt2qliVP32NEu-q0BiuvdphDDSjwWCjSHtW4SMC73DdL9O7Bjt2vz-lumDq9b5asuuxFvx_KQknhFRhAX15W-8CYBOEWZ0vVYsFjI5tCSMEAYZ6EAm62HEbNZTj9aJw HTTP/1.1

Request Access Token

GET https://graph.facebook.com/oauth/access_token?client_id=438893679548466&redirect_uri=http%3A%2F%2Fdemo.snapboard.com%2FSnapBoardDemo%2FAccount%2FExternalLoginCallback%3F__provider__%3Dfacebook%26__sid__%3D9fbc4fb2ac434930a78e50c895271a0f&client_secret=8022ba46243c1becc5e4020f72f08bd7&code=AQCxVpduOEybUZVpB74wFCzZZVCPgBfpnBj7tvxSDVGag9u9zV9yX268Wf0eB1rb6nZYmoFRlweasCIKksFQkwzEzE0aWYuzstA_ciHbhJSTmMb0ZsrlZ9jjXLMHrdirigIOz13WC8nW-gbXQzuwG1DmmJFEv2KtupZl8KMAIZBSVsu9aewPT5R2lNgSgfg_SW53Qt2qliVP32NEu-q0BiuvdphDDSjwWCjSHtW4SMC73DdL9O7Bjt2vz-lumDq9b5asuuxFvx_KQknhFRhAX15W-8CYBOEWZ0vVYsFjI5tCSMEAYZ6EAm62HEbNZTj9aJw&scope=email HTTP/1.1

Access Token ResponseHTTP/1.1 200 OKAccess-Control-Allow-Origin: *Cache-Control: private, no-cache, no-store, must-revalidateContent-Type: text/plain; charset=UTF-8Expires: Sat, 01 Jan 2000 00:00:00 GMTPragma: no-cacheX-FB-Rev: 997953X-FB-Debug: b8sYgk6apQZlsdJEXdTuEN+gisLdVvOQ15CK8o3cLSA=Date: Thu, 07 Nov 2013 11:47:59 GMTConnection: keep-aliveContent-Length: 215

access_token=CAAGPKZBXdGDIBAImEo6Pf6GthtiEdjQoAGWUBiNSwUeTuZAbztASscJKpNZCsuKUSBDQqwJ9ZAPUF7tugWkgbaUqh8vQkHwZCsARz7rEu0j8EfDA0tZA8CIW2ZAbSQh4fNDTNpUm0B4zZAxqycQsYjLhY8BarPp9izFZBUVeAsYQCfoVBqK4WwSxq

Request Profile Info

GET https://graph.facebook.com/me?access_token=CAAGPKZBXdGDIBAImEo6Pf6GthtiEdjQoAGWUBiNSwUeTuZAbztASscJKpNZCsuKUSBDQqwJ9ZAPUF7tugWkgbaUqh8vQkHwZCsARz7rEu0j8EfDA0tZA8CIW2ZAbSQh4fNDTNpUm0B4zZAxqycQsYjLhY8BarPp9izFZBUVeAsYQCfoVBqK4WwSxq HTTP/1.1Host: graph.facebook.com

Profile Response

HTTP/1.1 200 OK…Content-Length: 609

{"id":"574847493","name":"Michele Leroux Bustamante","first_name":"Michele","middle_name":"Leroux","last_name":"Bustamante","link":"https:\/\/www.facebook.com\/michelebusta","username":"michelebusta","birthday":”LA LA LA LA","bio":"I'm a geek. Wait, no I'm not. Wait, yes I am...","quotes":"Never complain, never explain. -Katherine Hepburn”,"gender":"female","email":"michelebusta\u0040gmail.com","timezone":1,"locale":"en_US","verified":true,"updated_time":"2013-11-07T11:44:01+0000"}

Invalid Access Token

GET https://graph.facebook.com/574847493/friends?access_token=CAAGPKZBXdGDIBAGtzITGJq3ykpbuSDF6xQlDxonZCGW15CKCgq4fmfKH5QK7pYq374C9uWcZAZBnJrqZAEpx4gp73U9bGNmJlb0dvby3LkvuVrzGZCxBvZCbWrXWyHuouAil15sm76Q5g4uQ5myiCFRaRaMEOHXLNPCTClK2IApKEkB7A51qe7F&limit=5000&fields=%5B%22id%22%2C%22name%22%2C%22link%22%5D HTTP/1.1

HTTP/1.1 400 Bad Request…WWW-Authenticate: OAuth "Facebook Platform" "invalid_token" "Error validating access token: User 574847493 has not authorized application 438893679548466."…Content-Length: 172

{"error":{"message":"Error validating access token: User 574847493 has not authorized application 438893679548466.","type":"OAuthException","code":190,"error_subcode":458}}

And now, for a creepy image of the

original OpenID

http://openidexplained.com/

OpenID Connect vs. OAuth 2

OpenID ID Token ResponseHTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "access_token": "SlAV32hkKG", "token_type": "Bearer", "refresh_token": "8xLOxBtZp8", "expires_in": 3600, "id_token": "eyJhbGciOiJSUzI1NiJ9.ew0KICAgICJpc3MiOiAiaHR0cDovL 3NlcnZlci5leGFtcGxlLmNvbSIsDQogICAgInVzZXJfaWQiOiAiMjQ4Mjg5NzYxM DAxIiwNCiAgICAiYXVkIjogInM2QmhkUmtxdDMiLA0KICAgICJub25jZSI6ICJuL TBTNl9XekEyTWoiLA0KICAgICJleHAiOiAxMzExMjgxOTcwLA0KICAgICJpYXQiO iAxMzExMjgwOTcwDQp9.lsQI_KNHpl58YY24G9tUHXr3Yp7OKYnEaVpRL0KI4szT D6GXpZcgxIpkOCcajyDiIv62R9rBWASV191Akk1BM36gUMm8H5s8xyxNdRfBViCa xTqHA7X_vV3U-tSWl6McR5qaSJaNQBpg1oGPjZdPG7zWCG-yEJC4-Fbx2FPOS7-h 5V0k33O5Okd-OoDUKoFPMd6ur5cIwsNyBazcsHdFHqWlCby5nl_HZdW-PHq0gjzy JydB5eYIvOfOHYBRVML9fKwdOLM2xVxJsPwvy3BqlVKc593p2WwItIg52ILWrc6A tqkqHxKsAXLVyAoVInYkl_NDBkCqYe2KgNJFzfEC8g" }

ID Token

{ "iss": "https://server.example.com", "sub": "24400320", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "auth_time": 1311280969, "acr": "urn:mace:incommon:iap:silver", "at_hash": "MTIzNDU2Nzg5MDEyMzQ1Ng" }

Where are we now?

WS-Federation + SAML 1.1/2WS-Trust + SAML 1.1/2

SAML 2

OAuth2 + JWT

OpenID Connect

Suggested Implementations

• Thinktecture– Authorization Server and Identity Provider– All but SAML 2– Open Source

• Auth0– Hosted model or appliance– Affordable, from small bus to enterprise– All protocols– FREE version for dev

References

• Conference resources to be referenced here: – http://michelebusta.com

• See my snapboards:– Currently at the alpha site:

http://snapboardalpha.cloudapp.net/michelebusta– Will move these to snapboard.com/michelebusta when we

go live on the main site (SOON watch my blog for announcement)

• Contact me:– michelebusta@solliance.net– @michelebusta

Michele Leroux BustamanteManaging Partner

Solliance (solliance.net) CEO and Cofounder

Snapboard (snapboard.com)

Microsoft Regional Director Microsoft MVP

Author, SpeakerPluralsight courses on the way!Blog: michelebusta.commichelebusta@solliance.net@michelebusta