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
FIWARE.ArchitectureDescription.Security.Access Control Generic Enabler - FIWARE Forge Wiki

FIWARE.ArchitectureDescription.Security.Access Control Generic Enabler

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

Copyright

Copyright © 2012-2015 by Thales

Legal Notice

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

Overview

The initial requirement for the architecture presented here is the following: to provide a mean for controlling access to resources that are available on a given FI-WARE Instance. Those resources are owned by users of the FI-WARE Instance, either end-users (data that belongs to each end-user) or by application or service providers (API operations exported by a given application or service, which may well be a FI-WARE GE). Such access will be typically requested by client applications or services (including FI-WARE GEs) acting on behalf of another user. It would require approval from the resource owner and may be restricted by security policies that are either global to the FI-WARE Instance, or defined for application/services or for the end-users (both resource owners and end-user on behalf of whom access is requested), as well as the organizations that end-users belong to, if any.

In order to complete the picture, it is strongly recommended that the privacy of the end-users be preserved. In particular, the end-user – and/or the end-user’s organization - must be able to control which third-party applications may have access to which of his/her data, for which duration, etc. Each such access must be auditable, as required by various regulations or internal policies.

Furthermore, the third-party applications should not have knowledge of the credentials (typically login and password) of the user on behalf of whom they are trying to get access to resources. Last but not least, users should be able to revoke access from all or specific third-party applications at will, without having to change their password.

On the figure below, Service GEs provide API resources to Client Applications. Some of these APIs provide access to specific resources of some users. The IdM GE (Identity Management Generic Enabler) provides identity management and authentication for users and client applications. Business Requirement

Basic Concepts

Example Scenario

The basic concepts come from the OAuth 2 [OAuth2] and XACML 2.0 [XACML2] standards illustrated by the sample scenario below. The OAuth standard is supported by the Identity Mangement GE essentially, the OAuth Authorization endpoint and Token endpoint in particular. The Access Control GE is only a consumer of OAuth tokens, therefore it only supports validation of OAuth tokens and getting authorization info from the token, such as user attributes. The XACML standard is only supported by the Access Control GE.

Sample Scenario

(OAuth) Resource Owner

The Resource Owner is the entity that owns resources on a Resource Server. The Resource Owner may be an End-User, an application or service provider. The Resource Owner may delegate resource access to a third-party - the Client Application (see next section) - with certain restrictions, e.g. limited scope, time period.

The Resource Owner must be registered in the IdM Generic Enabler.

(OAuth) Client Application

The Client Application is the third-party from the Resource Owner's point of view, that is requesting access to the resources on behalf of that resource owner.

The Client Application must be registered in the IdM Generic Enabler.

(OAuth) Resource Server

The Resource Server, also referred to as the Target Service (or Service GE in FI-WARE) is the server hosting the resources that the Client Application requests access to.

The Resource Server must be registered in the IdM Generic Enabler.

OAuth Authorization Endpoint

This is the endpoint where client applications redirect users to for authorization grant and get an authorization code in return. This authorization code represents the user's approval of the client app's request to access resources on behalf of the user. Then, the client app can use the authorization code to request an access token from the Token Endpoint (see below). See also the Authorization Endpoint section in the OAuth 2.0 standard.

This endpoint is implemented by the IdM Generic Enabler (NSN/DT).

OAuth Token Endpoint

The Token Endpoint issues access tokens to Client Applications provided that they authenticate successfully and present a valid authorization code. Client Applications need such access tokens to access the Resource Servers.

Policy Decision Point (PDP)

The PDP provides authorization decisions based on various attributes and XACML policies. Attributes may come from the access request context as provided by PEPs (see below), such as the request URL, the HTTP method and especially the OAuth access token. From the OAuth access token, the PDP is able to get extra attributes related to the OAuth context (the resource owner a.k.a end-user ID, the client ID, etc.). It is also able to obtain extra attributes associated with the end-user by means of requesting them from the Identity Management GE acting as Attribute Provider (clearance level, role, location, etc.). This information, combined with information about the environment (e.g., current time) is used by the PDP to check whether access must be granted based on defined XACML policies.

This endpoint is implemented by the Access Control GE.

Policy Administration Point (PAP)

The PAP provides an interface for policy administrators to manage XACML policies to be enforced by the PDP.

This endpoint is implemented by the Access Control GE.

Policy Repository (PRP)

The XACML PRP is only used internally for storing policies managed by the PAP and retrieved by the PDP for enforcement.

It is also part of the Access Control GE.

Policy Enforcement Point (PEP)

The PEP protects the Resource Server (e.g., instance of a FI-WARE GEis) from unauthorized access to resources. The PEP can be deployed as a security proxy that intercepts all HTTP(S) traffic to the Resource Server. Access is denied or permitted depending on the XACML PDP’s decision. The PEP forwards information about the API request (URL, HTTP method, HTTP headers, etc.) to the PDP, including the OAuth access token which the PDP can use to get information about the client application, the user on behalf of which the request has been issued and the token scope (user-approved permissions).

Main interactions

From the user and the client application’s perspective, the main interactions are the same as described in the OAuth 2.0 standard, section 1.2. From the Resource Server’s perspective, the OAuth token validation and API request authorization may be delegated to the PEP, so that the integration effort on the Resource Server is minimal.

The main interactions are illustrated by the figure below.

Main interactions

For further details on the OAuth interactions with the IdM GEs, please refer to FIWARE Open Specification of Identity Management Generic Enabler.

Basic Design Principles

  • The architecture complies with the OAuth and XACML standard.
  • All APIs (IdM OAuth APIs, XACML Policy Management API, XACML PDP API, Resource Server APIs) are RESTful APIs.
  • Format of access control policies managed by the PAP and enforced by the PDP is defined by the XACML standard.
  • The PDP computes access decisions based on policies according to the XACML standard rules for policy evaluation (XACML engine).
  • The PDP and PAP should support multi-tenancy.
  • There are several options for the PEP deployment:
    1. Use a HTTP Proxy. In this case, the owner of the Resource Server must provide the necessary information to the PEP proxy owner for integration with the Resource Server.
    2. Built/Embedded in the Resource Server. In this case, the PEP implementation is the responsibility of the owner of the Resource Server.

In all cases, the PEP would have to integrate with the IdM Generic Enabler for OAuth token validation, and the XACML PDP for requesting authorization decisions.

References

Personal tools
Create a book