review of distributed databases. students presentations csce 824 - farkas 2

Review of Distributed Databases

Students presentations

CSCE 824 - Farkas 2

Textbook Reading

Chapter 1: Introduction Chapter 2: Background on Relational DBMS

Also, lecture materials from CSCE 520 Chapter 3: Distributed Database Design –

top-down approachMain concepts, approaches, advantages,

disadvantages

Farkas CSCE 824 - Spring 20113

Summary cont.

Chapter 4: Database Integration – bottom-up approach

Understand main concepts, difficulties, and supporting technologies

Chapter 5: Security Concepts Also, lecture notes from CSCE 522

Chapter 10: Transaction Management Main concepts, ACID properties, (no 10.3)


Summary cont.

Chapter 11: Concurrency control 2PL, lock types, deadlock management (no

specifics about TO alg.)

Chapter 12: reliability 2PC, site and communication failures, window of

uncertainty

Chapter 13: replicated databases Goals, issues, types of replica control alg. ,

advantages, disadvantages


Test 1 – Question Type 1. Relate concepts to current technologies

Chapter 3: fragmentation, allocation: how do these concepts relate to grid or service oriented computing; what are the security issues related to these concepts?

Chapter 4: data integration: what are the current trends related to integration? How do ontologies support semantics-based integration? Web data dynamics and integration correctness.

CSCE 824 - Farkas 6

Test 1 – Question Type 2.

Apply concepts to a particular problem Assume you are using 2PL to ensure serializability.

How can we extend the model to handle transactions with different security levels?

Suggest a modification to 2PC to make it more efficient (less log forces or/and less number of messages) but still correct.

Find a current P2P architecture that uses data replication. Evaluate the type of replication used and suggest improvements.

CSCE 824 - Farkas 7

Test 1 – Question Type 3.

Suggest unsolved research problems: Given an area of the distributed databases covered in

the lectures, identify a research problem that is not solved sufficiently. Justify your solution by describing a motivating example. E.g., the problem of … has been studied in the context of …. However, the current solutions are not sufficient to support … because …. For example, <give an example here>.

CSCE 824 - Farkas 8

Test 1– Question Type 4.

A particular exercise from the textbook,E.g., 3.3, 3.15,3.16, 4.2, 4.3, 4.6, 4.7, 4.12,

5.4, 5.6, 5.7, 5.9, 11.12, 13.1, 13.3, 13.4

CSCE 824 - Farkas 9

Test 1

Given 4 questions, choose 3 to solve Date: Oct. 28-Oct. 31

CSCE 824 - Farkas 10

Security Policies


Security Policies

Reading

Text book Chapter 5

Jajodia et al., Flexible Support for Multiple Access Control Policies, http://www.cacs.louisiana.edu/~jyoon/grad/adb/References/secpap/multi-ac-conflict01tods.pdf

Recommended

XACML 2.0 core spec., http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-

core-spec-os.pdf

CSCE 824 - Farkas13

Policy, Model, Mechanism

Policy: High-level description Model: formal representation – proof of

properties Mechanism: low-level specifications

Separation of policy from the implementation!

CSCE 824 - Farkas14

System Architecture and Policy

Simple monolithic system Distributed homogeneous system

under centralized control Distributed autonomous systems

homogeneous domain Distributed heterogeneous system

Complexity Of

Policy

CSCE 824 - Farkas15

Traditional Access ControlTraditional Access Control

Protection objects: system resources for which protection is desirable

– Memory, file, directory, hardware resource, software resources, etc.

Subjects: active entities requesting accesses to resources

– User, owner, program, etc.

Access mode: type of access– Read, write, execute

CSCE 824 - Farkas16

Access Control Models Have been around for a while:

Access Control Models: Discretionary, Mandatory, Role-Based

Concepts: Negative Authorization, Delegation, Revocation, Temporal

Relatively new:Access Control Models: Usage-Based,

Capabilities(attribute)-Based, Organizational, Workflow

Concepts: Emergency, Obligation, Provision, Spatial information

CSCE 824 - Farkas17

Negative Authorization

Traditional systems: Mutual exclusion New systems: combined use of positive

and negative authorizationsSupport exceptionsProblems: How to deal with

