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
Testbed Security Architecture - FIWARE Forge Wiki

Testbed Security Architecture

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

Introduction

Testbeds deployed in FI-WARE offer a Security architecture that comprises a set of Generic Enablers and components from Cloud and Security Chapters. They allow third-party applications to securely use FI-WARE Generic Enablers acting on behalf of users that are previously authenticated/authorized in the platform.

Overview

The following diagram shows the main components and Generic Enablers that comprise the second release of FI-WARE architecture.

Testbed Security Architecture Overview

The architecture comprises a set of Generic Enablers and components that provide security capabilities to other Web Applications , Backend Applications and FI-WARE Generic Enablers. Identity Manager GE is offering management of users, their authentication and authorization, and privileges within organizations. It also allows developers to register applications that will access public information about the users, only once they allow these applications to use their information. Application developers and providers can use this system to securely access FI-WARE Generic Enablers by using OAuth 2.0 standard. Identity Manager GE stores permissions and roles in the Access Control GE, which will later validate requests from the Keystone Proxy component, basing on XACML. This component receives OAuth tokens and it checks them against Identity Manager GE and then it authorize the related user against Access Control GE. PEP Proxy forces every request to be authenticated against Keystone Proxy.

Each of the above components provides a HTTP API that can be used programmatically. The human actor represents the programmatic user of the different capabilities of the Security Architecture via REST APIs.

Security Architecture for Cloud Chapter

Testbed Security architecture also offer this mechanism to Cloud GEs with some details. In this chapter there is no need for PEP Proxy while there is a similar programmatic library inside every Cloud GE. The following diagram shows the security architecture applied to the Cloud Chapter GEs.

Testbed Security Architecture Overview

This diagram differs from the previous one in the appereance of Keystone Middleware that is a library that takes part of every Cloud GE. This library acts as a PEP Proxy because it validates the OAuth token obtained from every request against Keystone Proxy. The rest of components play the same role as in the general Testbed Security Architecture. As mentioned in Cloud Hosting Architecture every Cloud Generic Enabler can be also accessed programmatically, but in this case Keystone Middleware will also check tokens. Self-Service Interfaces GE is the Web Portal that allows users to access Cloud GEs from their web browsers, and it is also compatible with he Identity Management GE since it authenticates users in this component using OAuth 2.0.

Inter-dependencies and Interaction between GEs and components

While each GE and component comprises a set of functions and capabilities that can be used stand-alone, in a typical testbed deployment the different components will interact with each other, to provide a complete end-to-end solution. For example:

  • PEP Proxy receives secured requests from Web Applications and users, and it checks tokens inside these requests against Keystone Proxy.
  • Keystone Proxy validates tokens against Identity Manager GE and authorizes user roles in the Access Control GE in the same request.
  • Identity Manager GE store permissions and roles in Access Control GE.

Concepts and Topics

This Security Architecture bases the authentication and authorization on a series of terms which are often used in Authentication mehcanisms:

  • Users: They are actors who have register an account in the Identity Manager GE.
  • Organizations: Groups of users in which they can play multiple and different roles. A user can create organizations and add other users to it. They are created in the Identity Manager GE, and are automatically used in the Cloud Chapter (also known as Tenants or Projects) as well as other GEs.
  • Roles: Set of permissions that a user can play inside an organization. There are a set of pre-defined roles in the Identity Manager GE, but Application Developers can also add their own roles that make sense in the scope of their applications.
  • Permissions: They are the acceptance/rejection of an user action in a resource. In the Identity Manager GE they are defined on REST APIs (e.g. a permission that allows a user to make a GET HTTP request to a resource with the URL /posts/).
  • Applications: Third-party web services that allow users to authenticate with their credentials in the Identity Manager GE. These services will redirect the user's web browser to the Identity Manager to show them the form to put their credentials. Once they are authenticated it will redirect back to the web application with the OAuth token.
  • Token: It is the OAuth security token that represents a user who has successfully authenticated in the Identity Manger GE. It is used in every HTTP Request to act on behalf of the user.
Personal tools
Create a book