all FREECO11-workshop-papers.pdf - trese

More documents

Recommendations

Info

the corresponding rules. Policy assertions relating to differentsecurity concerns are tangled in one rule, such as theseverity level for privacy (line 6) and the encryption algorithmfor confidentiality (line 7). Policy assertions relatingto one security concern are scattered over multiple rules,such as the encryption algorithm BlowFish (lines 7 and 16).Tangling and scattering leads to poor maintainability of thepolicy specification due to crosscutting concerns.What is needed for modularizing tangled policies are languagemechanisms that help to encapsulate and disentanglenon-functional concerns in a clear and concise way.2.4 Policies Lack Integrating FormalismsPolicies express different goals. Like these goals vary, so dotheir representations in policy languages that specify them.Generally, different policy languages do not share a commonsyntax, even if they are based on the same fundamental representationaltechnology, such as XML (e.g. WS-Policy) orEBNF (e.g. Ponder [2]). Furthermore, policy statementsare adapted to the concepts underlying the specificationparadigms, with each policy supporting a single paradigm,and thus formalism. This limited view is insufficient whendealing with distributed business applications. A holisticspecification of the system’s behavior requires a combinationof views of the complete system. Because different representationsand formalisms have various degrees of powerregarding the description of these views, it is difficult to determinea single, ideal language suited to their expression.What is needed for policies are methods for integratingdifferent paradigms addressing different views of the system.3. OVERVIEW OF RELATED WORKCurrent policy languages only support one concrete syntaxthat supports only a limited set of security formalismsand paradigms. Existing languages are not open for newsyntax and semantics, which is what new formalisms andparadigms would require. They do not support policies likethose discussed in Section 2.1–2.4 because they all share theinsuffiencies that policies are not semantically flexible, notprecisely scoped, contain scattered and tangled code fragments,and adherent to one paradigm only.Ponder [2] is an object-oriented policy language with avery basic support for controlling the effects of policies inpolicy groups, but particularly it neither supports full-fledgedlexical nor dynamic scoping.WS-Policy 1 is a XML-based policy language frameworkthat allows integrating new domain-specific policy languageswith an XML-based syntax, but in particular concrete syntaxis not supported.XACML 2 is an XML-based and rule-based policy languagefor defining attributes the specification of authorizationpolicies and obligations. Specifically, but policies for abehavioral specification of a component (e.g. security automata)are out of scope.What is needed is an extensible policy language that userscan tailor for the specific requirements of their business application.So that, for such a policy language, they can selectthe right concrete DSL syntax, composition mechanisms, securityformalisms, or paradigms that they want to use, tobe included into their policy language.1 WS-Policy: www.w3.org/TR/ws-policy2 XACML: www.oasis-open.org/committees/xacml4. INTRODUCING COMPOSITION MECH-ANISMS INTO POLICY LANGUAGESIn order to overcome the limitation of existing policy languagesdiscussed in Section 2, we propose to make compositionmechanisms from programming languages available inpolicy languages. Specifically, we consider adapting polymorphyand scoping for meeting the need of policy languagefor semantic flexibility. Furthermore, we propose the use ofaspects for addressing scattered and tangled policy definitions,and an open set of paradigms to define policies withthe right syntax and semantics. In the following, we presentexample solutions in WSPL, however WS-Policy or anotherpolicy language could be extended with the same mechanismsin a similar manner.4.1 PolymorphyTo enable flexible policies, we propose to extend the policylanguage with an inheritance mechanism that is similarto polymorphic programming languages. The inheritancemechanism enables the end users to refine the rules of abase policy in an extended policy.1 Policy (Id = ”Service−Levels”) {2 Rule { Trust = ”High”,3 Options = { ”Pre−Paid”, ”Credit−Card”, ”Invoice” }}4 ...5 Rule { Trust = ”Low”,6 Options = { ”Pre−Paid” }}7 }Listing 5: Base of a polymorphic policyFor example, Listing 5 and Listing 6 show two modularpolicies, where the latter policy extends the former – likea subclass extends its super class. Listing 5 shows the basepolicy Service-Levels that defines the payment options fordifferent trust levels. Listing 6 shows the policy extensionSpecific-Service-Levels that defines what Low trust orrespectively High trust means. Note that, even when differentstakeholders define those policies at different timesor in different sub-systems, the policy extension Specific-Service-Levels can refine what Low or High trust meansfor the Service-Levels base policy.1 Policy (Id = ”Specific−Service−Levels”) {2 Extends ( Super = ”Service−Levels” )3 Rule { Location = ”Germany”, Experience−Level = ”Good”,4 Experience−Length = ”Long”, Trust = ”High” }5 Rule { Location = ”USA”, TPM−Available = True,6 Platform−Monitor = ”Deployed”, Trust = ”High” }7 ...8 Rule { Trust = ”Low” }9 }Listing 6: Extension of a polymorphic policyWe expect that having an inheritance mechanism availablein policy languages, we can provide policy developers withsimilar advantages as having OO inheritance w.r.t. extensibility,reusability, and modular reasoning. However, it is achallenge to provide such an inheritance mechanism for anopen set of policy dialects. On the one hand, the inheritancemechanism need to define a default polymorphic semanticsthat allows to refine policies by overriding parts of them at
the level of assertions. On the other hand, the inheritancemechanism needs to be extensible for special cases in whichit must take into account the specific semantics of a policydialect. While we expect that end users can use the defaultpolymorphic semantics for most cases, only an extensibleinheritance mechanism enables domain-specific compositionsemantics for composition.4.2 ScopingTo precisely scope policies, we propose to support differentscoping schemes in the policy language. Every scopedescribes a partial view of the system that is structured indifferent topologies, such as an organizational or a technicaltopology, of which several topological views can overlap. Todefine a new scope, there is a special operator Scope with:(1) an Id that defines a unique identifier for the scope withina topology, (2) a scoping Strategy that defines how the definedelements in its body propagate, and (3) a Priorityfor resolving conflicts between overlapping scopes. Insidethe scope operator, a nested policy defines a binding forthat policy in this scope.Depending on the topological view and the scoping strategy,the contained bindings can propagate to other scopes orparts of the system. With lexical scoping, elements of an enclosingscope propagate to its nested scopes. With dynamicscoping, the definition of an element always establishes anew binding that propagates globally through all scopes.For example, Listing 7 shows several policies that are nestedinside different scopes. The corresponding Scope operatorsselect the right scope and strategy for the nested policiesthat all have the same Id. Since there are different scopesdefined for the policies, there is no name clash between them.The first two scopes allow defining the Key-Length policydifferently for the two companies Organizational.MarketX.Company1with 1024 bits (lines 3–9) and Organizational.MarketX.Company2with 512 bits (lines 10–14). BecauseCompany1 uses a lexical scoping strategy, it is possibleto redefine the policy within a certain department (e.g., Dep1with 2048 bits). There is another scope that defines a specialKey-Length policy for devices with limited resources.There are two dynamic policies that impose restrictions onthe maximum key length, namely 256 bits when using thealgorithms to communicate with sensor nodes, and 128 bitswhen the systems detects that the battery of a mobile sensordevice is low. Each scope implicitly binds the policies thatare nested into it body.Alternative, one can explicitly define the scope of a policyby using the policy operator’s optional Scope attribute.For example, the policy in line 7 redefines the Key-Lengthpolicy. Because the policy is explicitly scoped to Organizational.MarketX.Company1.Dep1through the Scope attributeof the policy, however this only overrides the bindingof this policy within the department Dep1 of Company1.When scopes of different topologies overlap, there canbe multiple bindings for one policy Id. Consider a subcomponentthat is part an organizational topology elementCompany1 and part of a technical topology Technical.NetworkA.SensorNodes.In Listing 7, there are different policiesdefined for this sub-component by the two scopes Organizational.MarketX.Company1and Technical.NetworkA.SensorNodes.Therefore, it is necessary to resolve such conflictingbindings. To resolve such conflicts, we always select thebinding from the scope with the higher priority.1 Scope (Id = ”Organizational.MarketX”,2 Strategy =”Lexical”,Priority=”Normal”) {3 Scope (Id = ”Company1”, Strategy =”Lexical”){4 Policy (Id = ”Key−Length”) {5 Rule {6 Key−Length = ”1024−bit”7 Policy (Id = ”Key−Length”, Scope = ”Dep1”) {8 Rule { Key−Length = ”2048−bit” }9 }}}}10 Scope (Id = ”Company2”) {11 Policy (Id = ”Key−Length”) {12 Rule {13 Key−Length = ”512−bit”14 }}}}1516 Scope (Id = ”Technical.NetworkA.SensorNodes”,17 Strategy = ”Dynamic”, Priority=”High”) {18 Policy (Id =”Restricted−Key−Length”) {19 Rule { Key−Length = ”256−bit”, Transport = ”GPRS” }}20 Policy (Id = ”Quality−of−Protection”) {21 Rule { Key−Length = ”128−bit”, Battery = ”Low” }}22 }Listing 7: A policy using different scoping schemes4.3 AspectsIn order to disentangle crosscutting concerns in modernOO programming languages, aspect-oriented approaches[7, 6] have gained attention. Aspects provide designatedmeans for encapsulating (non-functional) crosscutting concerns.Transferring aspect-orientation, including its conceptsof pointcuts and advice, to policy languages offers usersand developers a convenient and familiar solution for dealingwith tangled and scattered assertions in policies.Listing 8 presents a way of disentangling the scattered policycriticized in Section 2.3. Each pointcut defines a patternover rules and assertions where the advice defines what assertionsit adds to the matching rules. Introducing aspectsexplicates statements and bindings, as well as distinguishingfunctional from non-functional segments of a policy. Furthermore,the presented solution can avoid ambiguities usingexplicit execution order via priorities (e.g. line 24), whichenables a better composability of different policy fragments.Aside from integrating easily accessible constructs familiarfrom AOP, policies can also be empowered through user definedfunctions, such as the NOT(ME) statement presented inthe above listing. Here, NOT negates the predicate ME; MErefers to a provider that defined the above policy – thus theexpression NOT(ME) matches all services not operated by theprovider.4.4 Multi-Paradigm InterpretationEmpowering policies with the interpretation of multipleparadigms allows them to incorporate different formalismscovering possibly orthogonal system views. It also givesusers and developers more freedom to specify facets of a policyin the constructs they deem most appropriate—regarding,for instance, usability, understandability or brevity—for coveringall pertinent facts of the view covered.The preceding policy fragment in listing Listing 9 illustratesthe integration of different policy constructs, i.e. aFinite State Machine and a Ponder [2] role-based access controlstatement, into a generic WSPL [1] policy. This permitsaccess to primitives from policy languages that weredesigned to specify a specific system functionality withina joint generic context. What is special in such a com-
Page 1 and 2: FREECO-11Table of ContentsTable of
Page 3: 1 Policy (Id = ”Service Levels”
Page 7 and 8: An association-based model of dynam
Page 9 and 10: that, when substituted back into r
Page 11 and 12: This suggests using the association
Page 13 and 14: class-based languages like Java and
Page 15 and 16: • The keywords final in Java, con
Page 17 and 18: Composing heterogeneous software wi
Page 19 and 20: 3. APPROACHOur approach consists of
Page 21 and 22: example, the naming convention we s
Page 23 and 24: 2. We present a novel approach and
Page 25 and 26: CG Template 1CG Template 2...CodeSl
Page 27 and 28: Open, extensible composition models
Page 29 and 30: (define eval (lambda (exp env)(appl
Page 31 and 32: defined to combine values into comp
Page 33 and 34: • a proof that the model transfor
Page 35 and 36: have been proposed that allow parts
Page 37 and 38: FREECO-11Author IndexAuthor IndexBe

all FREECO11-workshop-papers.pdf - trese

Create successful ePaper yourself

Delete template?

Save as template?