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

DecisionApplication

Administration

PolicyRepository

PEP

Enforcement

Client

AuthoritiesAttribute

Repositories

PDP

PDP 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• http://issuu.com/divaybansal/docs/master-th

esis• If nothing else it demonstrates how XACML

can implement key-dependancies policies• Alternative architectures