This document discusses API access control for FIWARE GEs using OAuth and XACML. It describes how the IdM GE can provide OAuth authorization services while the Access Control GE can enforce access control policies set in XACML. The Access Control GE includes a Policy Decision Point and can validate OAuth access tokens to control access to protected resources according to policies. Several solutions are provided for OAuth-aware and unaware policy enforcement points.

1. Follow @FIWARE #FIWARE-AZ on Twitter !
The FI-WARE Project – Base Platform for Future
Service Infrastructures
FI-WARE Access Control GE
Part 1 – API Access Control with OAuth/XACML Overview
Cyril DANGERVILLE, Thales
FI-WARE / WP8 / T8.2
fiware-api-cross@lists.fi-ware.eu

2. UC Requirement:
GEs’ REST API Access Control
Service
1. UC project apps need to invoke APIs provided by GEs to access user resources.
2. User privacy must be preserved.
OAuth framework fits very well!
The FI-WARE Project – Base Platform for Future
Service Infrastructures
FI-Ware Testbed
Service
GE
IdM
GE
IdM
GE
GE
Service
GE
Service
GE
Client
APP
Client APP
GE

3. Sample scenario in OAuth context
1
2
3
4
(Resource Owner)
The FI-WARE Project – Base Platform for Future
Service Infrastructures
Location GE
(Resource Server)
Location Tracking
WebApp
(Client App)
5
IdM GE
•Registration Service
•Authentication Service
•Oauth Authorization Service
6
User registers to the Tracking App. And allows the tracking app to retrieve the location data from location GE
User, Location Tracking webapp and Location GE have to be pre-registered at IDM GE.

4. OAuth Authorization Framework
 IETF: RFC 6749, version in FIWARE: 2.0 (latest)
 “enables a third-party application to obtain limited access to an HTTP service, either on behalf of
a resource owner by orchestrating an approval interaction between the resource owner and the
HTTP service, or by allowing the third-party application to obtain access on its own behalf.”
 The old way: you (resource owner) share your credentials with the 3rd party
 Security Issue 1: 3rd party ends up storing your credentials
 Security Issue 2: works well for password authentication only
 Security Issue 3: 3rd party get same complete access to your stuff as You
 Security Issue 4: revoking 3rd-party access is VERY painful (password
change) and hardly to never specific to an individual 3rd-party
 Security Issue 5: if 3rd-party compromised, so are your credentials and data
 Resource Owner: delegates LIMITED resource access to 3rd party (Client App)
 Client App: the 3rd party from the Resource Owner’s standpoint
 Resource Server (later referred as Target Service (GE)): hosts the resources
 Authorization Endpoint: issues Authorization Code that represents resource owner
granting access to 3rd party on his/her behalf
 Token Endpoint: issues Access Token in exchange for Authorization Code (or refresh
token), sent to the Resource Server to get access
The FI-WARE Project – Base Platform for Future
Service Infrastructures

5. XACML
 eXtensible Access Control Markup Language
 Fact: enterprise security policy (if exists) managed in different places (HR,
Legal, Finance, IT, etc.), enforced in many points: network access, mail,
intranet, business apps, etc.
-> Consolidated view and global application of “best practices” in access
control is VERY VERY HARD
 Where to start? Common language for expressing security policy
 OASIS standard, version in FIWARE: 2.0 (latest 3.0 released Jan 2013)
 Related to IETF Policy Framework Working Group and the Distributed Management Task Force
(DMTF)/Common Information Model (CIM) (RFC3198), and ISO10181-3 (Access Control Framework)
 Policy Decision Point (PDP): provides authorization decisions based on
Attribute-based Access Control (ABAC) / RBAC policies:
 Subject(s) can do Action(s) on Resource(s) in given Environment,
provided some Condition(s) on Subject/Action/Resource/Environment
 Policy Administration Point (PAP)
 Policy Repository Point (PRP)
 Policy Enforcement Point (PEP): protects the resource, i.e. intercepts
request and asks PDP for permission before letting it through
 Attribute Finder (non-XACML term): gets attributes not provided by PEP
The FI-WARE Project – Base Platform for Future
Service Infrastructures

6. FIWARE API Access Control based on…
 IdM GE:
 Self-Registration/Self-Care Service
 User & Service Administration Service
 Authentication & SSO Service
 OAuth Services:
 Authorization Endpoint -> resource owner’s authz grant
 Token Endpoint -> access token
 DT GCP only tested so far with Access Control GE. NSN One-IDM will
officially support OAuth 2.0 in R2.3.3 (end of June)
 Access Control GE:
 Access Control Policy Administration (PAP)
 Access Control Policy Enforcement:
 PEP(s) built-in or deployed as reverse proxy(ies) – Your own / Thales
 Access Control Policy Decision Point (PDP)
 OAuth access token validation
 Attribute Finders provide attributes from various sources, e.g.
 OAuth access token, such as JSON Web Token (JWT)
 IdM GE API for user attribute mgt
The FI-WARE Project – Base Platform for Future
Service Infrastructures

7. Solution for OAuth-UNaware PEP (option 1)
The FI-WARE Project – Base Platform for Future
Service Infrastructures

8. Example: Cloud WP
Oauth-Enabled
Client App
Keystone PEP
9 request info +
token
14 validation result +
request info + attrib
The FI-WARE Project – Base Platform for Future
Service Infrastructures
NSN/DT IdM
11 Access token
Thales RBAC/XACML Asset
1 request
2 redirect to IdM OAuth
4 Authentication +
Json token
5 Json token
6 Json token + client id + client secret
Resource
7 Access token
8 request + token
10 request info + token
12 Access token + attrib
13 validation result +
request info + attrib
15 request
Proxy
Keystone Middleware
Accounting + Monitoring
7

9. Solution for OAuth-aware PEP (option 2)
The FI-WARE Project – Base Platform for Future
Service Infrastructures

10. Solution for OAuth-aware/IdM-integrated PEP
(option 3)
The FI-WARE Project – Base Platform for Future
Service Infrastructures

11. Example: Live Demo
Oauth-Enabled
Client App
(simulation of
call center backend)
C
Proxy - D
The FI-WARE Project – Base Platform for Future
Service Infrastructures
IdM-like component
0 user role can do verb
10
A
Thales RBAC/XACML Asset - B
1. User & password
2. Authentication + token-1
3 token-1 + client id + client secret
4 Oauth access token
5 request + Oauth access token
7 user role
9 validation result
10 request
Live Demo app backend
6 Oauth access
token
8 user role, verb
Configuration scripts - E

12. Thanks !
http://fi-ppp.eu
http://fi-ware.eu
Follow @FIWARE #FIWARE-AZ on Twitter !
The FI-WARE Project – Base Platform for Future
Service Infrastructures
11