We use first and third-party's cookies to improve your experience and our services, identifying your Internet browsing preferences on our website. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
Security Architecture - FIWARE Forge Wiki

Security Architecture

From FIWARE Forge Wiki

Jump to: navigation, search



Copyright © 2014-2016 by Thales.

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.

Terms and definitions

Before we show an overview of the architecture, it is important for the reader to understand a few key terms that we will use throughout the document, regarding each topic addressed by the Security Chapter:


The overall ambition of the Security Architecture of FIWARE is to demonstrate that the Vision of an Internet that is secure by design is becoming reality. Based on achievements to date and/or to come in the short-term (both from a technological but also a standardization perspective) we will show that secure by design is possible for the most important core (basic) and shared (generic) security features as anticipated by the FIWARE project and in accordance with the requirements of external stakeholders and users. Therefore, the secure by design concept will address both the security properties of the FIWARE platform itself and the applications that will be built on top of it. As such, the Security Architecture will focus on key security features such as identity management, access control or security monitoring to be delivered as so-called generic security enablers which, by design, can be integrated with other FIWARE GEs.

In the context of FI-Core (FIWARE follow-up project), the Security Architecture has been revisited and also simplified to come up with an architecture focused on major areas to be covered (since corresponding to market needs/demands) and for which Core Security GEs have to be provided in a way that make them easy to install, deploy and use even by non-ICT experts.

For the previous version of the architecture, refer to Security Architecture R3.

The security architecture of FIWARE is thus built around the following topical areas (also representing key concerns in Future Internet):

  • Identity and Access Management;
  • Cybersecurity;
  • Trust and Trustworthiness management.

The Security architecture consists of five GEs that together provide a comprehensive set of services for applications to comply with major security requirements such as authentication, authorization and trustworthiness. Four of them are used by applications at runtime. They are shown in the figure below. The last one is not part of the same picture since it is used at development and testing stage of the software lifecycle. We will describe it later.

Security Architecture Overview

To explain the diagram above, we give below a brief description of each of the Generic Enablers shown there, together with their relationships to other participating in the FIWARE environment.

  • Identity and Access Management
    • The Identity Management GE (IdM):
      • Features overview: the GE provides user, organization and application identity (and credentials) management, and authentication. It addresses new requirements for identity management of things (IoT). It complies with IETF System for Cross-domain Identity Management (SCIM) 2.0 Specification, providing a REST API for managing user identities in multi-tenant cloud-based applications and services. It also provides flexible management of organization-specific and/or application-specific roles and associated permissions (on specific URLs and actions), as well as user-role assignments.
      • Interactions overview: As shown on the diagram, developers (application owners) interact with the IdM to register their applications, and manage the security of their application (credentials, roles, authorization policy); end-users interact with the IdM to self-register, manage their profile and their organizations. Finally, all users and client applications (e.g. service consumers) interact with the IdM for authentication and possibly delegate access to a third-party client application (using the OAuth2 flow). PEPs (Policy Enforcement Points, e.g. the PEP Proxy GE presented in the next section) interact with the IdM to validate access tokens issued by the IdM and presented by access requesters when requesting access to the protected backend applications. The PEP also uses and gets the user information related to token. More information can be found in Authorization PDP GE architecture description.
      • The IdM GEri currently available in the catalogue is KeyRock.
    • The Authorization PDP GE (PDP) manages authorization policies in XACML format and enforces decisions based on them when requested by PEPs to authorize or deny access requests to services.
      • Features overview: this GE implements XACML v3.0 Core specification with the following benefits:
        • More advanced and flexible policy target matching capabilities;
        • Extensible attribute categories;
        • Dynamic Obligations (actions to be fulfilled by the PEP) and possibility to use Obligations in Rules;
        • Multi-tenant RESTful PAP/PDP API.
      • Interactions overview: besides the interaction with PEPs, the PDP GE (REST API) is used by the IdM GE to manage policies defined by developers for their application and have them enforced via the PDP API when requested by PEPs. More information can be found in Authorization PDP GE architecture description.
      • The Authorization PDP GE, introduced in release 4.1, replaces the former Access Control GE from Release 3. The Authorization PDP GEri currently available in the catalogue is AuthZForce.
    • The PEP Proxy plays the role of Policy Enforcement Point in the form of a HTTP reverse-proxy in front of the protected REST services.
      • Features overview: the PEP intercepts requests to the service, then authenticates the access request by requesting the IdM to validate the attached access token; then it authorizes the request by requesting the PDP with the client access request information and token-related information (such as user attributes retrieved in previous step from the IdM), for the PDP to decide whether to permit or deny based on the current authorization policy enforced by the PDP for the requested resource. The PEP applies the PDP's decision to permit or deny the access request. If permitted, the PEP forwards the request to the service, then forwards the service’s response back to the client, like a reverse proxy. As shown on the diagram, other PEPs may be used instead of the PEP Proxy GE for very specific types of applications, such as non-RESTful services or non-HTTP services. More information in the section PEP Proxy GE architecture description.
      • The PEP Proxy GE is a new GE introduced in Release 4. The GEri currently available in the catalogue is Wilma.
  • The Cyber Security GE provides a compact tool, depending on customers' preferences, embedding an Attack Paths Engine, with Attack Path Scoring and a Remediation component, easy to implement by an SME without particular expertise in security.
    • Features overview:
      • All-in-one application vulnerability data collector,
      • Dynamic Risk Analysis with attack path computation and scoring,
      • Visualization of the risk level (attrition) through color codes,
      • Automated remediation proposal based on user feedback, with rich countermeasures catalogue ;
      • Privacy-Preserving data sharing: based on the principles of Multi-Party Computation (MPC), the Cyber Security GE should enable its users to execute computations on data they are otherwise unwilling to share.
    • Interactions overview: The Cyber Security GE may collect security information and events from the other GEs and from the infrastructure through a SIEM provided by the infrastructure owner on his own. Indeed, the SIEM component is no longer part of this GE as it was until Release 3 with the former Security Monitoring GE. It is now the responsibility of the infrastructure owner to acquire a SIEM on his/her own - various open source and COTS solutions exist - and integrate it with the CyberSecurity GE. For more information on this integration process and this GE in general, please refer to the section CybserSecurity GE architecture description.
    • The Cyber Security GE is a new GE introduced in Release 4, replacing the Security Monitoring GE. The GEri should be available in the catalogue for major release R4.
  • Trust & Trustworthiness Management: the Trustworthy Factory GE provides to application developers an environment to assist them in the development of trustworthy applications; more specifically, help them meet trustworthiness objectives (as defined above). The environment brings the following benefits to the developer and evaluator (or certifier):
    • For the developer: a trustworthiness-driven (Java) development platform, that provides a set of integrated tools to help the developer achieve trustworthiness objectives for this/her application, and to produce the related evidence by means of static analysis of the application code and runtime analysis during the tests;
    • For the evaluator/certifier: a Trustworthy Application Certification Platform supporting certificate editing, signature and binding (code labeling tool).
    • The Trustworthy Factory GE is a new GE introduced in Release 4. The GEri should be available in the catalogue for major release R4.

