Combining KMIP and XACML

What is XACML? XML language for access control Coarse or fine-grained Extremely powerful evaluation logic Ability to use any available information Superset of Permissions, ACLs, RBAC, etc Scales from PDA to Internet Federated policy administration OASIS and ITU-T Standard

Key XACML Features Federated Policy Administration – Multiple policies applicable to same situation – Combining rules to resolve conflicts Decision may include Obligations – In addition to Permit or Deny – Obligation can specify present or future action – Examples: Log request, require human approval, delete data after 30 days Protect any resource – Web Server, Java or C++ Object, Room in building, Network Access, Web Service, Geographic Data, Health Records, etc.

XACML Benefits Standard Policy Language – Investment protection – Skills reuse Leverage XML tools Policy not in application code – Reduce cost of changes – Consistent application – Enable audit

XACML Architecture PDP Decision Application Administration Policy Repository PEP Enforcement Client Authorities Attribute Repositories PDP Resources

Policy Evaluation in Brief - 1 Attribute-based access control (ABAC) Attributes associated with Subject(s), Action, Resource or Environment Attributes may represent static (Group) or dynamic (# of accesses) properties PDP is stateless Policies contain Boolean expressions If false, policy is not applicable If true, Effect (Permit or Deny) is returned

Policy Evaluation in Brief - 2 Combining Algorithms resolve conflicting policy results – Typical: Deny Overrides Obligations which are associated with final Effect are also returned Policies are tree structured to simplify management

Reasons for KMIP Servers to Use XACML Implement more complex key relationship policies – Dependancies: derived key, wrapped key, split key Enhance policies to meet Enterprise needs – Other Subject attributes (Roles) – Environmental attributes – Privacy or contractual requirements

What to consider Not Policy structure (this would be necessary with RBAC for example) Attributes What ones may be needed Where will the come from How will they get to PDP Interface – Remote/Local – Protocol/API

Attributes Datatypes – XACML defines 14 scalar types – KMIP types are a subset – Commonly used are easy, e.g. string Access – With decision request – KMIP request – Other request, e.g. LDAP KMIP must maintain dynamic values

Interfaces PDP may be remote or imbedded Tradeoff is ease of integration vs. performance – Most KMIP servers relatively low decision volume Remote call via SOAP defined by XACML – Clearly the easiest to implement OpenAz open source project is defining APIs Defining a TTLV remote call is possible

Excellent paper on this subject Masters thesis by Divay Bansal IBM / ETH Zurich thesis thesis If nothing else it demonstrates how XACML can implement key-dependancies policies Alternative architectures