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.OpenSpecification.Security.Authorization PDP (R4.1) - FIWARE Forge Wiki

FIWARE.OpenSpecification.Security.Authorization PDP (R4.1)

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Security.Authorization PDP
Chapter Security,
Catalogue-Link to Implementation Authorization PDP
Owner Thales, Cyril DANGERVILLE

Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.

Copyright

Copyright © 2012-2014 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. In the context of FI-WARE, we assume that the IdM GE (Identity Management Generic Enabler) provides identity management and authentication for users and Client Applications. Then we will see how the Authorization PDP GE fits in the picture, i.e. it is able to use this information provided by the IdM GE as authorization attributes for fine-grained attribute-based access control. Business Requirement

Basic Concepts

Example Scenario

The basic concepts come from the OAuth 2 [OAuth2] and XACML [XACML3] standards illustrated by the sample scenario below. The OAuth standard is supported by the Identity Management GE essentially, the OAuth Authorization endpoint and Token endpoint in particular. The PEP is a consumer of OAuth tokens, therefore it validates OAuth tokens and getting authorization info from the token, such as user attributes; it is a also a client of the Authorization PDP since it forwards the retrieved token-related information with other request information in a authorization request to the Authorization PDP to get an authorization decision (Permit or Deny). Depending on this decision, the PEP blocks or forwards the request.

In the picture below, the steps go as follows:

  1. The Resource Owner - an end-user of the Location Tracking service - first requests the Location Tracking webapp (OAuth Client Application). To perform this request, the Location Tracking webapp needs to request some resource(s) owned by the end-user (Resource Owner) delivered by Location GE (OAuth Resource server). To be allowed to do this, the Location Tracking webapp needs the user consent and the resulting authorization code from the IdM GE.
  2. The webapp redirects the user to the IdM GE.
  3. If the user is not yet authenticated, the user authenticates to the IdM GE and is then asked to approve the Location Tracking webapp's request to access his/her resources on the Location GE.
  4. After successful authentication/approval, the user is redirected to the Location Tracking webapp with an authorization code.
  5. The webapp requests the IdM GE's token endpoint with this code and gets an Oauth access token in return.
  6. The webapp requests the Location GE with the token and gets access to the resources successfully.


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 provided by the Authorization PDP 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 provided by the Authorization PDP GE.

Policy Repository Point (PRP)

The PRP role is fulfilled by an internal policy storage mechanism of the Authorization PDP GE which is used by both the PAP and the PDP. As a result, users of the Authorization PDP GE API do not interact with a so-called PRP directly, but only through the PAP and PDP.

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, like a FIWARE Security Proxy GEi. The FIWARE Security Proxy is OAuth-aware, i.e. it extracts the OAuth access token from every access request and sends it to the IdM for validation, and also to get token-related information such as authenticated user information in return. Then the Proxy sends an authorization request to the Authorization PDP that contains this IdM-issued information with other information about the access request: resource, operation, etc. For instance, for a REST API request, the Security Proxy sends the URL, HTTP method and authenticated user attributes. The Authorization PDP GE replies with the authorization decision: Permit or Deny. The PEP forwards or blocks the access request based on this decision. In some complex use cases, it is hardly possible to delegate the PEP function to a proxy separated from the protected application (Resource Server in the OAuth context); it is better to have it built-in, therefore the built-in PEP shown in the diagram below.

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 like a FIWARE PEP Proxy GEi. In this case, the owner of the Resource Server must provide the necessary information to configure the Proxy for integration with the Resource Server.
    2. Built-in/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

Detailed Open Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labelled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labelled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications

Other Open Specifications

  • XACML 3.0

Re-utilised Technologies/Specifications

The Authorization PDP GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Attack. Any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself
  • Authentication protocol: "Over-the-wire authentication protocols are used to exchange authentication data between the client and server application. Each authentication protocol supports one or more authentication methods. The OATH reference architecture provides for the use of existing protocols, and envisions the use of extended protocols which support new authentication methods as they are defined." (OATH)
  • Access control: is the prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. (ITU-T-X-800_Link). More precisely, access control is the protection of resources against unauthorized access; a process by which use of resources is regulated according to a security policy and is permitted by only authorized system entities according to that policy. RFC 2828
  • Account: A (user) account is “typically a formal business agreement for providing regular dealings and services between principal sand business service providers.” OASIS Security Assertion Markup Language (SAML)
  • Authentication (AuthN): We adopted the following definition of authentication from RFC 3588"Authentication is “the act of verifying the identity of an entity (subject)”
