Implementing UCON with XACML for Grid Services

1
Implementing UCON with XACML for Grid Services

• Bruno Crispo
• Vrije Universiteit Amsterdam
• OGF-25-Tutorial
• crispo_at_cs.vu.nl

2
Table of Content

• UCON in GridTrust
• eXtended Access Control XML (XACML)
• Language
• Run-time Support
• How we implemented in GridTrust
• Limitations and Extensions
• Multilateralism
• Performance

3
From Access Control to Usage Control
Rights
Subjects
Usage Decision (Authorizations)
Objects
4
From Access Control to Usage Control
Rights
Subjects
Usage Decision
Objects
Attributes
Attributes
Authorizations
oBligations
Conditions
5
Policies Examples

• Access Control policies
• Silver Users can use the service from 800 am
  till 800pm
• Managers can read and write Purchase Orders of
  the all Sales Department while Accountants can
  only write they own P.O.
• Users from Server A can run any experiment that
  uses at most 10GB of disk and 1 GB of RAM

6
Policies Examples

• Usage Control policies
• Silver Users can use the service only 5 times
  from 800 am till 800pm
• The SendOrder Service can be invoked only after
  the Log Service has been successfully invoked
• All mails sent outside the company must be
  encrypted
• All data related to a customer must be deleted
  when its account is deleted
• Users from Server A can run any experiment that
  uses at most 10GB of disk and 1 GB of RAM

History based
Workflow based
Obligations
Continuous monitoring
7
Policies Examples

• DRM policies
• (Pay Per Use) - The cost to see this movie is
  4.00
• (Metered Payment) - The cost to see this movie
  is 1/minute
• (Play n times) You can see this movie at most
  10 times

8
GridTrust Model
9
Components
Trust and Security for Next Generation Grids,
www.gridtrust.eu
10
Virtual Breeding Environment
VBE Manager
PKI
Virtual Breeding Environment
Trust and Security for Next Generation Grids,
www.gridtrust.eu
11
User SP Registration to a VBE
VBE Manager
SRB
PKI

• A Virtual Breeding Environment formed by users
  and different types of services.
• A VBE manager regulated the subscription of
  services and users to the VBE

Trust and Security for Next Generation Grids,
www.gridtrust.eu
12
VO Virtual Organizations
VBE Manager
SRB
PKI

• Any user (VO Owner) may initiate the process of
  creating a VO by looking for service providers
  she needs.

VO Manager
Trust and Security for Next Generation Grids,
www.gridtrust.eu
13
VO Virtual Organizations
VBE Manager

• The search and join is driven by service
  functionality and by security policy
• UCON policies, at this level written using XACML
• Service Resource Broker that implements a
  match-maker for XACML policies

PKI
VO
VO Manager
SRB
Trust and Security for Next Generation Grids,
www.gridtrust.eu
14
SRB Secure Resource Broker Service

• Service to match the security policy required by
  the VO with the policies exposed by service
  providers
• Supports XACML as a policy language
• It supports policy integration algorithms

Trust and Security for Next Generation Grids,
www.gridtrust.eu
15
VO Virtual Organizations
VBE Manager

• Users can register to use the VO. The
  registration consider also the security policies
  of both VO and User
• Support for UCON policies

PKI
VO
C-UCON
VO Manager
SRB
Trust and Security for Next Generation Grids,
www.gridtrust.eu
16
Enforcer

• A component used by the VO
• Optionally can be also a third party service
• Implement UCON policy at VO level
• E.g. Service1 can be invoked only after Service2
  has been invoked

Trust and Security for Next Generation Grids,
www.gridtrust.eu
17
VO Usage
Virtual Breeding Environment
VO
ENFORCER
VO user
Service2
Application
Service1
Service3
Trust and Security for Next Generation Grids,
www.gridtrust.eu
18
eXtendible Access Control XML (XACML)

• XML based access control language
• Simple Syntax, Strong Expressivity
• OASIS standard
• Widely adopted both in industry and academia
• Many implementations (both open source and
  proprietary)

