Securing FIWARE Architectures
0 likes18 views
The document provides an overview of identity management and access control within FIWARE architectures, detailing components such as Keyrock for identity management, Wilma as a PEP proxy, and Authzforce for policy-based access control. It explains key concepts like authentication, authorization, and common OAuth2 flows, highlighting the roles and interactions of these components in securing applications and APIs. The document also covers advanced topics like role-based and policy-based access control, as well as integration with European eID services.
Securing FIWARE Architectures
- 1. Securing FIWARE Architectures Jason Fox, Senior Technical Evangelist FIWARE Foundation
- 2. Learning Goals What are Identity Management and Access Control? Which FIWARE components will you need? What are Authentication and Authorization? How do they differ? What is OAuth2? What flows are supported? What is a PEP Proxy? What does it do? What is a PDP and when will I need one? What terms such as RBAC, PBAC and XACML mean and how are they used? 1
- 3. FIWARE Catalogue 2 2 Data/API Management Publication Monetization Core Context Management (Context Broker) Context Processing, Analysis, Visualization Interface to IoT, Robotics and third party systems Deployment tools 2 Development of Context-aware applications (Orion, STH-Comet, Cygnus, QuantumLeap, Draco) Connection to the Internet of Things (IDAS, OpenMTC) Real-time processing of context events (Perseo) Handling authorization and access control to APIs (Keyrock, Wilma, AuthZForce, APInf ) Publication and Monetization of Context Information (CKAN extensions, Data/API Biz Framework, IDRA) Creation of Application Dashboards (Wirecloud) Real-time Processing of media streams (Kurento) Business Intelligence (Knowage) Connection to robots (Fast RTPS,Micro XRCE-DDS) Big Data Context Analysis (Cosmos) Cloud Edge (FogFlow) Documents exchange (Domibus)
- 4. IAM Generic Enablers Identity & Access Control Management 3 ● Keyrock – Identity Management ● Wilma – PEP Proxy ● AuthZForce – Authorization PDP
- 5. Keyrock Main features 4 Web Interface and Rest API for managing Identity ● Users, devices and groups management ● OAuth 2.0 - based Single Sign On ● Application - scoped roles and permissions management ● Support for local and remote PAP/PDP ● JSON Web Tokens (JWT) and Permanent Tokens support ● MySQL / PostgreSQL and external DB driver ● European eID authentication compatibility (CEF eIDAS)
- 6. Keyrock : Identity Management 5 ● Application - A securable FIWARE application consisting of a series of microservices ● User - Any human actor interacting with a FIWARE Application ● Organization - A group of users who can be assigned a series of rights. Organization Role - An association allowing certain users to administer all rights ● PEP Proxy - A proxy for use between generic enablers challenging the rights of a user. ● IoT Agent - A proxy between IoT Sensors and the Context Broker ● Role - A descriptive bucket for a set of permissions assignable to either a single user or an organization. ● Permission - An ability to do something on a resource within the system Other Actors RBAC
- 7. Keyrock : Identity Manager 6 ● Offers GUI-based or API-based interaction to administrate users, roles and permissions. ● Allows admins to associate users to roles, roles to applications etc. ● The API is a simple REST API enabling simple CRUD actions via the usual HTTP Verbs ● Simple Policy Decision Point (PDP) also available
- 8. OAuth 2 : Common Grant Types 7 User Credentials Grant ● A User wants to log into an application via a web-app client ● The web-app client is absolutely trusted Authorization Code Grant ● Application doesn’t need to store or use passwords directly ● Just needs to confirm who the user is from a trusted source OAuth 2.0 is the industry-standard protocol for authorization https://oauth.net/2/ several common grant types defined
- 9. OAuth 2 : Common Grant Types 8 Implicit Grant ● Retrieves access token directly ● Simplified form, used by some client side applications Client Credentials Grant ● No user involved ● Used when the application itself, not the user needs access Refresh Token ● Exchange a token for a new one
- 10. 9 PEP Proxy for securing service backends ● Basic and complex AC policies support ● OAuth 2.0 Access Tokens support ● JSON Web Tokens (JWT) support ● Custom PDP configuration ● Integrated with API Management tools o APInf & API Umbrella o Kong Wilma Main features
- 11. Wilma : PEP Proxy 10 ● Offers a Policy Execution Point (PEP) to protect other microservices ● Request must provide X-Auth-Token header signifying who (or what) is making the request. ○ Token is obtained via an OAuth Flow ● PEP Proxy passes information on to a Policy Decision Point (such a Keyrock) to make a permit/deny decision on the request. ● Keyrock PDP adjudicates based on authentication or Role-based Access Control RBAC
- 12. 11 PAP and PDP Server for managing complex AC policies ● XACML-3.0 standard-compliant ● Cloud-ready RESTful ABAC framework with XML optimization ● Multi-tenant REST API for PDP and PAP ● Standards: o OASIS: XACML 3.0 + Profiles (REST, RBAC, Multiple Decision) o ISO: Fast Infoset ● Extensible to attribute providers (PIP), functions, etc. AuthZForce Main features
- 13. Authzforce : Policy-based Access control 12 ● PEP Proxy passes information on to a Policy Decision Point to make a permit/deny decision on the request. ○ Keyrock declines to adjudicate ○ Authzforce used to make final decision ● Authzforce is an XACML Server offering Policy-Based Access control PBAC: ○ Policies written in XML ○ Policies can be complex ○ Policies can be altered on the fly ● Use Authzforce for fine grained access control.
- 14. XACML - Defining Complex Access Policies 13 ● XACML policies are split into a hierarchy: ○ <PolicySet> ■ <Policy> ● <Rule> ● Each <Rule> within a <Policy> is evaluated as to whether it should grant access to a resource ● The overall <Policy> result is defined by the result of all <Rule> elements processed in turn. ● Separate <Policy> results are then evaluated against each other using combining algorithms define which <Policy> wins in case of conflict. A <Rule> element consists of a <Target> and a <Condition>.
- 15. 14 Identity and AC Management OAuth 2.0 flow
- 16. 15 Identity and AC Management Accessing GEs and services OAuth2 flow Request + token Check auth
- 17. 16 Identity and AC Management Accessing GEs and services ● Level 1: Authentication ● Level 2: Basic Authorization ● Level 3: Advanced Authorization
- 18. 17 Identity and AC Management Accessing GEs and services ● Level 1: Authentication o Check if a user has been authenticated ● Level 2: Basic Authorization ● Level 3: Advanced Authorization
- 19. 18 Identity and AC Management Level 1: Authentication IAM Infrastructure IdM Service Application Service Backend PEP OAuth2 flow Request + token Check token
- 20. 19 Identity and AC Management Accessing GEs and services ● Level 1: Authentication ● Level 2: Basic Authorization o Checks if a user has permissions to access a resource o HTTP verb + resource path ● Level 3: Advanced Authorization
- 21. 20 Identity and AC Management Level 2: Basic Authorization IAM Infrastructure IdM PAP PDP Service Application Service Backend PEP OAuth2 flow Request + token Check token
- 22. 21 Identity and AC Management Accessing GEs and services ● Level 1: Authentication ● Level 2: Basic Authorization ● Level 3: Advanced Authorization o Custom XACML policies
- 23. 22 Identity and AC Management Level 3: Advanced Authorization IAM Infrastructure IdP Service Application Service Backend PEP OAuth2 flow Request + token Check token PAP Policies DB PDP Check auth
- 24. 23 ● A JSON Web Token (JWT) is a JSON object defined in RFC 7519 as a safe way to represent a set of information between two parties. ● The token is composed of a header, a payload, and a signature. Identity and AC Management JSON Web Tokens Encoded Decoded
- 25. eID Integration CEF eIDAS 24 ● eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation to enable secure and seamless electronic interactions between businesses, citizens and public authorities. ● Access to European services by national eID eIDAS country 1 eIDAS country 2 eIDAS country 3 Service User country 2 eID
- 26. eID Integration FIWARE Identity Gateway 25 ● Integration of FIWARE Security Framework with eIDAS ● Every application registered in Keyrock can be linked to a eIDAS node o By an OAuth 2.0 – SAML2 gateway ● Users can then authenticate using their national eID o AC policies based on user eIDAS profile ● Transparent for applications providers
- 27. eID Integration FIWARE Identity Gateway 26 IAM Infrastructure IdP Service Application Oauth 2.0 requests access-token User info request eIDAS eIDAS node 1 IdP 1 eIDAS node 2 IdP 2 … SAML flow Authentication
- 28. Data Usage Control 27 ● Security Framework and Data Usage Control o Ensures data sovereignty o Regulates what is allowed to happen with the data (future usage). ● Integration with Big Data and Processing GEs
- 29. Summary: Terms Identity Management ensures that only the right individuals get access to resources • Usernames, passwords • Roles and permissions • etc... Access Control is the selective restriction of access to resources Authentication is a mechanism to confirm you are who you claim to be. i.e. Who are you? Authorization is a mechanism to ensure you have permission to access a resource i.e Is X allowed to do Y to Z? Authorization can be either Role Based (RBAC) or Policy Based (PBAC) When attempting to gain access you pass the PEP - Policy Execution Point You are either granted or denied access by a PDP - Policy Decision Point Administrators can set up rules using a PAP - Policy Administration Point 28
- 30. Summary: FIWARE Generic Enablers Keyrock - Identity Management to know who can do what • GUI based or API based • Supports human and machine users (such as IoT Agents) • Flexible Role-based administration • Multi-Tenant • OAuth2 Compliant • Simple PDP - Authentication or RBAC Authorization Wilma PEP Proxy - Gatekeeper to confirm permissions prior to access • User identified via a header within the request • Links to either Keyrock or Authzforce • Code can be extended for advanced scenarios Authzforce - Adjudicator to either permit or deny when given information • XACML based ruleset can be modified on the fly • Used in advanced scenarios PBAC Authorization Alternatives are available e.g. Keystone, Steelskin, IDSA Security • Always use the most appropriate tools for your use-case 29
- 31. Security GEs documentation 30 ● FIWARE Catalogue o https://www.fiware.org/developers/catalogue ● FIWARE Academy o https://fiware-academy.readthedocs.io/en/latest/index.html ● Identity Management – Keyrock o Repo: https://github.com/ging/fiware-idm ● PEP Proxy – Wilma o Repo: https://github.com/ging/fiware-pep-proxy ● Authorization PDP – AuthZForce o Repo: https://github.com/authzforce/server
- 32. Thank you! http://fiware.org Follow @FIWARE on Twitter