Incompleteness – Default policy Inconsistencies – Conflict resolution

CSCE 824 - Farkas18

Conflict Resolution

Denial takes precedence Most specific takes precedence Most specific along a path takes precedence Priority-based Positional Grantor and time-dependent Single strategy vs. combination of strategies

CSCE 824 - Farkas19

Policy Specification Language

Express policy concepts Required properties of policy languages:

Support access control, delegation, and obligation Provide structuring constructs to handle large systems Support composite policies Must be able to analyze policies for conflicts and

inconsistencies Extensible Comprehensible and easy to use

CSCE 824 - Farkas20

Policy Specification Language Approaches

Logic-based approach Adv: Precise and expressive Disadv: not intuitive, difficulty and complexity of implementation e.g., Jajodia et al., A logical language for expressing authorizations,

1997 Graphical approach

Adv: supports visual understanding Disadv: Scope is limited E.g., Hoagland et al., Security Policy Specification using a Graphical

Approach, 1998 Event-Based language

Adv: clear semantics and architecture Disadv: limited scope E.g.,Lobo et al., A Policy Description Language, 1999

Object-Oriented, declarative language Adv: clear semantics, expressiveness, easy to use Disadv: support of domain specific semantics E.g., Damianou et al., The Ponder Policy Specification Language, 2000

CSCE 824 - Farkas21

Flexible Authorization Framework (FAF)

Logic-based An authorization is of the form s,o,<sign>a An authorization specification AS consists of a set of:

authorization cando (base facts, non-recursive rules) derivation dercando (conditional facts, recursive rules) conflict resolution do (avoiding over/under specification) history done Hierarchical (hie-) and application specific (rel-)

predicates Integrity error predicate symbols

Copyright: slides on FAF are from Dr. D. Wijesekera, GMU

CSCE 824 - Farkas22

Functional Architecture

PropagationPolicy

Conflict Resol.+

Decision Policy

IntegrityConstraints

HistoryTable

AuthorizationTable

USER

o,s,+a

DECISION

CSCE 824 - Farkas23

Authorization Rules

cando(o,s,<sign>a) L1 … Ln

o objects subject<sign>a signed actionL1 … Ln are done, hie- or rel- literals

CSCE 824 - Farkas24

Authorization Policy Collection of rules Closed policy example:

dercando (u,o,+a) cando(s,o,+a) in(u,s)do (u,o,+a) dercando(u,o,+a)do (u,o,-a) do(u,o,+a)

error(s,o,a) cando(s,o,-a)

CSCE 824 - Farkas25

Denials-take-precedence

do (u,o,-a) dercando(u,o,+a) dercando(u,o,-a)

do (u,o,-a) do(u,o,+a)

CSCE 824 - Farkas26

Static Separation of Duty

error() do(s,budget,submitting) do(s,budget,evaluating)

do(s,budget,approving) .

CSCE 824 - Farkas27

Revoking Permissions Granted permissions have to be revoked. Semantics and representational issues

Policy 1:cando(s1,o,+a) .

dercando(s2,o,+a) <- cando(s1,o,a)

Policy 2:cando(s1,o,+a) .

cando(s2,o,+a).

If s1’s permission a on o is revoked, should s2 still have permission a on o?

CSCE 824 - Farkas28

Provisions and Obligations

Yes/no response to every request is just not enough

Provisions: Conditions to be satisfied before permission is considered

Obligations: Conditions to be fulfilled as a consequence of accesses

CSCE 824 - Farkas29

Example: Electronic Loan Application

Provisions: Registered account holderEither already registered or register now!Some actions need to be taken in order to

satisfy the obligations Conditions:

Have a good credit historyMakes enough money to pay back

Then, the bank sells the loan

CSCE 824 - Farkas30

Example continued Obligations

Customer needs to make up her mind in a week

Agree to abide by following conditions1. Have to pay an installment every month by the

due date

2. If not, have to pay installment+surcharge within two weeks grace period

3. Failing (2), the loan will be cancelled and property re-processed.

CSCE 824 - Farkas31

Representation of the Problem

Extend access control policies with provisions and obligations.

Provisions and obligations are constructed from conjunctions and disjunctions of literals.