Interdependencies and Interactions between GEs

  • IdM – Authorization PDP: the IdM depends on the Authorization PDP to enforce access control policies defined by developers via the IdM’s developer portal for their applications. When a developer decides to apply the access policy he/she has defined in the portal, the IdM converts it into XACML format and sends the policy to the Authorization PDP GE via its PAP API. More information can be found in the Identity Management GE architecture description.
  • PEP Proxy – IdM: the PEP Proxy depends on the IdM for authenticating access requests to protected services/resources, more specifically validate the access token from each access requests, and getting information about the token as known by the IdM such as token expiration date and requester attributes: ID, role, etc. For each access request coming to the PEP Proxy, the Proxy validates its access token and gets information about it using the IdM API. More information can be found in the PEP Proxy GE architecture description.
  • PEP Proxy – Authorization PDP: the PEP Proxy depends on the Authorization PDP for enforcing authorization decision. For each access request to protected services, when advanced authorization is needed, the PEP Proxy sends information about the access request (resource URL, HTTP method…) and the requester, retrieved from the IdM, to the Authorization PDP GE’s PDP API. If the PDP’s decision is Permit, the PEP forwards the request as usual. If not (Deny), it rejects the request with a HTTP 403 response for instance. More information can be found in the PEP Proxy GE architecture description.

Interfaces with other Chapters

Security pervades throughout any architecture with sensitive data or assets. Therefore, we dare to say that Security GEs may be used by all FIWARE chapters.

Identity Management GE

Any other GE or application that has security requirements related to access control (authentication, authorization) can use the Identity Management GE (e.g. GEri Keyrock) and OAuth2 protocol in order to secure frontend and backend parts of them. Using OAuth2, they can implement a single sign on mechanism that allows every user with a FIWARE account to login in their web applications. Furthermore, and together with the PEP Proxy GE and the Authorization PDP GE, they can add an authorization level to their backend services.

PEP Proxy GE

This GE provides the enforcement of authorization policy to REST-based backend services in order to allow and restrict access to the available resources. Thus, and together with IdM GE, you can specify which users have access to which specific resources in your backend. And using the GE (e.g. GEri Wilma) on top of your REST service, it will decide when a request has the required permissions to be executed.

Authorization PDP GE

Any other chapter’s GE with a need for advanced dynamic authorization enforcement may benefit from the Authorization PDP. For GEs with standard REST-style APIs, there is no need to interface the PDP directly with the protected application, but only with the PEP Proxy protecting the application. However, for other custom (non-REST) APIs or very specific access control requirements of certain applications used in other chapters, using the PEP Proxy is not possible; in which case, the application may need a custom PEP (possibly built-in) interacting directly the PDP.

Trustworthy Factory GE

Any other chapter interested in improving or merely proving the level of trustworthiness of an existing GE implementation written in Java, or developing new trustworthy GE implementations or features in Java, may benefit from the Trustworthy Factory GE.. In general, this could be part of any process to improve the quality of your GE software. Indeed, trustworthiness attributes are usually important software quality attributes.

Cyber Security GE

In FIWARE, the Cloud Chapter offers Generic Enablers for designing a modern cloud hosting infrastructure for Future Internet applications and services. The CyberSecurity GE can help to secure this infrastructure by computing its attack paths. In order to do that, the administrators of the cloud infrastructure have to do regular vulnerability scans, export the network topology in the inputs format of the Cyber Security GE, and analyze the security of the infrastructure, using the Cyber Security GE. They may also deploy the remediations proposed by the Cyber Security GE, in order to improve the security of the Cloud infrastructure.

Architecture Description of GEs

Personal tools
Create a book