Recomendados
Mais conteúdo relacionado
Semelhante a Jacob has a horse, says Travis
Semelhante a Jacob has a horse, says Travis (13)
Último
Último (20)
Jacob has a horse, says Travis
- 1. Jacob Has a Horse, says Travis a tale of truths in a microservice architecture
- 2. Who Am I?
- 3. Who Am I, attributes? Name: Jacob Age: 38 Length: 177cm Family-role: Father Son: Bertil Weather: Sunny Location: Some Café
- 4. Me, using a service Name: Jacob Age: 38 Length: 177 Shirt size: 48 Location: Home Weather: Rainy StoreAccount: 123-XYZ Clothing Store /buy
- 5. Part 1: The API Security Maturity Model
- 6. API Security Maturity Model API Keys and Basic Authentication
- 7. Example Name: Jacob Age: 38 Length: 177 Shirt size: 48 Location: Home Weather: Rainy StoreAccount: 123-XYZ Clothing Store /buy
- 9. Example Clothing Store Web /buy /inventory /purchase Authorization: Basic YWRtaW46UGFzc3dvcmQx Authorization: Basic YWRtaW46UGFzc3dvcmQx
- 10. Example Clothing Store Web /buy /inventory /purchase Authorization: Basic YWRtaW46UGFzc3dvcmQx { user: 123-XYZ } Authorization: Basic YWRtaW46UGFzc3dvcmQx { user: 123-XYZ }
- 11. The problem with API Keys and Basic Auth • Machine verification(ish) • User isn’t bound to the requested resource • Authentication only, no Authorization
- 12. API Security Maturity Model API Keys and Basic Authentication Token based Authentication
- 14. Example: The publisher Inside organization Web Content The Internet
- 15. Example: The publisher Inside organization Web Content The Internet Authorization: Bearer AT Authorization: Bearer AT Authorization: Bearer AT
- 16. The problem • Access Tokens only used for authentication • Authorization is not performed • Machine access to the same API • Result: Anyone who could obtain a token can update the content API.
- 17. API Security Maturity Model API Keys and Basic Authentication Token based Authentication Token based Authorization
- 18. Scopes • Named “permissions” in a token • Strings • Does not contain any values • Requested by the client • Authorized by the user and the OAuth server
- 19. Scopes Example • content_read • content_write • email • address • invoice_list Content Invoices Users
- 20. Example: The Swish app Image Copyright Getswish AB
- 21. Example: The Swish app Image Copyright Getswish AB BankID (eID) Swish
- 22. Example: The Swish app Image Copyright Getswish AB BankID (eID) Swish
- 23. Example: The Swish app Image Copyright Getswish AB BankID (eID) Swish /payment-history/<phone-number>/ALL
- 25. Passing information around PhoneNumber = 123213
- 26. Passing information around PhoneNumber = 123213
- 27. What could go wrong? • What can happen when an API calls another API? • Who trust’s who? • Information gets added along the way
- 28. Spaghetti Photo by Immo Wegmann on Unsplash
- 29. API Security Maturity Model API Keys and Basic Authentication Token based Authentication Token based Authorization Centralized trust using Claims
- 30. Part 2: Claims – the missing piece
- 31. Who do we trust? • The caller? • The API Gateway? • The issuer of the tokens? • The user database?
- 32. Trust Trust is a subjective assessment of another’s influence in terms of the extent of one’s perception about the quality and significance of another’s impact over one’s outcomes in a given situation, such that one’s expectation of, openness to, and inclination toward such influence provide a sense of control over the potential outcomes of the situation. Romano D.M. (2003). "The Nature of Trust: Conceptual and Operational Clarification". Louisiana State University, PhD Thesis.
- 33. Trust, in other words • Trust is subjective • It does not guarantee absolute truth • It helps us predict the correctness of a decision
- 34. Participants in Trust The issuer / authority The relying partyThe requesting party
- 35. Who Am I, attributes? Name: Jacob Age: 38 Length: 177cm Family-role: Father Son: Bertil Weather: Sunny Location: Some Café
- 36. Who Am I, Context attributes?Weather: Sunny Location: Some Café CONTEXT ATTRIBUTES
- 37. Who am I, subject attributes Name: Jacob Age: 38 Length: 177cm Family-role: Father Son: Bertil SUBJECT ATTRIBUTES
- 39. Attribute: firstName = Jacob age = 38 Trust Claims, not attributes
- 40. Claim: Skatteverket says: the firstName of this person is Jacob Jacob is 38, says Polisen Jacob has a son, says Skatteverket Trust Claims, not attributes
- 41. The anatomy of a claim Jacob is 177cm tall, says Polisen Subject Attribute Asserting party
- 42. How can we trust the data • Always verify all incoming data against the original source • Trust an common party to provide the data
- 43. Using claims The issuer / authority The relying partyThe requesting party
- 44. Using claims The issuer / authority The relying partyThe requesting party
- 45. Verifying claims The issuer / authority The relying partyThe requesting party OK
- 46. Verifying claims The issuer / authority The relying partyThe requesting party Verify signature
- 47. Hey, I can use a JWT eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJqY W5lZG9lQGV4YW1wbGUuY29tIiwibmFtZSI6IkphbmUgR G9lIiwiaWF0IjoxNTQ2MzAwODAwLCJleHAiOjE4OTM0N TYwMDB9.XcNkubx0GNwbOohJGVAUVxl187oYSR0ecFz 0wvHvksOsOW9m6z3WyW4- Q_yZUMuJaq_WZCX0y8EIUj9bur7aVfSONKv2uS_m7Cn h_GlAAXFRkLZk9cBg3Xrv8mF2rcmZMy_0l5RdRDzF48H 35agZoImUR8sfPU- S7ypgSmNX0j3nlLJLZNqjjF2XkFr54rNsXYFBQZUunzBgV moeqfWRKcSB- HJOrSWEiKL8JLMp8qgS0x4h5YRVtNiJ5o7I3KDYVGG4bw ExFFPwHakseTdjkRJOGcUu1P5- 8DoLnsp1JLYbpfGLC3ebO1rRLQYuDDkqEmqzrMXTyXXT 8Lg8I2IkBw { sub: janedoe@example.com name: Jane Doe iat: 1546300800 exp: 1893456000 iss: https://login.curity.io subscriber_id: ABC_123 }
- 48. A JWT has Claims { sub: janedoe@example.com name: Jane Doe iat: 1546300800 exp: 1893456000 iss: https://login.curity.io subscriber_id: ABC_123 } These are claims!
- 49. A JWT has Claims { sub: janedoe@example.com name: Jane Doe iat: 1546300800 exp: 1893456000 iss: https://login.curity.io subscriber_id: ABC_123 } There’s a subject
- 50. A JWT has Claims { sub: janedoe@example.com name: Jane Doe iat: 1546300800 exp: 1893456000 iss: https://login.curity.io subscriber_id: ABC_123 } Issued by
- 51. Using the JWT The issuer / authority The relying partyThe requesting party Verify signature JWT
- 52. A JWT is not a protocol!
- 53. Traffic Photo by Denys Nevozhai on Unsplash
- 55. Using Claims
- 56. Using Claims
- 57. Using Claims { sub: janedoe@example.com name: Jane Doe iat: 1546300800 exp: 1893456000 iss: https://login.curity.io subscriber_id: ABC_123 phone_number: +46 123 123 123 }
- 58. Using Claims
- 60. Claim data • Organize sensitive data to be reachable only by the OIDC server • Include identity specific data in the token • Use Opaque tokens on the internet and JWTs internally • Only add data when the client needs it!
- 61. How to identify data to put in the token • It should be relevant to a large set of your APIs • It should not be application specific • It should be attributes of the user • It should not be contextual for the session
- 62. Summary: Trust few sources
- 63. Summary: No spaghetti Photo by Eiliv-Sonas Aceron on Unsplash
- 64. Summary: Attributes are not claims age: 34 firstName: Jane lastName: Doe email: jane@example.com carVIN: 123123123123
- 65. Summary: Claims are easy • The car is yellow, Jacob says. • Travis phone number is 123 123 123, says his wife
- 66. Jacob has a horse, says Travis
Notas do Editor
- I’m going to talk about something important today. But in order to get there, we need to take a step back and look at what the security model looks like today. Part 1. The API Security Maturity Model So bear with me, when we first dive into some examples, to build up the model that we can dive into later in part 2
- I can present myself in many ways. If I use this photo as a basis, we could add some basic info that makes sense.
- One example is when I buy clothes. The store doesn’t really care if I’m actually 38 years old, or if my shirt size is 48. They don’t call the police to check that I’m really who I say I am. As long as I pay… Context? – where to ship to? So, I guess there’s no issue here… We’re getting ahead of ourselves a bit!
- Lets leave that example for a bit now and lets take a historic look at where we stand I’ve defined a model for how we can categorize the maturity of API Security The basic level is where you protect your API using only APIKeys and Basic Authentication. Essentially this means that you are protecting the API itself from being called from unauthorized clients, but you are not protecting the API from incorrect usage or malicious usage
- Token based Authorization = Scopes
- The API is protected with system credentials Network security policies Not reachable from the outside
- Token based Authorization = Scopes
- Lets side track slightly. Some of you who have worked with OAuth before probably know this.
- Lets side track slightly. Some of you who have worked with OAuth before probably know this.
- They used certificate pinning to lock down the caller of the API. However you can decompile the app to retrieve the certificate Then endpoint then was used to retrieve the payment history The call was authenticated, but not authorized properly It was possible to replace the phonenumber and retrieve the payment history of anyone with an account at swish
- To add complexity to the problem, we should remember that we pass a lot of information around. It’s rarely one system involved when building complex services. Give a few examples. Simple to more complex
- To add complexity to the problem, we should remember that we pass a lot of information around. It’s rarely one system involved when building complex services. Give a few examples. Simple to more complex
- Spaghetti of trust In swish, the API trusted the App to provide the correct phone number.
- Token based Authorization = Scopes
- We don’t trust the gateway (particularly) Give examples of where we trust the wrong part? Aftonbladet. Bank example of altered account number. Who can modify the input?
- What is trust? We use it all the time. HTTPS.
- Subjective = we can define what we trust in our own systems
- The issuer The enforcing party The relying party The information sources Trust is subjective, we must create our own limitations and boundaries to make trust mean something https://en.wikipedia.org/wiki/Computational_trust
- I can present myself in many ways. If I use this photo as a basis, we could add some basic info that makes sense.
- How do you know this is my son?
- Two authorities can assert my attributes: The police who issue passports, which includes my name, length and age The tax authority who knows where I live, and that my son is my son. But I don’t always need to prove who I am to the depth of these authorities.
- 1 . This would make it pretty pointless to pass data at all since verifying it all the time is cumbersome Usually there are more than one source of data, so more knowledge about where data came from is needed. 2. Trust a common party with the most important data. Two common methods: Ask someone we trust to give it when we need it. How do they know we entitled to get the data? * Sign it.
- The issuer The enforcing party The relying party The information sources Trust is subjective, we must create our own limitations and boundaries to make trust mean something https://en.wikipedia.org/wiki/Computational_trust
- The issuer The enforcing party The relying party The information sources Trust is subjective, we must create our own limitations and boundaries to make trust mean something https://en.wikipedia.org/wiki/Computational_trust
- It’s not the cars that make it safe to drive. It’s the rules
- Information sources Limit who can obtain data from valuable sources Here’s the kicker : Only include the data that you know the client will need. A good OIDC/OAuth server will allow you to do this