TrustInCyberspace adds the term “level of confidence” to this definition:
Authentication is the process of confirming a system entity’s asserted identity with a specified, or understood, level of confidence.” This definition holds all necessary parts to examine authentication in broad sense. First of all it does not narrow the authentication to human users, but refers to a generic “system entity”. See authentication reference architecture description for a closer look at different identities that could be authenticated.
Secondly it introduces the often neglected concept of “level of confidence” which applies to each authentication of an identity. No computer program or computer user can definitely prove the identity of another party. There is no authentication method that can be secured against any possible identity-theft attack, be it physical or non-physical. It is only possible to apply one or more tests, which, if passed, have been previously declared to be sufficient to go on further. The problem is to determine which tests are sufficient, and many such are inadequate.
The original Greek word originates from the word 'authentes'='author'. This leads to the general field of claims and trust management, because authentication could also mean to verify the “author” / issuer of any claim.
The confirmation or validation process of authentication is actually done by presenting some kind of proof. This proof is normally derived from some kind of secret hold by the principal. In its simplest form the participant and the authentication authority share the same secret. More advanced concepts rely on challenge/response mechanisms, preventing the secrets to be transmitted. Refer to Authentication Technologies for a detailed list of authentication methods used today.
As stated above, each authentication method assures only some level of trust in the claimed identity, but none could be definite. Therefore it makes sense to distinguish the different authentication methods by an associated assurance level, stating the level of trust in the authentication process.
As this assurance level depends not only on the technical authentication method, but also on the overall computer system and even on the business processes within the organization (provisioning of identities and credentials), there is no ranking of the authentication methods here.
  • Countermeasures. Action, device, procedure, technique or other measure that reduces the vulnerability of an information system.
  • Cyber attack. An attack, via cyberspace, targeting an entity (industrial, financial, public...) and using cyberspace for the purpose of disrupting, disabling, destroying, or maliciously controlling a computing environment/infrastructure; or destroying the integrity of the data or stealing controlled information
  • Exploit. A program or technique that takes advantage of vulnerability in software and that can be used for breaking security, or otherwise attacking a host over the network
  • Federation: The term federation “is used in two senses - "The act of establishing a relationship between two entities. An association comprising any number of service providers and identity providers.” OASIS Security Assertion Markup Language (SAML)
“A federation is a collection of realms that have established a producer-consumer relationship whereby one realm can provide authorized access to a resource it manages based on an identity, and possibly associated attributes, that are asserted in another realm.
Federation requires trust such that a relying party can make a well-informed access control decision based on the credibility of identity and attribute data that is vouched for by another realm.” WS-Federation @ IBM
Remark: Federation according to WS-Federation @ IBM is similar to the concept of a Circle of Trust.
  • FI. Future Internet.
  • Forensics for evidence. The use of scientifically derived and proven methods toward the preservation, collection, validation, identification, analysis, interpretation, documentation and presentation of digital evidence derived from digital sources for the purpose of facilitating or furthering the reconstruction of events found to be criminal, or helping to anticipate unauthorized actions shown to be disruptive to planned operations.
  • Identity. In the narrow sense, identity is the persistent identifier of users (user name), things or services by which other parties “remember” them and, hence, are able to store or retrieve specific information about them and are able to control their access to different resources. In the wider sense, identity also covers further attributes of users, things and services; e.g. for users, such information may include personal information such as context, group membership and profile.
  • Identity (Digital): The term identity and its meaning have been discussed controversially in the “identity community” for many years. Until now, there is no commonly agreed definition of that notion. : : The IdM && AAA reference architecture applies the following three definitions of identity.
The Identity Gang defines the term digital identity as follows:
A digital identity is “a digital representation of a set of Claims made by one party about itself or another digital subject.”
The following comments were added:
A digital identity is just one set of claims about a digital subject. For any given digital subject there will typically be many digital identities.
A digital identity can be created on the fly when a particular identity transaction is desired or persistent in a data store to provide a representation that can be referenced.
A digital identity may contain claims made by multiple claimants.
A digital identity may be signed by a digital identity provider to provide assurance to a relying party.
This definition emphasizes two facts:
Normally, a principal (subject) has multiple digital identities or personas.
Identities are made out of attributes (claims).
Therefore, the scope of identity management in the reference architecture has two viewpoints: For once it focuses on identities and personas itself, and on the other side, it deals with the attributes of these identities and personas.
The Liberty Alliance Project (LAP) defines digital identity as follows:
Digital identity is “the essence of an entity. One’s identity is often described by one’s characteristics, among which may be any number of identifiers. A Principal may wield one or more identities.”
RSA uses the following definition of digital identity:
“Digital identity consists of an identity assertion and the characteristics, sometimes called attributes that are collected or observed through our computerized relationships. It is often as simple as a user name and password.”
The definition of RSA adds one important aspect to the identity discussion: Even the simplest user name and password combinations without any additional attributes or claims constitute an identity.
  • Identifier: Identifiers can be understood as a dedicated, publicly known attribute of an identity that refers to that identity only. Typically, identifiers are valid within a specific domain. Special types of identifiers are valid globally, due to the use of popular domain naming and resolution protocols such as DNS, which implies addressing capabilities to the identity. OASIS Security Assertion Markup Language (SAML) defines identifier as follows:
An identifier is “a data object (for example, a string) mapped to a system entity that uniquely refers to the system entity. A system entity may have multiple distinct identifiers referring to it. An identifier is essentially a "distinguished attribute" of an entity.”
  • Identity context: is “the surrounding environment and circumstances that determine meaning of digital identities and the policies and protocols that govern their interactions.” (Identity Gang)
  • Identity management (IdM): comprises “the management of identity information both internally and when it is passed from one entity to another.” Open Mobile Alliance (OMA)
  • Identity provider: The Open Mobile Alliance (OMA) defines the term identity provider (IdP) as follows - An identity provider is “a special type of service provider […] that creates, maintains, and manages identity information for principals, and can provide […] assertions to other service providers within an authentication domain (or even a circle of trust).”
Another notion defines identity provider as “an agent that issues a digital identity [that] is acting on behalf of an issuing Party.” (Identity Gang)
The following definition of identity provider descends from WS-Federation @ IBM: “An identity provider is an entity that acts as an authentication service to end requestors and as data origin authentication service to service providers […]. Identity providers are trusted (logical) 3rd parties which need to be trusted both by the requestor […] and the service provider which may grant access to valuable resources and information based upon the integrity of the identity information provided by the identity provider.”
The Identity Provider is part of the Identity Management infrastructure.
  • Impact. The adverse effect resulting from a successful threat exercise of vulnerability. Can be described in terms of loss or degradation of any, or a combination of any, of the following three security goals: integrity, availability, and confidentiality.
  • Partial identity: a partial identity is a set of attributes of a user. Thus, an identity is composed of all attributes of a user, a partial identity is a subset of a user's identity. Typically, a user is known to another party only as a partial identity. A partial identity can have a unique identifier. The latter is a strong identifier if it is allows for a strong authentication of the user (holder) of the partial identity, such a cryptographic "identification" protocol
  • Privacy: Dictionary definitions of privacy refer to "the quality or state of being apart from company or observation, seclusion [...] freedom from unauthorized intrusion" (Merriam-Webster online). In the online world, we rely on a pragmatic definition of privacy, saying that privacy is the state of being free from certain privacy threats.
  • Privacy threats. The fundamental privacy threats are: traceability (the digital traces left during transactions), linkability (profile accumulation based on the digital traces), loss of control (over personal data) and identity theft (impersonation).
  • Risk analysis. The process of identifying security risks, determining their magnitude, and identifying areas needing safeguards. An analysis of an organization's information resources, its existing controls, and its remaining organizational and MIS vulnerabilities. It combines the loss potential for each resource or combination of resources with an estimated rate of occurrence to establish a potential level of damage
  • Security monitoring. Usage of tools to prevent and detect compliance defaults, security events and malicious actions taken by subjects suspected of misusing the information system.
  • Service impact analysis. An analysis of a service’s requirements, processes, and interdependencies used to characterize information system contingency requirements and priorities in the event of a significant disruption.
  • Single sign-on: is “From a Principal’s perspective, single sign-on encompasses the capability to authenticate with some system entity—[…] an Identity Provider - and have that authentication honored by other system entities, [termed] Service Providers […]. Note that upon authenticating with an Identity Provider, the Identity Provider typically establishes and maintains some notion of local session state between itself and the Principal’s user agent. Service Providers may also maintain their own distinct local session state with a Principal’s user agent.” Liberty Alliance Project (LAP)
  • S&D: Security and Dependability
  • Threat. An event, process, activity being perpetuated by one or more threat agents, which, when realized, has an adverse effect on organization assets, resulting in losses (service delays or denials, disclosure of sensitive information, undesired patch of programs or data, reputation...)
  • USDL and USDL-Sec: The Unified Service Description Language (USDL) is a platform-neutral language for describing services. The security extension of this language is going to be developed FI-WARE project.
  • Vulnerability. A weakness or finding that is non-compliant, non-adherence to a requirement, a specification or a standard, or unprotected area of an otherwise secure system, which leaves the system open to potential attack or other problem.
  • WADL. The Web Application Description Language is a machine-readable XML description of HTTP-based web applications used typically with REST web services.
  • WS-SecurityPolicy: It is an extension to SOAP to apply security to web services. It is a member of the WS-* family of web service specifications and was published by OASIS.
  • The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.
Personal tools
Create a book