Lean and Mean – Authorization for kick-ass APIs (Jonas Markström)
•Download as PPTX, PDF•
1 like•354 views
This is a session given by Jonas Markström at Nordic APIs 2016 Platform Summit on October 26th, in Stockholm Sweden. Description: So you’ve decided to go down the API path. You’re fitting your enterprise’s architecture with the best in REST services, micro services, and API gateways. You’ve convinced your management that opening up your most precious assets – your data – to the outside world will have considerable benefits. Just imagine: your partners, customers, and contractors will all be able to interact with your systems. Now, of course, there is just this little nagging doubt in your head: did you code that service correctly? Are you positive only the right people have access to the relevant data? Did you thoroughly test that 10,000-line code that implements access control? Of course you didn’t… Because you didn’t hard-code the authorization. You went for Attribute Based Access Control, the weapon of choice of API Ninjas. Right? In this talk, we will cover the basics of externalizing authorization using ABAC and how it can be applied to your APIs: – Secure API endpoints no matter the technology – Control access to API functionality – Control access to data: dynamic data masking – Implement access control as centrally-managed policies – Reuse the access control across other technologies in the stack. Benefits include: – Leaner APIs – Slashed development time – Faster time-to-market
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Lean and Mean – Authorization for kick-ass APIs (Jonas Markström)
Similar to Lean and Mean – Authorization for kick-ass APIs (Jonas Markström) (20)
More from Nordic APIs
More from Nordic APIs (20)
Recently uploaded
Recently uploaded (20)
Lean and Mean – Authorization for kick-ass APIs (Jonas Markström)
- 1. Lean & Mean - Authorization for kick-ass APIs Jonas Markström API Security Ninja
- 2. © Axiomatics 2016 2 Feeling lonely?
- 3. © Axiomatics 2016 3 Not one but many monoliths
- 4. © Axiomatics 2016 4 Time to rethink the plumbing…
- 5. © Axiomatics 2016 5
- 6. © Axiomatics 2016 6
- 7. © Axiomatics 2016 7 Feeling pretty happy?
- 8. © Axiomatics 2016 8 A single entry into the kingdom
- 9. © Axiomatics 2016 9 Open up to business
- 10. © Axiomatics 2016 10 Before & After ⁃ From the monolith to... ⁃ The decoupled approach Acme Enterprise Firewall Web Container Processes Data Acme Enterprise Firewall Web Container Processes Data API API API Gateway Third Party API
- 11. © Axiomatics 2016 11 Is your access control broken?
- 12. © Axiomatics 2016 12 Who gets to decide?
- 13. © Axiomatics 2016 13 Who gets to decide? User API I, Alice, want to view bank accounts Can Alice view account #123? Data
- 14. © Axiomatics 2016 14 The Guardian Angel
- 15. © Axiomatics 2016 15 Authorization as Infrastructure User API I, Alice, want to view bank accounts Can Alice view account #123? Data APIGateway ABAC Authorization Service SQLProxy Which data can be retrieved?
- 16. © Axiomatics 2016 16 Did you say ABAC? Externalized Centralized Policy Driven Attribute Based Standardized
- 17. © Axiomatics 2016 17 Attributes are labels that describe anyone and anything
- 18. © Axiomatics 2016 18 Attributes are Multi-Dimensional Who What Where When Why How
- 19. © Axiomatics 2016 19 Policies bring attributes together to make it all work
- 20. © Axiomatics 2016 20 “Managers can view accounts in their region” “Customers can create transfers up to $1,000” “A user cannot approve a transfer they requested” “Tellers can view transactions in their own region”
- 21. © Axiomatics 2016 21 Policies that apply to a specific API or service Policies that apply across the enterprise / API sets Policies can be local or global
- 22. © Axiomatics 2016 22 Use ABAC to implement... Time-based policies “Deny access to the API outside office hours”
- 23. © Axiomatics 2016 23 Use ABAC to implement... Location-based policies “Dutch Employees cannot view Singapore client data”
- 24. © Axiomatics 2016 24 Use ABAC to implement... Dynamic access control “Managers can view accounts that are in the same branch.”
- 25. © Axiomatics 2016 25 Use ABAC to implement... Dynamic Segregation of Duty “Employees cannot approve transactions they initiate.”
- 26. © Axiomatics 2016 26 Secure APIs start with ABAC... Any API Any Policy Any Attribute
Editor's Notes
- The IT landscape is big, vast, ever-expanding -much like the universe. The number of applications is growing fast like stars and like planets. There is no stopping to the business’ hunger for: better processes, new and better apps, and more data… So many business analysts and stakeholders… One architect, you…
- Historically each and every app exists independently one of another. Information is exchanged record by record manually in a process that is: tedious lengthy and error-prone We are in the late nineties and IT is painful and it is preventing the business from connecting the dots… (its not business friendly, it doesn’t enable the business)
- Three letters: E… A… I… Enterprise Application Integration: integration framework comprised of a collection of technologies and services forming a middleware or "middleware framework“, to enable integration of systems and applications across the enterprise. Integrate applications together, exchange data, extend business processes.
- and you integrate within the enterprise and even beyond the enterprise boundaries. You invite your customers, partners, contractors - agents, legal bodies –you invite them all to the party. And you share the processes & you share the data.
- EAI morphed into SOA or Service-Oriented Architecture. And SOA brought about a plethora of standards and tools to implement EAI/SOA. Such standards include SOAP, WS-*, SAML, and so on. XML was the new kid on the block and it was cool.
- Yes, SOAP was liberating (and, huh, clean). Large companies, they started building SOA strategies driven by SOAP and WS-*. It was relatively successful. But progress was slow and integration difficult. The promise of interoperability wasn’t fulfilled. The .NET stack struggled to talk to other stacks e.g. Java. Different protocols emerged and competed e.g. WS-Eventing and WS-Notification. XML processing was heavier than previously thought. Authentication and trust establishment was a cryptic nightmare. So is that little boy laughing because it was a piece of cake or because it was still painful?
- To have this happen, a new breed of products emerged some ten years ago: XML gateways. The heavy-weight champions of security. The likes of IBM’s Datapower. XML fortresses in a sense. Masters of SAML and WS-Security. Yeah, a great step forward but still not that agile. We needed something more lightweight, easier to use. More dedicated. Not an all-in-one Swiss Army knife.
- Banks. Banks are among the ones that want to open up. From a legacy system where a single web portal would get access to internal data & processes, banks are now moving to an API-first design where small APIs, micro-service-style! This can enable simple customer-facing mobile applications or can be means for a partner or another vendor to access (and therefore buy) bank data. This helps banks get more buck for their data. And actually, banks don’t just do it for the money. In Europe they will also have to start complying with consumer-enabling legislation. APIs will be great cornerstone of a long-lasting strategy.
- Now that you expose more data. More openly, you need to really think about security, and about access control in particular. Do you bake the access control inside the API itself? If so, then how do you make sure your API is secure but also future-proof: flexible enough to adapt to future needs? How do you make sure your API complies with national and international regulations? The regulations of today and those of tomorrow. Yes, these are rethorical questions ;)
- So one of the main challenges when building APIs, business layers, applications, and data stores is that it is unclear where authorization decisions should be made and by whom. Should developers implement the logic? If so, where? As SQL statements? As logic inside a business process? Inside the application’s logic itself? Or within the API? What if we have different ways of consuming the same data sets? Does this require implementing different logic in different places? And how do I get a good overview of what is allowed, what isn’t? How do I prove I am compliant?
- Let’s look at a flow. Imagine a user Alice on the left-hand side trying to access data via an API on the right-hand side. Who gets to decide whether the call should be allowed? The API can handle authentication and basic authorization e.g. OAuth scopes. But what about finer-grained authorization? Who does the data belong to?
- Oh look, it’s the guardian angel! We’ve heard many names for that component. And yes we’ve even heard Guardian Angel. This is the component you query in order to get a decision, an authorization decision. Can I do this? Yes, you can. No you cannot! The Guardian Angel is the one central point of decision making you go to in the enterprise. It is the same central point no matter the layer you are in, no matter the technology. It knows it all.
- ABAC or Attribute-Based Access Control is the new authorization model flexible enough to secure your APIs, applications, and data stores all in one go, from one central place, in a consistent manner. ABAC is also a NIST-backed initiative as well as a standard. XACML is the standard implementation for ABAC
- Attributes are key-value pairs. They can be used to describe anything and anyone. Attributes can be multi-valued. For instance citizenship = ‘Swedish’ and ‘Norwegian’. Attributes can be typed. An attribute could be a string, a number, a boolean, or a date.
- Attributes can relate to who, what, where, when, why, and how. Attributes cover all the grammatical functions of a sentence: the subject (who), the verb (what action), the object (what resource), and the contextual information (why, how, when, where…) Attributes can be sourced from multiple locations: databases, other APIs, the API message itself, authentication tokens (SAML, JWT…)
- Attributes alone though are not enough. We need something to bring the attributes all together. We need a bit of chemistry. If we try do an analogy, then: Policies are like the natural language Attributes are like the vocabulary Use policies to bind attributes together to create the authorization spark. Use policies to combine attributes and determine whether access should be granted or denied.
- Examples
- Policies can grant access… and deny access
- Dynamic access control that is applied on the fly based on the context of the interaction. Location and time as previously seen but also relationship: does the user own the data? Have a relationship to the data?
- Dynamic access control that is applied on the fly based on the context of the interaction. Location and time as previously seen but also relationship: does the user own the data? Have a relationship to the data?