FI-WARE OAUTH-XACML-based API Access Control - Overview (Part 1)

The FI-WARE Project – Base Platform for Future Service Infrastructures

Follow @FIWARE #FIWARE-AZ on Twitter !

FI-WARE Access Control GEPart 1 – API Access Control with OAuth/XACML Overview

Cyril DANGERVILLE, ThalesFI-WARE / WP8 / [email protected]


UC Requirement:GEs’ REST API Access Control

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!

FI-Ware Testbed

ServiceGE

IdMGEIdM

GE

ServiceGE

ServiceGE

ServiceGE

Client APP

Client APPGE


Sample scenario in OAuth context

Location GE(Resource Server)

Location TrackingWebApp

(Client App)

IdM GE• Registration Service

• Authentication Service• Oauth Authorization Service

User registers to the Tracking App. And allows the tracking app to retrieve the location data from location GE

12

3

6

5

4

User, Location Tracking webapp and Location GE have to be pre-registered at IDM GE.

(Resource Owner)


OAuth Authorization FrameworkIETF: 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 credentialsSecurity Issue 2: works well for password authentication onlySecurity Issue 3: 3rd party get same complete access to your

stuff as YouSecurity 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 dataResource Owner: delegates LIMITED resource access to 3rd party (Client

App) Client App: the 3rd party from the Resource Owner’s standpointResource Server (later referred as Target Service (GE)): hosts the

resourcesAuthorization Endpoint: issues Authorization Code that represents

resource owner granting access to 3rd party on his/her behalfToken Endpoint: issues Access Token in exchange for Authorization Code

(or refresh token), sent to the Resource Server to get access


XACMLeXtensible Access Control Markup LanguageFact: 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 HARDWhere to start? Common language for expressing security

policyOASIS 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


FIWARE API Access Control based on…IdM GE:Self-Registration/Self-Care ServiceUser & Service Administration ServiceAuthentication & SSO ServiceOAuth Services:

Authorization Endpoint -> resource owner’s authz grantToken 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 validationAttribute Finders provide attributes from various

sources, e.g.OAuth access token, such as JSON Web Token (JWT)IdM GE API for user attribute mgt


Solution for OAuth-UNaware PEP (option 1)


Example: Cloud WP

NSN/DT IdM

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

11 Access token

12 Access token + attrib

13 validation result + request info + attrib15 request

Oauth-Enabled Client App

Proxy

Keystone Middleware

9 request info + token

14 validation result + request info + attrib

KeystonePEP

Accounting + Monitoring

8


Solution for OAuth-aware PEP (option 2)


Solution for OAuth-aware/IdM-integrated PEP (option 3)


Example: Live Demo

11

IdM-like component

A

Thales RBAC/XACML Asset - B

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

Oauth-Enabled Client App

(simulation of call center backend)

C

Live Demo app backend

Proxy - D

6 Oauth access token

8 user role, verb

1. User & password

Configuration scripts - E

0 user role can do verb


http://fi-ppp.eu

http://fi-ware.eu

Follow @FIWARE #FIWARE-AZ on Twitter !

Thanks !

12

http://fi-ppp.eu/

http://fi-ware.eu/

FI-WARE OAUTH-XACML-based API Access Control - Overview (Part 1)

Software

party access

limited access

network access

complete access

resource ownergranting

issues access token

token12 access token

fiware api access control