19
XACML History

• First Meeting 21 May 2001
• Requirements from Healthcare, DRM, Online Web,
  XML Docs, Fed Gov, Workflow.
• XACML 1.0 - OASIS Standard 6 February 2003
• XACML 1.1 Committee Specification 7 August
  2003
• XACML 2.0 Approved February 2005
• XACML 3.0 Core Specification under review

20
Goals

• Define a core XML schema for representing
  authorization and entitlement policies
• Target - any object - referenced using XML
• Fine grained access control
• Consistent with and building upon SAML

21
XACML Key Aspects

• General-purpose authorization policy model and
  XML-based specification language
• Input/output to the XACML policy processor is
  clearly defined as XACML context data structure
• Extension points function, identifier, data
  type, rule-combining algorithm, policy-combining
  algorithm, etc.
• A policy consists of multiple rules
• A set of policies is combined by a higher level
  policy (PolicySet element)

22
XACML Syntax
23
XACML Example
Multimedia
Deny-Overrides
login
ana_at_xacml.org
VideoServer
Permit
UsersRegs
gt08h00 and lt17h00
the user ana_at_xacml.org can login on a Video
Server in the period between 0800AM and 0500PM
24
XACML Schemas
25
XACML Combination Algorithms

• Both at policy level and at rule level
• Used to compute decision result in case of
  policies/rules with conflicting effects
• rule lttargetgtltcond1..condngtlteffectgt
• rule1 ltany user,read,file1gtltin-range-time
  8-20gtltdenygt
• rule2ltjohn,read,file1gtltin-range-time
  10-12gtltpermitgt

• Permit-Override John can access
• Deny-Override John cant

Trust and Security for Next Generation Grids,
www.gridtrust.eu
26
XACML Combination Algorithms

• Similarly for policies

27
Problem Policy Integration

• If VO can always impose its policy, combination
  algorithms are enough
• Simple
• Not very flexible
• We want to increase flexibility to increase the
  chances service provider can join the VO
• Then we cannot impose but we need to integrate VO
  and service provider policies, thus combination
  algorithms are not enough.

28
Example

• VO Policy Any user with an email in the .edu
  or in the .gov domains can read any file.
  However, no access is allowed from 8am till 12am.
  Deny-Override
• SP policy Any user with an email in the .edu
  domain can perform any action on any resource. HP
  users can read any files from 8am till 10am.
  However, requests received between 8am till 6pm
  are denied Permit-Override

• Which combination algorithm to apply?

29
Example

• VO Policy Any user with an email in the .edu
  or in the .gov domains can read any file.
  However, no access is allowed from 8am till 12am.
  Deny-Override
• SP policy Any user with an email in the .edu
  domain can perform any action on any resource. HP
  users can read any files from 8am till 10am.
  However, requests received between 8am till 6pm
  are denied Permit-Override

• If Deny-Override ? HP users cannot read file from
  8am till 10am

30
Example

• VO Policy Any user with an email in the .edu
  or in the .gov domains can read any file.
  However, no access is allowed from 8am till 12am.
  Deny-Override
• SP policy Any user with an email in the .edu
  domain can perform any action on any resource. HP
  users can read any files from 8am till 10am.
  However, requests received between 8am till 6pm
  are denied Permit-Override

• If Permit-Override ? VO may not be happy that HP
  users and .edu domain can violate its policy

31
Propose integration algorithms

• Stakeholders specify combination algorithms and
  also which compromise they are willing to accept
  if they offer their service to a VO
• Step1 Normalize policy (First-one applicable)
• Step2 Compute policy similarity
• Step3 Specify integration preferences

32
Policy similarity
Ri Rj
Ri
Rj

Ri
Rj

Rj
Ri
Ri
Rj
33
Policy Integration Preferences

• VO point of view
• Converge Override
• VO enforces only its unchanged policy
• Restrict Override
• VO enforces also SP policies that do not deny its
• Deny Override
• VO enforces also SP policies. Request permitted
  only if all permit it
