FIWARE OpenSpecification Security Access_Control_Generic_Enabler

17FIWARE OpenSpecification Security Access_Control_Generic_Enabler

17.1Preface

17.2Copyright

17.3Legal Notice

17.4Overview

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.

17.5Basic Concepts

17.5.1Example 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.

17.5.2(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.

17.5.3(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.

17.5.4(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.

17.5.5OAuth 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).

17.5.6OAuth 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.

17.5.7Policy 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.

17.5.8Policy 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.

17.5.9Policy 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.

17.5.10Policy 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).

Download 1.78 Mb.

Share with your friends: