Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JDD2015: Security in the era of modern applications and services - Bolesław Dawidowicz

155 views

Published on

SECURITY IN THE ERA OF MODERN APPLICATIONS AND SERVICES

Security is hard. Old days are over and it requires way more then providing login form, comparing password hash and maintaining HTTP session. With the raise of mobile and client side apps, (micro) services and APIs it has become a fairly complex topic. At the same time with security breaches hitting the news on the monthly basis it is everyone's concern. Being an area every developer or architect needs to understand very well.


Thankfully a number of modern standards and solutions emerged to help with current challenges. During this talk you will learn how to approach typical security needs using modern token based security and standards like OAuth2, OpenID Connect or SAML. We’ll discuss wide variety of security related topics around multi factor authentication or identity federation and brokering . You will also learn how you can leverage modern open source identity and access management solutions in your applications.

Published in: Software
  • Be the first to comment

  • Be the first to like this

JDD2015: Security in the era of modern applications and services - Bolesław Dawidowicz

  1. 1. Security in the era of modern applications and services JDD 2015 Kraków Bolesław Dawidowicz Engineering Manager, Red Hat
  2. 2. Me…
  3. 3. 10 years working at Red Hat
  4. 4. Security team at Red Hat (Middleware Products)
  5. 5. Keycloak Open Source Identity and Access Management Solution
  6. 6. Agenda - Part 1 • Problems with modern security • Why it used to be so simpler before… • Modern requirements • Token based security
  7. 7. Agenda - Part 2 • SAML 2 / Federation • JWT (JSON Web Token) • OAuth 2 & OpenID Connect
  8. 8. Agenda - Part 3 • How to make your life simpler • Identity Brokering • Externalising security • Out of the box solution
  9. 9. So lets start
  10. 10. In the old days… … all used to be simple ;)
  11. 11. Server Side Apps
  12. 12. Form based security Cancel Login Username Password Hash / Compare
  13. 13. Old Architecture • Usually server side • Passwords • Simple session management • Invalidate to logout • Cookies
  14. 14. Not anymore…
  15. 15. Passwords • Not easy to store and validate • Hard to enforce using strong and unique ones • Problematic to pass around in safe manner
  16. 16. New credential types • Not always easy to adapt application to support them
  17. 17. Session Management • Simple for server side applications • Complex for mobile and HTML5 applications
  18. 18. External Users • Other Companies • Our partners or customers • No access to their database • Social Networks
  19. 19. Single Sign On
  20. 20. Single Sign Out Invalidate all your sessions in one place
  21. 21. Mobile Devices • Using app for 10 min every 2 months … and remain logged in! • Authentication within application • Safe storage of credentials • Cut of access when device is lost
  22. 22. OWASP The Open Web Application Security Project
  23. 23. OWASP 
 Top 10 Most Critical Application Security Risks
  24. 24. #2 in 2013
  25. 25. Broken Session and Authentication Management
  26. 26. Tokens
  27. 27. Tokens / Tickets / Assertions
  28. 28. What is a token? • (XML / JSON / Whatever) document with some payload • Information about user • Name, organisation, roles, authentication method, timestamp, lifespan, etc. • Can be signed
  29. 29. Tokens are signed • Ensure they were not tampered • No one altered them in the meantime • Trust them without additional check with issuer. • Now communication overhead
  30. 30. Why Tokens? • Decoupling authentication / authorization • Not relying on specific method • Mobile / Server Side and Client Side apps will authenticate differently. • How this info is passed around
  31. 31. Flexible You can decide what they contain
  32. 32. Why Tokens? • Contain any additional information needed • Can have defined lifetime • Can be invalidated or managed in central manner
  33. 33. Ok but still… why tokens help?
  34. 34. Delegation of authentication to dedicated and trusted server / provider
  35. 35. Providing credentials to only one selected entity
  36. 36. Cancel Login Username Password
  37. 37. Cancel Login Username Password
  38. 38. Typical Components
  39. 39. Identity Provider / Authorization Server • Stores user data and credentials • Performing authentication • Issuing, verifying and revoking tokens
  40. 40. Service Provider / Resource / Resource Server • Exposing data or operations to be accessed by: • user • application on behalf of the user
  41. 41. User / Client / Relying Party • User (e.g. via Browser) • Applications acting on behalf of the user 
 (e.g. Mobile App) • Backend Service or App (e.g. Microservices)
  42. 42. In practice?
  43. 43. ACME
  44. 44. ACME Token
  45. 45. ACME Token Here you authenticate (providing credential). Within company firewall/VPN Cancel Login Username Password
  46. 46. ACME Token Here you authenticate (providing credentials). Within company firewall/VPN Here you get access (no credentials) Cancel Login Username Password
  47. 47. ACME Token Here you authenticate (providing credential). Within company firewall/VPN Here you get access (no credentials) ACME remains in control of shared user information Cancel Login Username Password
  48. 48. Web SSO
 (Single Sign On)
  49. 49. Federation
  50. 50. SAML 2
  51. 51. SAML 2 • OASIS Standard • Version 1.0 in 2001 • Version 2.0 in 2005
  52. 52. SAML 2 Facts • XML token - verbose and heavy • Complex flows, lot of different profiles • Very mature and widely adopted • Many binding types - SOAP for e.g. • High learning curve • Doesn’t fit mobile use cases well.
  53. 53. SAML 2 - Federation • Authentication and authorization between organisations • Not sharing access or ownership to user data • Trusting external Identity Provider
  54. 54. SAML2 is very widely adopted de facto standard
  55. 55. What is the issue with SAML2 and mobile?
  56. 56. POST vs GET
  57. 57. There are ways to workaround it… … still it always remains a workaround…
  58. 58. Newcomers…
  59. 59. OAuth2 & OpenID Connect
  60. 60. Modern security needs • Client Side Apps (HTML 5 / JS / Stateless) • Mobile Apps • (Micro)Services / APIs
  61. 61. First of all..
  62. 62. Tokens! :)
  63. 63. Token standards • Kerberos • SAML 2 • JWT (JSON Web Token)
  64. 64. JSON Web Token
  65. 65. JOSE • JSON Object Signing and Encryption • Set of IETF open standards (RFCs) • JWT - JSON Web Token • JWS - JSON Web Signature • JWE - JSON Web Encryption • JWA - JSON Web Algorithms • JWK - JSON Web Key
  66. 66. JWT (JSON Web Token) • JSON Document • Key [String] : Value [JSON] • Wide choice of signing algorithms
  67. 67. Anatomy • Simple JSON, Encoded in Base64 • Three parts • Header • Payload • Signature
  68. 68. { "alg": "HS256", "typ": "JWT" } { "iss": "joe", "exp": 1300819380, "human": true, "over 18": true } eyJhbGciOiJIUzI1Ni IsInR5cCI6IkpXVCJ 9.eyJpc3MiOiJqb2U iLCJleHAiOjEzMDA 4MTkzODAsImh1b WFuIjp0cnVlLCJvd mVyIDE4Ijp0cnVlfQ. 0LtIxMRXW0VItgVq hQGUJCEjzWpnXpt QOWxn9wGDyW4 Header in Base64: eyJhbGciOiJIUzI1NiI sInR5cCI6IkpXVCJ9 Payload in Base64: eyJpc3MiOiJqb2UiLCJleHAiOjE zMDA4MTkzODAsImh1bWFuIjp 0cnVlLCJvdmVyIDE4Ijp0cnVlfQ Header Payload JSON Web Token
  69. 69. <header-base64>.
 <payload-base64>.
 <signature-base64>
  70. 70. All you need to know! ;)
  71. 71. OAuth2
  72. 72. Who knows or used OAuth2?
  73. 73. Everyone ;)
  74. 74. source: aaronparecki.com
  75. 75. OAuth2 - Some facts • Many major companies behind it • Google, Facebook, Twitter and etc. • 2.0 incompatible with 1.x • Becoming de facto standard security framework for • Mobile Apps • Client Side • APIs / Services
  76. 76. Major usecase?
  77. 77. NOT for authentication
 …
  78. 78. NOT for authorization …
  79. 79. DELEGATION protocol
  80. 80. Applications & Services acting on behalf of the user
  81. 81. OAuth2 Actors • Resource owner - YOU! :) • Client - application acting on your behalf • Resource / Resource Server - APIs accessed by Client • Authorization Server - Place where you authenticate and where tokens are being issued
  82. 82. Authorization flows • Authorization Code - Server Side Application • Implicit - Client Side and Mobile Apps • Resource Owner - Directly using username / password • Client Credentials - For app related operations - app identity
  83. 83. Authorization Code Flow Server Side Applications
  84. 84. Authorization Server Resource Server ClientResource Owner
  85. 85. Authorization Server Resource Server Resource Owner Client ID Client
  86. 86. Authorization Server Resource Server Resource Owner Authorization
 Code Client
  87. 87. Authorization Server Resource Server Resource Owner Authorization Code Client ID Client Secret Client
  88. 88. Authorization Server Resource Server Resource Owner Refresh Token Access Token Client
  89. 89. Authorization Server Resource Server Resource Owner Access Token Client
  90. 90. Implicit Client Side & Mobile
  91. 91. Authorization Server Resource Server Client
  92. 92. Authorization Server Resource Server Client Access Token
  93. 93. Authorization Server Resource Server Client Access Token
  94. 94. OAuth2 - Scopes • During authorization user grants application access with given scope • e.g. Basic profile info only (full name & email) • e.g. Information about all your social graph (friends on FB) • e.g. Write access to FB wall
  95. 95. OAuth2 - Token Types • By Value • By Reference • Pointer to information • Way to not send data outside of your network • You could have Reverse Proxy translating those in front of your APIs.
  96. 96. OAuth2 - Summary • Is pretty generic • Doesn’t define specific token standard • Lacks on authentication and user info side • Many consider it more “a protocol framework” then protocol itself.
  97. 97. Scales and adapts nicely Just teach your (micro)Service to understand JWT!
  98. 98. Cancel Login Username Password
  99. 99. OpenID Connect
  100. 100. OpenID Connect • Builds on top of OAuth2 • Adds two new flows • Adds session management - • e.g. Single Sign On & Out for HTML5 apps • ID token • User info endpoint • Discovery & Clients self registration
  101. 101. Getting widely adopted…
  102. 102. OpenID Connect is what you should consider For any new modern application
  103. 103. But… How do I deal with all the legacy?
  104. 104. What is the easiest way to approach it?
  105. 105. Shameless Plug!
  106. 106. Keycloak Project Open Source Identity and Access Management Solution
  107. 107. Same concepts apply to other available solutions
  108. 108. Identity Brokering
  109. 109. Here is your Legacy
  110. 110. Here is your Legacy Here is your modern stuff
  111. 111. Will handle legacy infra integration for you !!!
  112. 112. Externalise Security
  113. 113. Integrate with OOTB Identity Solution
  114. 114. Remember OWASP?
  115. 115. Security is hard Don’t reinvent (or reimplement) things yourself…
  116. 116. How does it work?
  117. 117. <button onclick=“keycloak.login()”> Login </button>
  118. 118. OOTB Client Adapters • JBoss EAP & WildFly • JBoss Fuse • JBoss BxMS • JavaScript • NodeJS • Mobile (Cordova / Native) • Spring • Tomcat / Jetty • … custom …
  119. 119. What do you get?
  120. 120. Want to make it look like part of your application?
  121. 121. Sure!
  122. 122. My users need to accept “Terms & Conditions” page during auth…
  123. 123. User Self Management?
  124. 124. Let them setup OTP?
  125. 125. And much more… … of stuff you don’t need to implement yourself
  126. 126. Some (of many) features • Session management • Identity Management (with UI screens) • Security Defences • Password policies • User impersonation • ….
  127. 127. Lot of things you could implement badly… and in insecure way
  128. 128. What remains for you? • Configure client adapter • Get (more) information from the token • Call REST endpoints • Obtain additional information • Perform additional operations
  129. 129. Summary
  130. 130. Rely on existing standards OAuth2 and OpenID Connect likely will fit all of your needs
  131. 131. Use existing frameworks, libraries and OOTB solutions Will speed you up, help integrating with legacy infrastructure and shelter from mistakes…
  132. 132. Don’t try to (re)invent things yourself In security area this is most likely very bad idea…
  133. 133. Hope This Helps
  134. 134. Thank You! Questions?

×