Downloaded 24 times
![WS-Federation
Browser
RSTR
HTTP GET
wa=wsignIn1.0
wctx=[context]
wreq=[tokentype]
HTTP POST
wctx=[context]
wresult=RSTR
Passive
STS
Passive
RP
RequestedSecurityToken
SAML 2 Token
Signature
Subject Confirmation
Token Lifetime
Attributes (Claims = name, role)
RST
RSTR
Active
STS](https://image.slidesharecdn.com/securityavalanchebustamante-131120182115-phpapp02/85/Security-Avalanche-28-320.jpg)
![Home Realm Discovery
Browser
(requestor)
SignIn Response
RequestedSecurityToken
SAML 2 Token
Signature
Subject Confirmation
Token Lifetime
HTTP POST
wresult={Signin
Response}
wctx=[context]
2
1
HTTP GET
wa=wsignIn1.0
wtrealm=[Uri]
whr=[Uri]
wreply=[Uri]
wctx=[context]
Attributes (Claims = name, role)
Web Site
(RP)
IP-STS
(IdP)](https://image.slidesharecdn.com/securityavalanchebustamante-131120182115-phpapp02/85/Security-Avalanche-29-320.jpg)
Uploaded byMichele Leroux Bustamante
Security Avalanche
The document analyzes various web services security standards and frameworks, focusing on protocols like WS-Federation, SAML, and OAuth. It outlines their purposes, workflows, and applications in federated security scenarios, including single sign-on and delegated authorization. Additionally, it covers the processes of obtaining access tokens and managing credentials through OAuth 1.0a and 2.0, showcasing practical examples from Facebook interactions.
More Related Content
Similar to Security Avalanche
![[4developers2016] - Security in the era of modern applications and services (...](https://cdn.slidesharecdn.com/ss_thumbnails/4developers2016-modernappsecurity-160601100135-thumbnail.jpg?width=640&height=640&fit=bounds)
More from Michele Leroux Bustamante
Security Avalanche
- 1. Security Avalanche Michele LerouxBustamante michelebusta@solliance.net
- 2.
- 3.
- 4.
- 5.
- 6.
- 7. Industry-Specific Standards Transactions Messaging XML Transport Protocols TransportProtocols HTTP HTTPS SMTP Management/QOS Reliable Messaging Security Metadata Workflow
- 8. Industry-Specific Standards Transactions Messaging XML Schema XML XML XML TransportProtocols XML Digital Signatures XML Encryption Management/QOS Reliable Messaging Security Metadata Workflow
- 9.
- 10.
- 11. Industry-Specific Standards Security Reliable WS-RM Policy Messaging Transactions WS-RX WSRM Messaging XML TransportProtocols Management/QOS Reliable Messaging Metadata Workflow
- 12.
- 13.
- 14.
- 15. Industry-Specific Standards Insurance Industry-Specific LawEnforcement Standards Financial Services Goverment Reliable Messaging Transactions Messaging XML Transport Protocols Management/QOS Security Metadata Workflow
- 16. Industry-Specific Standards Workflow WS-SecureConversation WS-Trust WS-Federation Security SAML WS-SecurityPolicy Reliable Messaging Transactions OASIS WebServices Security Messaging XML Transport Protocols Management/QOS WS-SX Metadata Security
- 17. WS-Federation WS-ReliableMessaging WS-PolicyAttachment OASIS Web ServicesSecurity WS* HELL WS-Coordination WS-CAF WSDL MTOM WS-Transfer WS-Eventing WS-BusinessActivity WS-ResourceTransfer WSRF DIME WS-Addressing SOAP
- 18.
- 19.
- 20. Rich Client Windows Phone 8 Windows Phone 7 iPhone Windows 8/Surface Android Mobile Browsers iPad Web API WebAPI (mobile) (ajax) Web API (business) Web App
- 21. Simple Web Token (SWT) JSONWeb Token (JWT) Open ID 1.0 OAuth 1.0a Open ID 2.0 OAuth WRAP OpenID Connect 1.0 OAuth 2.0
- 22.
- 23. Security Standards: Goals • • • • • SingleSign-On (Passive Federation) Partner Federation (home realm redirection) Active Federation Delegation (on behalf of) Delegated Authorization
- 24. Session Agenda • • • • Review therelevant standards of today Practical applications Trends Implementation and architecture scenarios
- 25.
- 26.
- 27. WS-Federation • HTTPS • SAMLbearer tokens SignIn Response RequestedSecurityToken – Signed by issuer – Unencrypted and no proof key – Requires transport protection • Core Messages – SignIn request and response – Sign out and clean up 27 SAML 2 Token Signature Subject Confirmation Token Lifetime Attributes (Claims = name, role)
- 28. WS-Federation Browser RSTR HTTP GET wa=wsignIn1.0 wctx=[context] wreq=[tokentype] HTTP POST wctx=[context] wresult=RSTR Passive STS Passive RP RequestedSecurityToken SAML2 Token Signature Subject Confirmation Token Lifetime Attributes (Claims = name, role) RST RSTR Active STS
- 29. Home Realm Discovery Browser (requestor) SignInResponse RequestedSecurityToken SAML 2 Token Signature Subject Confirmation Token Lifetime HTTP POST wresult={Signin Response} wctx=[context] 2 1 HTTP GET wa=wsignIn1.0 wtrealm=[Uri] whr=[Uri] wreply=[Uri] wctx=[context] Attributes (Claims = name, role) Web Site (RP) IP-STS (IdP)
- 30. WS-Trust • HTTPS orMessage 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
- 31. Message Headers Signature =Proof Key SAML Token 3 Client 1 RP 2 RST RSTR RequestType = Issue Lifetime AppliesTo = /RelyingParty RST RSTR Proof Key TokenType = SAML 2 Claims = name, role RequestedProofToken WS-Trust / Issue() RequestedSecurityToken SAML 2 Token Signature Active STS Subject Confirmation Token Lifetime Attributes (Claims = name, role) Proof Key
- 32. Delegation / OnBehalf Of Client Bearer token Web Application Holder-of-key token Service STS Credentials
- 33. SAML • Security AssertionMarkup 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 browserbased
- 34.
- 35. Claims • Identity providerstypically issue claims based on the user’s identity Authenticate
- 36. Claims • Applications maytransform identity claims into application-specific claims Transform
- 37. Where are wenow?
- 38. Motivation for OAuth •No password sharing (valet key) • Reduced risk of compromised credentials • Ability to revoke access without changing password
- 39. 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
- 40. OAuth2 Participants • • • • Resource Owner Client AuthorizationServer Resource Server
- 41. 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
- 42. OAuth 2 AbstractFlow Authorization Request Authorization Request Resource Owner Authorization Response Authorization Response (return authorization code/grant) Access Token Request (send authorization code) Client Authorization Server Access Token Response (return access_token / refresh_token) Resource Request (send access_token) Resource Server Protected Resource
- 43. OAuth 2 AbstractFlow Credentials Authorization Request Authentication Token Resource Owner Authorization Response Client Identity Provider Authorization Request Authorization Response Access Token Request Authorization Server Access Token Response Resource Request Resource Server Protected Resource
- 44. Authorization Grant • RepresentsResource Owner authorization • Types of grants – Authorization Code – Implicit – Resource Owner Password Credentials – Client Credentials
- 45.
- 46. OAuth2 Flows • AuthorizationCode 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
- 47. Authorization Code • Useragent 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
- 48. Authorization Code Grant AuthorizationRequest Authorization Request Resource Owner Authorization Response Authorization Response Access Token Request Client Authorization Server Access Token Response Resource Request Resource Server Protected Resource
- 49.
- 50. Implicit • Optimized forJavaScript clients • Access token issued to Client directly – No authorization code (intermediate credential) – Access token may be visible to resource owner, user agent
- 51. Implicit Grant Authorization Request AuthorizationRequest Resource Owner Access Token Response Access Token Response Authorization Server Client Resource Request Resource Server Protected Resource
- 52.
- 53. Resource Owner PasswordCredentials • 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
- 54. Resource Owner Password CredentialsGrant Access Token Request Resource Owner Password Credentials Resource Owner Access Token Response Authorization Server Client Resource Request Resource Server Protected Resource
- 55. Resource Owner Password CredentialsGrant Login Page 1 2 3 Client Application grant_type Username password scope* acess_token token_type expires_in* scope* state* refresh_token* 7 Authorization Server Credentials Resource Server
- 56. Client Credentials • Clientis also Resource Owner • Present client credentials to request access
- 57. Client Credentials Grant AccessToken Request Access Token Response Authorization Server Client Resource Owner Resource Request Resource Server Protected Resource
- 58.
- 59. Extension Grant Flow •Client requests access token by presenting a token and specifying its kind – I.e., OAuth-SAML2 specification
- 60. Client Registration • Establishingtrust 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
- 61. Client Authentication • Clientsmay register a password (secret) with the Authorization Server • Pass with Basic Authentication • If not supported, pass as form parameters
- 62. Client Authentication • BasicAuthentication (recommended) POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA • Parameters POST /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
- 63. Access Token • Representsauthorization to resources • May be signed • Format described by accompanying specifications – I.e., SAML2, JWT
- 64. Access Token Response HTTP/1.1200 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" }
- 65. 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
- 66.
- 67.
- 68.
- 69.
- 70. Access Token Response HTTP/1.1200 OK Access-Control-Allow-Origin: * Cache-Control: private, no-cache, no-store, must-revalidate Content-Type: text/plain; charset=UTF-8 Expires: Sat, 01 Jan 2000 00:00:00 GMT Pragma: no-cache X-FB-Rev: 997953 X-FB-Debug: b8sYgk6apQZlsdJEXdTuEN+gisLdVvOQ15CK8o3cLSA= Date: Thu, 07 Nov 2013 11:47:59 GMT Connection: keep-alive Content-Length: 215 access_token=CAAGPKZBXdGDIBAImEo6Pf6GthtiEdjQoAGWUBiNSwUeTuZAbztASscJKp NZCsuKUSBDQqwJ9ZAPUF7tugWkgbaUqh8vQkHwZCsARz7rEu0j8EfDA0tZA8CIW2ZAbS Qh4fNDTNpUm0B4zZAxqycQsYjLhY8BarPp9izFZBUVeAsYQCfoVBqK4WwSxq
- 71.
- 72. Profile Response HTTP/1.1 200OK … 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":"mich elebusta","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":"michelebustau0040gmail.com","timezone":1,"l ocale":"en_US","verified":true,"updated_time":"2013-11-07T11:44:01+0000"}
- 73. Invalid Access Token GET https://graph.facebook.com/574847493/friends?access_token=CAAGPKZBXdGDIBAGt zITGJq3ykpbuSDF6xQlDxonZCGW15CKCgq4fmfKH5QK7pYq374C9uWcZAZBnJrqZAEpx4 gp73U9bGNmJlb0dvby3LkvuVrzGZCxBvZCbWrXWyHuouAil15sm76Q5g4uQ5myiCFRaR aMEOHXLNPCTClK2IApKEkB7A51qe7F&limit=5000&fields=%5B%22id%22%2C%22nam e%22%2C%22link%22%5DHTTP/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}}
- 75. And now, fora creepy image of the original OpenID
- 76.
- 77. OpenID Connect vs.OAuth 2
- 78. OpenID ID TokenResponse HTTP/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" }
- 79. 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" }
- 80. Where are wenow?
- 81. 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
- 82. References • Conference resourcesto 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
- 83. Michele Leroux Bustamante ManagingPartner Solliance (solliance.net) CEO and Cofounder Snapboard (snapboard.com) Microsoft Regional Director Microsoft MVP Author, Speaker Pluralsight courses on the way! Blog: michelebusta.com michelebusta@solliance.net @michelebusta