FI-WARE OAUTH-XACML-based API Access Control - Overview (Part 1)
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
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