• Permit Override
• VO enforces also SP policies. Requested permitted
  if at least one permit it

• SP point of view
• Restrict Override
• SP accepts that only a subset of its accepted
  requests will be accepted by the VO
• Extend Override
• SP accepts requests it doesnt accept will be
  accepted by the VO
• Converge Override
• SP demands that its unchanged policy is enforced
  by the VO

34
Policy Integration Preferences
SP
VO
35
XACML Runtime Support

• The Policy Administration Point (PAP) stores
  XACML policies in the appropriate repository.
• The Policy Enforcement Point (PEP) performs
  access control by making decision requests and
  enforcing authorization decisions.
• The Policy Information Point (PIP) serves as the
  source of attribute values, or the data required
  for policy evaluation.
• The Policy Decision Point (PDP) evaluates the
  applicable policy and renders an authorization
  decision.
• Note The PEP and PDP might both be contained
  within the same application, or might be
  distributed across different servers

36
Evaluation Workflow
VO User
Obligations service
PEP (DKM )
PDP
Context Handler
Resources Attribute Manager
PIP
PAP
Environment Attribute Manager
Subjects Attribute Manager
37
Our implementation in GridTrust
Virtual Breeding Environment
VO
ENFORCER
P E P
Service2
VO user
Service1
Service3
Trust and Security for Next Generation Grids,
www.gridtrust.eu
38
Enforcer

• Extension of SUN XACML PDP to support UCON at VO
  service level
• At the moment covers only a subset of the XACML
  specifications
• In case of denial respond with the rule that
  caused the deny
• Rollback

Trust and Security for Next Generation Grids,
www.gridtrust.eu
39
Enforcer (Extended PDP)
APPPLICATION (PEP)
Allow?
Yes/No/Delay/Modify/N/A

• OAM Object Attribute Manager
• SAM Subject Attribute Manager
• HM History Manager
• CM Consition Manager
• OM Obligation Manager

PDP
OAM
SAM
HM
CM
OM
Enforcer
B. Crispo
TNO Groningen - 16-10-2008
39
40
Why PDP Performance is Important?

• PDP is critical for the overall performance of
  authorization service
• The proliferation of service oriented
  applications
• S3-like services will face enormous amount of
  requests requiring authorization decisions

41
Experiments

• PDP Tested Sun XACML, XACML Enterprise,
  XACMLight
• Two phases have been tested
• Policy Load Loading of policy/policies from
  disk to main memory.
• Policy Evaluation Request evaluation against
  loaded policies.
• Environment 3.4 GHz Pentium IV CPU, 2GB RAM,
  160 GB Serial ATA (7200 rpm) HDD
• JVM heap size 256 MB - 1024MB

42
Policy Test Suite

• Three policy test suites (syntetic policies)
• Large Number of Policies 10, 100, 1000 and 10000
  XACML policies composed of 4 rules.
• Large Number of Rules 10, 50, 100, 500 and 1000
  rules in a single policy.
• Policy Similarity 10 policies with different
  similarity settings

43
Large Number of Policies

• In enterprise/cross-enterprise systems
• With large number of entities eager to specify
  access control policies
• With shared PDP services
• 1 request is evaluated against 10, 100, 1000 and
  1000 policies at a time.

44
Large Number of Policies
Policy Load
45
Large Number of Policies (Cont.)
Policy Evaluation
46
Large Number of Rules

• A single organization
• With large number of users and resources
• Single Point of Control
• 1 request is evaluated against 10 policies with
  10, 50, 100, 500, 1000 rules inside

47
Large Number of Rules
Policy Load
48
Large Number of Rules (Cont.)
Policy Evaluation
49
Ongoing Work

• Extend the enforcement by reaction, extending the
  obligation
• Integrating security policy Match-making with
  Resource Allocation/Scheduling
• Improve performance acting both on loading time
  (more efficient policy representation) and
  evaluation time (more efficient evaluation
  algorithms)
• Considering Continuous Monitoring at service
  level for some specific applications