230 likes | 364 Vues
This paper presents a novel approach to composing security policies for web services using defeasible logic. Traditional security policies can be complex, governed by multiple entities, and challenging to merge. Our method utilizes defeasible reasoning to create a clear framework for integrating these policies, allowing for flexibility and adaptability. By defining meta-policies and implementing a composition function, we ensure that resulting policies meet the requirements of all entities involved, thus enhancing the overall security landscape of web services.
E N D
Defeasible Security Policy Composition for Web Services Adam J. Lee, Jodie P. Boyer*, Lars E. Olson, and Carl A. Gunter University of Illinois at Urbana-Champaign 3rd November 2006
Motivation • Security policies • Tend to be large and difficult to understand • Do not always have a well-defined means of composition • May be governed by multiple organizations or entities • Can we provide an intuitive way to specify and compose security policies? • Approach: Defeasible security policy composition
What is Defeasible Logic? • A computationally efficient non-monotonic logic • Why non-monotonic logic? • Allows for “jumping to conclusions” but later retracting conclusions if contradictory evidence comes to light • Models human reasoning
Defeasible Theories • Defeasible theories have three parts • Facts • dog(Sam) • Three types of rules • Strict rules: terrier(X) -> dog(X) • Defeasible rules: dog(X) => bark(X) • Defeater rules: sick(X) ~>¬bark(X) • A superiority relationship • Prioritizes rules to eliminate conflicts
Example Superiority Relationship • The logical theory:basenji(Jasmine)basenji(X) -> dog(X)r : dog(X) => bark(X)r’ : basenji(X) => ¬bark(X)r’ > r • Note: What happens without r’ > r?
Solution Overview • Each entity specifies a defeasible logic “meta policy” • Group of entities determine a precedence hierarchy • Policies are merged using a composition function, • Resultant composed policy is converted into its XML representation using a projection function,
Graphical Composition Overview Entity 1 A Resource Policy A meta policy Local Resource
What Does a Meta-Policy Look Like? • A meta-policy,P, is a tuple P = (Preas, Preq) • The reasoning theory, Preas, is a theory in the defeasible logic • The requirements theory, Preq, is a propositional logic theory • Used as a “sanity check” after merging to ensure this entity’s requirements are met • If the conclusions drawn during the merge can prove the statement SATISFIED in Preq, the defining entity is, well, satisfied with the outcome
Predicate Syntax • Security Token • securitytoken(Type, Issuer, {Claims}) • Integrity • integrity({Algorithms}, TokenInfo, {Claims}, {MessageParts}) • Confidentiality • confidentiality({Algorithms}, KeyInfo, {MessageParts})
Examples of Predicate Syntax • securitytoken('x509','uiuc',C) Represents an X.509 certificate issued by UIUC with no restrictions on the claims. • confidentiality({algorithm('encryption','rsa')}, securitytoken(T,'uiuc',C), {messageparts('xpath',S,'/body')}) Represents RSA encryption of the <body> element using a security token issued by UIUC.
Composition using • Define recursively in terms of a two policy composition function * • Two cases for *(p1, p2) • p1 and p2 unrelated by partial order • p1 dominates p2 • * can be used iteratively to compose any collection of partially ordered meta-policies
Projection Using • Derive C, the set of all conclusions that can be defeasibly proven from the composite reasoning theory • For each Ci 2Cthat satisfies the requirements theories, add Ci to the set of sets S • Fail if S is empty, otherwise generate XML
XML Generation • Find I, the intersection of each sS • Insert the elements of I into an <All> clause in the WS-SecurityPolicy • Create an <ExactlyOne> clause • For each sS, construct an <All> clause containing each conclusion in the set (s \ I) • Add this <All> clause as an item to the new <ExactlyOne> clause
Example • 2 organizations want to deploy a joint web service • Organization 1 • Wants X.509 to be used as the security token. • Allows a combination of tokens to replace X.509 when resources are constrained in mobile apps • Organization 2 • Deploys mobile apps • Requires Confidentiality • The organizations are unrelated in the partial ordering
Example Policy (Part 1) Req: hassecuritytoken -> satisfied. securitytoken('x509','uiuc',C) -> hassecuritytoken. securitytoken('saml',I,C),securitytoken('unt',I,C) -> hassecuritytoken. Reas: R1: {} => securitytoken('x509','uiuc',C). R2: {} => securitytoken('saml',I,C). R3: {} => securitytoken('unt',I,C). R4: mobile ~> ~securitytoken('x509',I,C). R5: securitytoken('x509',I,C) ~> ~securitytoken('saml',I,C). R6: securitytoken('x509',I,C) ~> ~securitytoken('unt',I,C). R4 > R1. R5 > R2. R6 > R3.
Example Policy (Part 2) Req: hassecuritytoken,hasconfidentiality -> satisfied. securitytoken('saml','uiuc/cs/dais',C) -> hassecuritytoken. confidentiality({algorithm('encryption','aes128cbc')}, securitytoken('unt',I,C)), {messageparts('xpath',S,'/body')}) -> hasconfidentiality. Reas: mobile. R1: {} => securitytoken('saml','uiuc/cs/dais',C). R2: {} => confidentiality({algorithm('encryption','aes128cbc')}, securitytoken(T,I,C), {messageparts('xpath',S,'/body')}).
Merged Reasoning Theories R1_1: {} => securitytoken('x509','uiuc',C). R1_2: {} => securitytoken('saml',I,C). R1_3: {} => securitytoken('unt',I,C). R1_4: mobile ~> ~securitytoken('x509',I,C). R1_5: securitytoken('x509',I,C) ~> ~securitytoken('saml',I,C). R1_6: securitytoken('x509',I,C) ~> ~securitytoken('unt',I,C). R1_4 > R1_1. R1_5 > R1_2. R1_6 > R1_3. mobile. R2_1: {} => securitytoken('saml','uiuc/cs/dais',C). R2_2: {} => confidentiality({algorithm('encryption', 'aes128cbc')}, securitytoken(T,I,C), {messageparts('xpath',S,'/body')}).
Set of Possible Conclusions • securitytoken('saml','uiuc/cs/dais',C) • securitytoken('unt',I,C) • confidentiality({algorithm('encryption','aes128cbc')}, securitytoken('unt',I,C), {messageparts('xpath',S,'/body')})
Expected WS-Policy Output <wsp:Policy> <wsp:All> <wsse:SecurityToken> <wsse:TokenType>wsse:SAMLAssertion</wsse:TokenType> <wsse:TokenIssuer>uiuc/cs/dais</wsse:TokenIssuer> </wsse:SecurityToken> <wsse:SecurityToken> <wsse:TokenType>wsse:UsernameToken</wsse:TokenType> </wsse:SecurityToken> <wsse:Confidentiality> <wsse:Algorithm Type="wsse:AlgSignature" URI="...AES128_CBC"/> <wsse:KeyInfo> <wsse:SecurityToken> <wsse:TokenType>wsse:UsernameToken</wsse:TokenType> </wsse:SecurityToken> </wsse:KeyInfo> <wsse:MessageParts Dialect="...XPath"> /Body </wsse:MessageParts> </wsse:Confidentiality> </wsp:All> </wsp:Policy>
Web Services and Beyond • This policy composition method is not only useful for merging WS-SecurityPolicy documents • Reliable messaging policies • WS-RM Policy specification • Investigating the interplay between security and reliable messaging policies would be an interesting area • Firewall policies • Example: Multiple groups sharing lab space • Efficiency of defeasible logic makes temporal firewall rules possible
Conclusion • Presented a system to compose security policies • Preferences for composition are encoded in meta-policies • Single operation for composition • Allow organizations to specify long term meta-policies • can be used for local resource policies • can be composed to determine the policy for a shared resource
Thank you for your attention. http://seclab.cs.uiuc.edu/ampol