We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. 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 functionalities 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 and access control 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.

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

  • Identity and Access Management;
  • Access Control Decision and Enforcement.

The Security architecture consists of three GEs that together provide a comprehensive set of services for applications to comply with major security requirements such as authentication and authorization. Some 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.

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.

Architecture Description of GEs

Personal tools
Create a book