O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

2019 | Policy-Enabling Your Services | Identiverse | Day 1, June 25

61 visualizações

Publicada em

APIs have become the backbone of many services nowadays - from the weather forecast to delivery notifications and photo printing services. Not only can we consume data and services more readily through those APIs but we can also mash them up into greater services. To do so, we tackled API security through OAuth and OpenID Connect. They form a good basis to handle authentication and basic authorization delegation, but there is so much more to consider from an authorization perspective. This session will discuss how security concerns can be addressed through policy-driven authorization in a way that meets the needs and expectations of application developers, owners, and auditors alike. We will show how complex access policies can be handled through a dedicated authorization microservice. With this approach, you can automate security deployment changes within the same CI/CD pipelines used for application management. Furthermore, new deployment configurations are possible, such as implementing the authorization service as a sidecar, to meet advanced performance and scale requirements. All this without changing a single line of code.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

2019 | Policy-Enabling Your Services | Identiverse | Day 1, June 25

  1. 1. ® POLICY-ENABLING YOUR SERVICES USING ELASTIC DYNAMIC AUTHORIZATION TO CONTROL ACCESS TO YOUR APIS, MICROSERVICES, AND DATA. GERRY GEBEL & DAVID BROSSARD
  2. 2. ® API Growth
  3. 3. ® A brief history of APIs Enterprise Service Bus CORBA COM/DCOM XML, WS-*, SOAP XML Gateways (Datapower…) REST API Gateways (Apigee…) API Management OAuth gRPC Service meshes (Istio) Orchestration (Kubernetes) Micro-gateways (42crunch, Ambassador…) Enterprise Application Integration Service Oriented Architecture API Micro services
  4. 4. ® Authorization for APIs Enterprise Application Integration Service Oriented Architecture API Micro services Home-grown Home-grown SAML XACML Home-grown SAML XACML OAuth 2.0 Home-grown SAML XACML OAuth 2.0 Framework-specific* *CanCan, Laravel, Keycloak, Claims-based… Framework-specific* ALFA OPA
  5. 5. ® Comparing Authorization Approaches Home- grown SAML OAuth 2.0 XACML ALFA OPA Description Code inside the applications Open standard for exchanging authentication and authorization data between parties OAuth 2.0 is the industry-standard protocol for authorization. Open standard which defines a declarative fine- grained, attribute- based access control policy language Open lightweight policy-based standard for attribute-based access control open source, general-purpose policy engine that enables unified, context-aware policy enforcement Policy- based No No No Yes Yes Yes RBAC Yes Yes Yes Yes Yes Yes ABAC Possibly No No Yes Yes Yes Reusable No Yes Yes Yes Yes Yes Applicable to multiple layers No No No Yes Yes No
  6. 6. ® what OAuth 2.0 is to SAML ALFA is to XACML…
  7. 7. ® The problem with tokens? Token bloat, role-based, no relationship, opaque
  8. 8. ® Token bloat We create too many assertions / scopes that end up being stored inside the identity token thus bloating it
  9. 9. ® Frankenscope When scopes blow up
  10. 10. ® Identity-centric All about roles and permissions – no room for relationships or additional attributes
  11. 11. ® The solution? Policy Enablement
  12. 12. ® The Ten Commandments of Authorization 1. Authorization shall be declarative  policy-based 2. Authorization shall be dynamic  runtime decision-making 3. Authorization shall use identity, action, & resource attributes 4. Authorization shall be decoupled from the application & data 5. Authorization shall be able to use relationships 6. Authorization shall be business-driven  all in it together 7. Authorization shall be transparent  easy to edit & audit 8. Authorization shall be scalable  protect one, protect all 9. Authorization shall be technology agnostic  APIs, data, & more 10. Authorization shall be future-proof  don’t make assumptions about tomorrow
  13. 13. ® Authorization for APIs & Data Interceptor Interceptor Transactional authorization Data-centric authorization Policy (ALFA)
  14. 14. ® ALFA – the Abbreviated Language for Authorization • OASIS Draft Standard (2015) • Lightweight JSON-like syntax for declarative attribute-based policies • Compatible with XACML & many other policy-based architectures • Fits into the CI/CD development cycle • Authorization-as-ALFA-code
  15. 15. ® Choose the right enforcement • APIs & Microservices • API gateways • Micro-gateways • Enforce on the way in… and out • Data stores • SQL proxies • Elasticsearch filters • Other? OData?
  16. 16. ® Choose the right decision engine • Central authorization engine, sidecar, or distributed • Central control pane • Stateless authorization engine  you can scale horizontally
  17. 17. ® Demo Authorization Applied to an API
  18. 18. ® A demo • This demo uses Apigee API Gateway • The gateway calls out to an Axiomatics Cloud Policy Decision Point • In the demo we authorize on the way in… and out • Dan wants to view record 131 • Owner and status is redacted • The original record
  19. 19. ® Demo Policy (ALFA) /*R1 - A manager can view any records */ rule manager{ target clause user.role == "manager" clause action_id == "GET" or action_id == "view" permit } /*R2 - An employee can view a record in their own department */ rule employeeView{ target clause user.role == "employee" clause action_id == "view" or action_id == "GET" condition record.department == user.department permit }
  20. 20. ® Demo Policy – Masking /*R2.1 - An client can view a record in their own department with obligation to mask owner and status*/ rule clientView{ target clause user.role == "client" clause action_id == "view" or action_id == "GET" condition record.department == user.department permit on permit{ obligation fields { mask_fields = "owner" mask_fields = "status" } } }
  21. 21. 21 ® Questions? @davidjbrossard |@ggebel

×