1 / 60

Policy Language Overview

Policy Language Overview. Andrea Westerinen CA Technologies Apr 28, 2011. Topics. Overview and comparison of: DMTF’s CIM and CIM-SPL (Simplified Policy Language) Ponder2 from Imperial College XACML AIR from MIT REI from UMBC RuleML OMG’s SBVR TMForum’s SID KAoS from IHMC.

redell
Download Presentation

Policy Language Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Policy Language Overview Andrea Westerinen CA Technologies Apr 28, 2011

  2. Topics Overview and comparison of: • DMTF’s CIM and CIM-SPL (Simplified Policy Language) • Ponder2 from Imperial College • XACML • AIR from MIT • REI from UMBC • RuleML • OMG’s SBVR • TMForum’s SID • KAoS from IHMC

  3. Language Comparison

  4. Language Comparison (Continued)

  5. Language Comparison (Continued)

  6. Language Comparison (Continued)

  7. Language Overviews

  8. CIM and CIM-SPL • Constructs: • PolicyGroup (set of rules) • PolicyRule (set of conditions and actions) • PolicyCondition (broad set of operators defined, but extensible only as macros) • PolicyAction • Supports definition of rules whose conditions consist of CIM data properties, and whose actions invoke CIM operations or function calls • Actions include operations on the CIM data repository to change properties, create an instance, etc.

  9. PolicyGroup Structure (CIM-SPL) • Import CIM_V<major>_<minor>_<release><final or preliminary><mof file name w/o extension>::<class name>:<simple Boolean condition> ; • Strategy [Execute_All_Applicable | Execute_First_Applicable] ; • Declaration { <List of constant definition> (Optional) • <List of macro definitions> (Optional) } • Policy { … } : Priority; • Policy { … } : Priority; • … • PolicyGroup:[Association Name(Property1,Property2)] { … }: Priority; • …

  10. Example (CIM-SPL) • Import SAMPLE CIM_V_2_8_CIM_Core28-Final::PhysicalElement; • May further filter target instances via the specification of a condition • StrategyExecute_All_Applicable; • Declaration { • InstallDate="ManagedSystemElement.InstallDate"; • Macro { Name = Age; Type = Long; Arguments Born:DATETIME; • Procedure = getYear(CurrentDate) – getYear(Born) } } • Policy { • Condition { 4 > Age(InstallDate) AND • VendorEquipmentType == "switch“ } • Decision { Upgrade (SKU) } • }:1 Target If Multiple Policies Defined Variables and Procs Rule Priority

  11. Ponder2 • Combines: • Domain Service (for managing objects) • Obligation Policy Interpreter (for handling Event-Condition-Action rules) • Command Interpreter (accepts commands written in PonderTalk to perform actions against objects registered in the Domain Service) • Authorization Enforcement (supports positive and negative authorization and conflict resolution) • Constructs • Policies are sets of rules • Rules address either obligation or permission • Obligation policies consist of condition/action definitions • Infrastructure resolves conflicts between policies that apply to the same (subject, target, action)-triple • Based on “more specific” rule (“more specific” type in the hierarchy)

  12. Obligation Policy (Ponder2) • template := root/factory/event create: #( "monitor" "value" ). • root/event at: "monitor" put: template. • policy := root/factory/ecapolicy create. • policy event: root/event/monitor; • condition: [ :value | value > 100 ]; • action: [ :monitor :value | root print: • "Monitor " + monitor + " has value " + value 6 ]; • active: true.

  13. Authorization Policy (Ponder2) • root/tauthdom at: "a3" put: (newauthpol • subject: root/personnel/nurse/ward1/nurse1 • action: "getrecord“ • target: root/patient/ward1/patient1 • focus:"t" ). • root/tauthdom/a3 reqneg. • root/tauthdom/a3 reqcondition: • [ :nurselevel | nurselevel < 3]. • root/tauthdom/a3 repneg. • root/tauthdom/a3 repcondition: • [ :patrecord | patrecord =="[name= Harry;age= 12;symptom=BonelessArm]"]. • root/tauthdom/a3 active: true. Rule name Rule Where enforced Positive/Neg Authz Additional conditions on subject/target Active (T/F)

  14. XACML 3 Concepts Action before or after access First applicable Deny overrides Permit overrides Only one applicable … Attributes defined as name/value pairs Broad set of operators and extensible Permit/Deny

  15. Example (XACML) • <Policy PolicyId="SamplePolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> • <!-- This Policy only applies to requests on the SampleServer --> • <Target> • <Subjects> <AnySubject/> </Subjects> • <Resources> <ResourceMatchMatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> • <AttributeValueDataType=“...XMLSchema#string"> SampleServer</AttributeValue> • <ResourceAttributeDesignatorDataType=“…XMLSchema#string" AttributeId=“…:resource:resource-id"/> • </ResourceMatch> </Resources> • <Actions> <AnyAction/> </Actions> • </Target>

  16. Rule in a Policy (XACML) • <Rule RuleId="LoginRule" Effect="Permit"> • <!-- Only use this Rule if the action is login --> • <Target> • <Subjects> <AnySubject/> </Subjects> • <Resources> <AnyResource/> </Resources> • <Actions> <ActionMatchMatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> • <AttributeValueDataType=“…XMLSchema#string">login</AttributeValue> • <ActionAttributeDesignatorDataType=“…XMLSchema#string" AttributeId="ServerAction"/> • </ActionMatch> </Actions> • </Target>

  17. Condition in a Rule (XACML) • <!-- Only allow logins from 9am to 5pm --> • <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> • <Apply FunctionId=“…function:time-greater-than-or-equal" > • <Apply FunctionId=“…function:time-one-and-only"> • <EnvironmentAttributeSelectorDataType=“…XMLSchema#time" AttributeId=“…environment:current-time"/> • </Apply> • <AttributeValueDataType=“…XMLSchema#time">09:00:00</AttributeValue> • </Apply> • <Apply FunctionId=“…function:time-less-than-or-equal" > • As above, but the time is 17:00:00 • </Apply> • </Condition>

  18. Multiple Rules in a Policy (XACML) </Rule> <!-- We could include other Rules for different actions here --> <!-- A final, "fall-through" Rule that always Denies --> <Rule RuleId="FinalRule" Effect="Deny"/> </Policy>

  19. AIR • Allows control over reasoning by invoking rules according to pattern matching, dependency tracking (explanations), nesting of rules and goal direction • Rule types: • Belief – forward chaining deduction • Goal – means to limit the application of rules • Hidden – not shown as step in the deduction/explanation • Rule actions: • Assertions (statement added to beliefs) • Subrules • Alternatives

  20. AIR Concepts

  21. Example (AIR) • @forAll :PERSON, :CITY, :STATE. • :ny_neighbor_state_residency_policy a air:Policy; air:rule :non-ny-residency-rule. • :non-ny-residency-rule a air:Belief-rule; • rdfs:label "Non NY residency rule"; • air:pattern {:PERSON tamip:Lives_in_city :CITY.}; • air:rule [ air:pattern {:CITY tamip:Has_state :NY.}; • air:alt [air:rule :neighbor-state-rule] ]. • :neighbor-state-rule a air:Belief-rule; • rdfs:label "neighbor state rule"; • air:pattern { :CITY tamip:Has_state :STATE. • :NY tamip:Neighbor_state :STATE.}; • air:assert { :PERSON air:compliant-with :ny_neighbor_state_residency_policy. }. Rules in Policy Subrules in Rule

  22. REI • Supports deontic objects • Permissions, Prohibitions, Obligations, Dispensations (waiver for obligations) • Common Properties : Actor, Action, Constraint {StartingConstraint, EndingConstraint} • StartingConstraintsubproperty of Constraint • Uses speech acts for dynamic policy modification • Delegation, Revocation, Request, Cancel • Properties : Sender, Receiver, Content (Deontic object/Action), Conditions • Focused on security and privacy • Uses meta policies for conflict resolution

  23. REI Concepts

  24. REI Ontologies

  25. Example (REI) • <policy:Policyrdf:ID="DeptPolicy"> • <policy:contextrdf:resource="#IsMemberOfCS"/> • <policy:grantsrdf:resource="#Perm_StudentPrinting"/> • <policy:grantsrdf:resource="#Granting_StudentLaserPrinting"/> • <policy:defaultBehaviorrdf:resource="&metapolicy;ExplicitPermExplicitProh"/> • <policy:defaultModalityrdf:resource="&metapolicy;PositiveModalityPrecedence"/> • <policy:metaDefaultrdf:resource="&metapolicy;CheckModalityFirst"/> • <policy:rulePriorityrdf:resource="#PriorityBA"/> • <policy:importsrdf:resource="#SchoolPolicyWithGreaterPriority"/> • </policy:Policy> Constraints that define the domain Associates deontic obj Explicit/implicit permission/prohibition Whether pos/neg rules take precedence Or Priority Resource defining ruleOfGreater/LesserPriority

  26. Example Deontic Object (REI) • If you borrow a book from the library, you’re obliged to return it before the due date, otherwise you must pay a fine <deontic:Obligationrdf:ID=”Obl_ReturnBook"> <deontic:actorrdf:resource="#PersonVar"/> <deontic:actionrdf:resource=”&inst;ReturnBook"/> <deontic:StartingConstraint rdf:resource="#IsMemberAndBorrowedBook"/> <deontic:EndingConstraintrdf:resource="#BeforeDueDate"/> <deontic:sanctionrdf:resource=”&inst;PayFine"/> </deontic:Obligation>

  27. Example Speech Act (REI) • ’Marty' revokes the permission to use a specific action ’HP123Printing from 'George' <action:Revocationrdf:ID=”MartyFromGeorge"> <action:senderrdf:resource="&inst;Marty"/> <action:receiverrdf:resource="&inst;George"/> <action:content> <deontic:Permission> <deontic:actionrdf:resource ="&inst;HP123Printing"/> </deontic:Permission> </action:content> </action:Revocation>

  28. RuleML • Concerned with rule interop “between industry standards • Such as JSR 94, SQL'99, OCL, BPMI, WSFL, XLang, XQuery, RQL, OWL, DAML-S, and ISO Prolog) • As well as established systems (CLIPS, Jess, ILOG JRules, Blaze Advisor, Versata, MQWorkFlow, BizTalk, Savvion, etc.)” • http://ruleml.org/ • Developed a base RuleML specification and a hierarchy of rule types • Based on Datalog/Horn clauses and n-ary relations • Unary/binary form of these clauses used in OWL/SWRL • Developed transformations from and to other rule standards/systems • Also addressing coordinated tool development • Such as an XSLT normalizer to check syntax, add role tags and missing attributes

  29. RuleML Rule Hierarchy Basic structure dealing with implications (head <- body), with details in relationships between variables Most work in this area

  30. RuleML Example "A customer is premium if their spending has been min 5000 euro in the previous year.“ <Implies> <head> <Atom> <Rel>premium</Rel> <Var>customer</Var> </Atom> </head> <body> <Atom> <Rel>spending</Rel> <Var>customer</Var> <Ind>min 5000 euro</Ind> <Ind>previous year</Ind> </Atom> </body> </Implies> Derivation Conclusion Premises

  31. SBVR • Semantics of Business Vocabularies and Business Rules • Based on semantic and first-order logic concepts • Defines UML constructs to represent vocabularies & rules • Assumed multi-lingual • Separates “symbols” from their concepts/semantics • Defines basic vocabulary/rule exchange structure using MOF/XMI • Includes approach to convert “structured English” to SBVR concepts in (non-normative) Annex C • Annex “describes one … way of using English that maps mechanically to SBVR concepts.” • “It is not meant to offer all of the variety of common English, but rather, it uses a small number of English structures and common words to provide a simple and straightforward mapping.”

  32. SBVR Details (Core Definitions to Instances) http://www.omg.org/news/meetings/ThinkTank/past-events/2006/presentations/04-WS1-2_Hall.pdf

  33. Major Areas Addressed by SBVR

  34. SBVR Community

  35. SBVR Meanings

  36. SBVR Semantic/Logical Formulations

  37. SBVR Policies and Rules

  38. SBVR Example • Very complex instantiation, even for simple rules … • For example … Definition: the age of the driver is at least the EU-Rent Minimum Driving Age • Results in a complex set of variables, quantifications, atomic formulations, role bindings, fact types, … • The definition is represented by a projection • The projection is on a first variable • The first variable ranges over the concept ‘driver’ … The first variable maps to the one role of the characteristic. • The projection is constrained by a first universal quantification … • Continued on the next slide • XML formulation even more complex

  39. SBVR Example (Continued) • The first universal quantification introduces a second variable. . . . The second variable ranges over the concept ‘age’. . . . The second variable is unitary. . . . The second variable is restricted by an atomic formulation. . . . . The atomic formulation is based on the fact type ‘driver has age’. . . . . The atomic formulation has a role binding. . . . . . The role binding is of the role ‘driver’ of the fact type. . . . . . The role binding binds to the first variable. . . . . The atomic formulation has a second role binding. . . . . . The second role binding is of the role ‘age’ of the fact type. . . . . . The second role binding binds to the second variable. • The first universal quantification scopes over a second universal quantification. . . . The second universal quantification introduces a third variable. . . . . The third variable ranges over the concept ‘EU-Rent Minimum Driving Age’. . . . . The third variable is unitary. • The second universal quantification scopes over an atomic formulation. . . . . The atomic formulation is based on the fact type ‘quantity1 > quantity2’. . . . . . The atomic formulation has a role binding. . . . . . . The role binding is of the role ‘quantity1’ of the fact type. . . . . . . The role binding binds to the second variable. . . . . . The atomic formulation has a second role binding. . . . . . . The second role binding is of the role ‘quantity2’ of the fact type. . . . . . . The second role binding binds to the third variable.

  40. SID Policy Domains Instance-specific definitions Infrastructure components Invariant definitions

  41. SID Policy – Big Picture

  42. SID Policy – Digging into Rules Execution strategy – Do all actions, until failure, etc. Sequenced actions – Mandatory to best effort XxxCriteria are OCL-based restrictions on actions, etc. in derived rules

  43. SID – Policy Details • SID – Shared Information/Data Model • Described in Publication GB922, NGOSS Release 4, Addendum 1-POL • Constructs: • Policy – a set of rules • Policy Rule • Policy Set – a group of policies • Policy Event – an occurrence • Policy Condition – an aggregation of individual PolicyConditions; boolean expression • Policy Action – an aggregation of individual PolicyActions; “actions to be applied”

  44. SID Policy – Related Constructs Policy Subject – set of entities that is the “focus of the policy” (as Roles) Policy Targets – set of entities that the policy will be applied to (as Roles) But not further related in the model, except that Entities have EntityRoles, and PolicyApplications also have Roles

  45. SID Example Not Provided • Cannot be compactly displayed • Complex set of inter-related instances • For example, … • PolicyRules have 1 or more PolicyConditions • Which ultimately have to be defined as PolicyConditionAtomics • Which are related 1-to-1 to PolicyStatements • Which have 1 or more PolicyVariables • Which are made up of 1 or more values with 1 or more operators • Most concepts include related constraints (OCL) • See detailed UML diagrams in backup • In addition, domain-specific extensions require corresponding UML definitions

  46. KAoS Overview • From IHMC – Florida Institute for Human Machine Cognition • Infrastructure and ontology for policy specification, analysis, disclosure and enforcement • Backing software implemented using Java Agent Services (JAS) • Based on OWL-DL (OWL 1) for extensibility • Base ontology defines general policy concepts • Domain interpretations/extensions necessary for specific environments • Includes generic reasoner interface (for example, Stanford Java Theory Prover or Pellet Reasoner) • Incorporates concepts of both positive/negative authorization and obligation • http://ontology.ihmc.us/KAoS/KAoS%20Tutorial.pdf

  47. KAoS Architecture (3 Layer) Policies distributed to Guards Implemented by enforcers

  48. Policy Decision Point

  49. KAoS Policies • Starting from a Situation … • Where the situation has variables describing its state, and has a history • Use of history: When [the actor] has performed [an action] which has [attributes] at least [some number] of times within the last [some number] [time period], then … • Use of state: When the [situation] has [state] with [attributes], then … • Evaluate a Rule: An [Actor] is [constrained] to perform [an action] which has [attributes] • Where an actor can be a specific instance, a type/class or role, or a logical union/complement/… of other instances or types (concepts all natively supported by OWL) • Where the constraint defines +/- authorization or obligation • Where the action is a type/class (such as movement) • …

  50. KAoS Policies (Continued) • Evaluate a Rule: An [Actor] is [constrained] to perform [an action] which has [attributes] • … • Where the attributes are the parameters of the action and can be: • Simple value restrictions (all/some values within a set of enumerated instances or of a certain type) – OR • A relation (equals, subset of/superset of, at least one, none) of 2 or more attributes • Business logic calls KAoS Policy Service in the context of a given situation to: • Test permission to perform an action • Get obligations • Get configuration (details allowed for action to be authorized)

More Related