CSCE 824 - Farkas32

Representation of the Problem

Extend access control policies with provisions and obligations.

Provisions and obligations are constructed from conjunctions and disjunctions of literals.

CSCE 824 - Farkas33

Example Provisions

1. cando(customer,loan,read) <-

Prov: register(customer)

2. cando(customer,loan,apply) <-

cando(customer,loan,read),

Prov: signedLetterOfIntent(customer,loan)

CSCE 824 - Farkas34

Delegation Policies

Supports temporary transfer of access rights Must be tightly controlled by security policy Always associated with authorization policy Not intended for security administrators Constraints! New area: delegation of obligations

CSCE 824 - Farkas35

Policy Development

Policy maker:Start with high-level policies Refine high-level policies to low-level policy

specification Determine resources required to satisfy the policy Translate high-level policies into enforceable versions Support analysis that verifies that lower level policies

actually meet the needs of higher level ones.

CSCE 824 - Farkas36

Policy Refinement Bandara, et al.: Policy Refinement for IP Differentiated

Services Quality of Service Management., IEEE eTransactions on Network and Service Management 3(2) (2006) 2–13“

Def.: If there exists a set of policies P ={P1, P2, ... ,Pn}, such that the enforcement of a combination of these policies results in a system behaving in an identical manner to a system that is enforcing some base policy P, it can be said that P is a refinement of P. The set of policies P ={P1, P2 .. Pn} is called the refined policy set.” (Bandra)

CSCE 824 - Farkas37

Policy Refinement Properties

A policy refinement is complete iff: Correct: there is a subset of the refined policy set

such that a conjunction of the subset is also a refinement of the base policy

Consistent: there are no conflicts between any of the policies in the refined policy set

Minimal: if removing any policy from the refined policy set causes the refinement to be incorrect

CSCE 824 - Farkas38

Policies for Integrated, Heterogeneous Systems Providing Security and Interoperation of Heterogeneous

Systems” by S. Dawson, S. Qian, and P. Samarati; in Distributed and Parallel Databases, vol. 8, no 1, January 2000 (http://homes.dsi.unimi.it/~samarati)

eXtensible Access Control Markup Language (XACML) Demand for information sharing

Heterogeneous systems Local access control Need interoperation

CSCE 824 - Farkas39

Automated Policy Translation Architecture

Automated Translation Modules

OtherATM

Unified Security Policy in ASL

SecurityPolicy

1

SecurityPolicy

2

SecurityPolicy

n

ACLATM

BLPATM

CSCE 824 - Farkas40

Mediation-based Databases

• Mediator provides controlled accesses to local databases (resources)

• No need for federated schema and multi-database language

CSCE 824 - Farkas41

Mediation-based Interoperation Architecture Security policy specifications

Application and source security lattices Correctness of specifications: consistency, non-

ambiguity, non-redundancy Access control

Mediator: accesses on virtual relation – limiting the number of applicable rules

Local sources: on local data (labeled) and translated application user label

XACML Slides from Audumbar at

http://ebiquity.umbc.edu/resource/html/id/259/Tutorial-on-XACML The XACML standard provides

Policy Language Request and Response Language Standard data-types, functions, combining algorithms Extensibility Privacy profile, RBAC profile An architecture defining the major components in an

implementation


Terms Resource: Data, system component or service Subject: An actor who makes a request to access certain

Resources. Action: An operation on resource Environment: The set of attributes that are relevant to an

authorization decision and are independent of a particular subject, resource or action

Attributes: Characteristics of a subject, resource, action or environment

Target: Defines conditions that determine whether policy applies to request


XACML Data Flow


Policy Structure


Policy Language Model


Request


Request

SubjectAttributes

ActionAttributes

EnvironmentAttributes

ResourceAttributes

Response


Response

Decision ObligationsStatus

Combining Algorithms

Deny overrides Permission overrides First applicable Only one applicable References:

OASIS XACML Technical Committee Home Page

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

Sun's XACML Open Source Implementation

http://sunxacml.sourceforge.net/


Next class

The inference problem


review of distributed databases. students presentations csce 824 - farkas 2

Documents

coresp csce

question type

approachmain concepts

data integration

database integration

type of replication

security issues

integration correctness