Presentation is loading. Please wait.

Presentation is loading. Please wait.

Authorization PDP GE Course (R4) FIWARE Chapter: Security FIWARE GE: Authorization PDP FIWARE GEri: AuthZForce Authorization PDP Owner: Cyril Dangerville,

Similar presentations


Presentation on theme: "Authorization PDP GE Course (R4) FIWARE Chapter: Security FIWARE GE: Authorization PDP FIWARE GEri: AuthZForce Authorization PDP Owner: Cyril Dangerville,"— Presentation transcript:

1

2 Authorization PDP GE Course (R4) FIWARE Chapter: Security FIWARE GE: Authorization PDP FIWARE GEri: AuthZForce Authorization PDP Owner: Cyril Dangerville, Thales Services

3 Authorization PDP GE Overview  Multi-tenant RESTful API for…  Attribute-based Access Control (ABAC) Policy Decision Point:  PDP (Policy Decision Point) interprets authorization policies  PDP evaluates authorization decision requests from PEPs (Policy Enforcement Points), e.g. FIWARE PEP Proxy GE, against the policies, and returns decision responses to them  Access Control Policy Administration  PAP (Policy Administration Point) for managing policies to be enforced by the PDP  Policies may reference each other for reuse/inheritance, e.g. hierarchical RBAC  Each tenant (aka domain) = 1 PDP, 1 PAP, N (>=1) policies  OASIS XACML 3.0 standard for policies and decision requests/responses

4 XACML 3.0 Standard Overview  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 enterprise policy (including “best practices”) in access control is VERY VERY HARD  Where to start? Common language for expressing security policy  OASIS standard: eXtensible Access Control Markup Language  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):  Subject(s) S (attributes) can do Action(s) A (attributes) on Resource(s) R (attributes) in given Environment E (attributes), provided some Condition(s) on Subject/Action/Resource/Environment attributes are met  Policy Administration Point (PAP)  Policy Enforcement Point (PEP):  Protects the resource, i.e. intercepts request and asks PDP for permission before letting it through  Not part of Authorization PDP, but there is FIWARE PEP Proxy GE for example

5 XACML Data Model  PolicySet  PEP’s Request:  Attributes (category = subject)  Attribute id=“subject-id”, values = … (datatype = anyURI)  Attribute id=“subject-role”, values = … (datatype = string)  …  Attributes (category = resource)  Attribute id=…, values =… (datatype = …)  Attributes (category = action)  Attributes (category = …)  PDP’s Response:  Decision: Permit/Deny/Indeterminate/…  Obligations: orders given to PEP (send an alert to some admin, log the access request somewhere, etc.)

6 XACML extensibility points  Attribute categories (XACML 3.0 only) and identifiers  Obligations  Other extensions that require extra PDP features  Datatypes  Functions  Policy/Rule Combining algorithms  Profiles: standardized sets of above extensions and special evaluation logic….  RBAC profile for supporting RBAC policies in XACML  Multiple Decision Profile  Etc.

7 XACML 3.0 vs 2.0: Why you should upgrade More advanced and flexible Target matching capabilities Custom attribute categories (limited to Resource, Action, Environment and a few Subject categories in v2.0) Dynamic Obligations using variables evaluated at runtime (limited to static values in v2.0) from request context after possible transformations by XACML functions Obligations in Rules (limited to Policies and PolicySets in v2.0)

8 REST API (1/2)  Each domain/tenant has a PAP for managing policies: /domains/{domainId}/pap  Add a policy (a version of a policy)  POST /domains/{domainId}/pap/policies  Body: XACML  Get a version of a policy (e.g. v1.0 of policy P1)  GET /domains/{domainId}/pap/policies/P1/1.0  Remove a version of a policy  DELETE /domains/{domainId}/pap/policies/P1/1.0  Get all versions of a policy  GET /domains/{domainId}/pap/policies/P1  Remove all versions of a policy  DELETE /domains/{domainId}/pap/policies/P1

9 REST API (2/2)  Policy references:  Policy P1 (v1.0) available: /domains/{domainId}/pap/policies/P1/1.0  Add Policy P2 referencing P1: POST /domains/{domainId}/pap/policies … P1 …  ‘Version’ is optional in the reference (latest version used if none specified)  Each domain/tenant has a PDP for requesting authorization decisions  PDP needs a root policy to know where to start  Reference to root policy set in domain properties with: PUT /domains/{domainId}/properties Body: domainProperties (rootPolicyRef, etc.)  PEPs send authorization decision requests with:  POST /domains/{domainId}/pdp  Body: XACML Request  Response: XACML Response

10 Authorization PDP GE Reference Implementation: AuthZForce XACML 3.0 support: Mandatory features of Core specification Core and Hierarchical RBAC profile Multiple Decision Profile, scheme of §2.3 only (repeated attribute categories) Packaging: Debian/Ubuntu.deb package Docker container More info on the FIWARE catalogue: http://catalogue.fiware.org/enablers/authorization-pdp- authzforce

11 Q & A Thanks for your attention


Download ppt "Authorization PDP GE Course (R4) FIWARE Chapter: Security FIWARE GE: Authorization PDP FIWARE GEri: AuthZForce Authorization PDP Owner: Cyril Dangerville,"

Similar presentations


Ads by Google