Upload
bdemchak
View
231
Download
0
Embed Size (px)
Citation preview
1
Policy Driven DevelopmentFlexible Policy Insertion for Large Scale Systems
POLICY 2012Chapel Hill, NCJuly 16, 2012
Barry Demchak
2
Dev
elop
erThe Problem
Stakeholder
Code
Negotiate Define
RealizeCreate,Maintain,Release
Run
Implement
Buggy code
Misinterpretation
Misimplementation
Misspecification
Obsolete-on-arrival
Impedance mismatch
Need Refinement
Clutter and overgrowth
Requirem
ents
Long developmentLong release
Source unavailable
Personnel attrition
Consequences• Stakeholders disaffected
and disenfranchised• Lost productivity
and opportunity
Observation• Agile doesn’t scale well
3
Roadmap• Problem description• Solution outline• Examples in real world PALMS system• Policy languages – a Domain Specific Language (DSL) approach• System of Systems composition• Evaluation• Conclusions• Future work
4
The Problem (cont’d)
signOn()
amount = keyWithdrawalAmount()
dispenseCash(amount)
New requirements1. Error if out-of-state2. Max withdrawal $100if user.outOfState then
error “out of state”return
amount = min(100, amount)if not verifyNewAmount(amount)error “cancelled”return
Approaches• Explicit coding• Property files• Active Directory, et al• ABAC/RBAC• Policy engine (PDP/PEP)• Aspects (AOP/AOSD)
5
PALMS ListDevices Device RepositoryClient
❸❶ ❷
❽ ❺❻❼
Storage
❹
PALMS ListDevices Device RepositoryClient
❸❶ ❷
❽ ❺❻❼
Storage
❹
Return ErrorIf User ≠ “Bob”
PALMS ListDevices Device RepositoryClient
❸❶ ❷
❽ ❺❻❼
Storage
❹
Return Error
Remove Unauthorized DevicesIf User ≠ “Bob”
Insight
• Applications as workflows (workflow activity = service = function)• activities exchange messages• activities perform work
• Workflows composed at runtime• Interactions must be identifiable at runtime• Messages must be interceptable
• Policy as decision that selects amongst workflow alternatives• Policy programming: upgraded activity that compliments existing processes
Consequences• Inject control, filter, and feature
via policy• Stateful policy = application Policy-driven runtime
composition of applications (SoS)
6
MechanicsI0 O0
I1
I...
O1
O...SS
DC
SDC
I O PIP
OP
OP, IQ
IP,OQ QOQ
IQ
P⨂Q S
OP
RPQ
P QIQ
OQ
IP
I,O
❻
Router
Messenger
Service/Data Connector
Service/Data Connector
{
{
Rich« Infrastructure »
Services
Rich« Application »
Services
Serv
ice/
Data
Co
nnec
tor
« PALMS Rich Service »
❶
❷
❸
❹
❺
❻Device
RepositoryData
Repository
Service/Data Connector
Context Manager
Service/Data Connector
EventLogging
Service/Data Connector
Policy Evaluation
7
Mechanics (cont’d)
• Control Policy on <P,Q>– RPQ calls Policy Evaluation RIS {IQ, P, Q}
– Fetch policy πcp for <P,Q>– Evaluate policy πcp(IQ, P, Q) new service Wcp
– RPQ executes Wcp(IQ)– PQ P RPQ Wcp
• Filter Policy on <P,Q>– RPQ calls Policy Evaluation RIS {IQ, P, Q}
– Fetch policy πfp for <P,Q>– Evaluate policy πfp(IQ, P, Q) new service Wfp
– RPQ calculates Wfp(IQ) IQ
– RPQ executes Q(IQ)– PQ P RPQ Wfp Q
S
OP
RPQ
P QIQ
OQ
IP
I,O
Wcp
PE
Policy Repository
P,Q πcp,fp
IQ,P,Q Wcp
Pre-
Post-
8
Roadmap• Problem description• Solution outline• Examples in real world PALMS system• Policy languages – a Domain Specific Language (DSL) approach• System of Systems composition• Evaluation• Conclusions• Future work
9
PALMS Policy Examples
• Access Control– Control Policy (at ❸)
– if (subject-in-any-study-role('PI,RA')) then () else return-error('Insufficient permissions')
– Filter Policy (at ❼)– filter-by-any-role('PI,RA')
• Audit (at ❷)– audit("AuditID1", ("event", "ListDevices"),
("subject", $Subject), ("deviceName", cur-value("deviceName")))
PALMS ListDevices Device RepositoryClient
❸❶ ❷
❽ ❺❻❼
Storage
❹
Return Error
Remove Unauthorized DevicesIf User ≠ “Bob” DSLs
10
Context System
• Optimizations– Workflow– Session– Custom
class Expression Data
Env ironmentHistory MessageApplicationState
PointsVisitedByMessage MessagesAtAPoint RowSet
XQueryStatement
Data
CredentialsEvaluation
11
Policy Evaluation Engine
Java Object XML
XML
XStream
XStream
XQuery
RBAC (Xdm)
Policy (XQuery)
(Service)+
PALMS ListDevices Device RepositoryClient
❸❶ ❷
❽ ❺❻❼
Storage
❹
Post-filter
ControlPre-filter
Java Object
Xdm Item Xdm
ItemSaxon
Saxon
12
Roadmap• Problem description• Solution outline• Examples in real world PALMS system• Policy languages – a Domain Specific Language (DSL) approach• System of Systems composition• Evaluation• Conclusions• Future work
13
XQuery Library Hierarchy
auth-treeops
auth-utils auth-msg
auth-query
palms
service audit composition filters
RBAC (Xdm)
Basic access control and messaging
14
PALMS Policy DSLsDomain Function Params ReturnAccess Control
subject-in-any-study-rolessubject-in-all-study-rolessubject-in-any-user-rolessubject-in-all-user-roles
$role-list boolean
filter-by-attribute $name, $value messagefilter-by-any-role $role-list message
Policy Composition
compose-unanimouscompose-overridecompose-allcompose-preemptivecompose-hierarchical
General return-error $error $message-q, $messageXQuery expression
15
PALMS Policy DSLs (cont’d)Domain Function Params ReturnAudit audit $auditID {, (name, value) }* message
audit-if $boolean-condition, $true-param-list,$false-param-list
param-list
Feature Composition
call-service $message-q, $message message
16
System of Systems Composition
Router
Messenger
Service/Data Connector
Service/Data Connector
{
{
Rich« Infrastructure »
Services
Rich« Application »
Services
Serv
ice/
Dat
a Co
nnec
tor
« PALMS Rich Service »
Device Repository
Data Repository
Service/Data Connector
Context Manager
Service/Data Connector
EventLogging
Service/Data Connector
Policy Evaluation
Router
Messenger
Service/Data Connector
Service/Data Connector
{
{
Rich« Infrastructure »
Services
Rich« Application »
Services
Serv
ice/
Data
Co
nnec
tor
« Policy Rich Service »
Policy Evaluation
Authoring System
Service/Data Connector
EventLogging
Service/Data Connector
Policy Evaluation
Service/Data Connector
Policy Repository
Router
Messenger
Service/Data Connector
Service/Data Connector
{
{
Rich« Infrastructure »
Services
Rich« Application »
Services
Serv
ice/
Data
Co
nnec
tor
« Event Logging Rich Service »
Event Logging Visualization System
Service/Data Connector
EventLogging
Service/Data Connector
Policy Evaluation
Service/Data Connector
Event Repository
17
Roadmap• Problem description• Solution outline• Examples in real world PALMS system• Policy languages – a Domain Specific Language (DSL) approach• System of Systems composition• Evaluation• Conclusions• Future work
18
Evaluation
# Operation Time (ms)Client Storage, empty device DB 63 (54.5 browser +
7.2 server + 1.3 network)
19
Evaluation
# Operation Time (ms)Client Storage, empty device DB 63 (54.5 browser +
7.2 server + 1.3 network)❶ Single service interaction, no Policy Evaluator RIS 0.115❷ ❶ + Policy Evaluator RIS, empty interaction DB ❶ + 0.203❸ ❷ + 1 interaction, no policy ❷ + 0.007
20
Evaluation
# Operation Time (ms)Client Storage, empty device DB 63 (54.5 browser +
7.2 server + 1.3 network)❶ Single service interaction, no Policy Evaluator RIS 0.115❷ ❶ + Policy Evaluator RIS, empty interaction DB ❶ + 0.203❸ ❷ + 1 interaction, no policy ❷ + 0.007
❸ + control policy ❸ + 76.50❸ + passthru post-filter policy ❸ + 78.62❸ + actual post-filter policy, no records ❸ + 84.51❸ + actual post-filter policy, 1/1 record ❸ + 91.66❸ + actual post-filter policy, 0/97 records ❸ + 359.98❸ + actual post-filter policy, 97/97 records ❸ + 818.08
21
Conclusions
Traditional Programming
Runtime Workflow Composition
Time to Market
Spee
d,
Com
plex
ity,
Stro
ng G
uara
ntee
s
Less More
More
• Guarantees– Depends on DSL language– Traditional AC languages?– Dependencies deferred to runtime
• Policy Programmer must know:– Interactions– Messages– Available services
22
Conclusions
• Policies are mini-applications composed into base workflow
• Clear positioning of policy relative within highly complex distributed system
23
Future Work• Policy programming
– Verification– Modeling– Model checking– Integration of modeling (simulation and debugging)– Extend to stakeholders (directly)– Integration of existing policy engines?
• Further speed optimizations– Precompilation– Harmonizing message formats or policy language to reduce conversions
• Secure Policy Deployment
24
Questions?
25
• BACKUP SLIDES• BACKUP SLIDES
• BACKUP SLIDES
• BACKUP SLIDES
• BACKUP SLIDES
• BACKUP SLIDES
• BACKUP SLIDES
26
Existing Choice Mechanisms• Compile time constants• Attributes in directories (permissions, owners, groups, etc)• Permissions in property files (Tomcat policies)• Attributes and permissions in registries (Active Directory, Facebook privacy,
Oracle database permissions)• Attribute Based Access Control (ABAC) and Role Based Access Control
(RBAC)• Declarative mechanisms (triggers)
• All amount to predicates that select workflows based on strategy, bridge, and state patterns
• Policy Engines, PDP/PEP moves predicates to external policy, but placement is constant
• BPEL Process Integration with Business Rules
27
Study Repository
Visualization Repository
Calculation Repository
Observation and Solution
PIStudy
Study
StudyPI
Study
Study
PIStudy
PALMSStudyStudyStudy
Study
StudyStudy
PI PIPI
Community
• Policy-driven access control– Subject data– Study data– Calculations– Visualizations
• Secure• HIPAA Compliance• Customized Studies• Collaboration• Data Reuse
Browser
Excel,Matlab…
Personal Activity Location Measurement System
• Understanding where activity-related energy expenditure occurs in time and space
Cyberinfrastructure
28
Study Repository
Visualization Engine
Calculation Engine
PALMS
StudyStudyStudy
Study
StudyStudy
PI
RA
Define
EnterSubjects
EnterObservations Refi
ne & Star
t
Refine & Create
Guest
Real Workflows
29
Study Repository
Visualization Engine
Calculation Engine
PALMS
StudyStudyStudy
Study
StudyStudy
PI
RA
Guest
Policy
Policy
Admin
Defines
Uses
Applies
Policy in Action
Policy (def.): Permission for someone to act on
something
30
The Technical Requirement• Technical Requirements
– Support research workflows– Security and privacy– High reliability and availability– Scalability (bandwidth/storage/users)– Auditability– Provenance and curation
• Key Insights– All stakeholders must have requirements met, or CI degrades– Existing development models have long latencies– Requirements are often lost in translation– Success of CI depends on
– Accurate, timely, and continuous requirement elicitation– Precise requirement formulation– Low implementation latency– Automatic requirement composition
31
Policy Driven Development• Goals
– Enable rapid customization– Empower stakeholders to directly define behavior
• Service Oriented Architecture (Rich Services)– Services loosely coupled
– Late binding– Scalability– Testable– Interoperable– Incremental development– Composition
– Services can be hierarchically decomposed
32
SPSS
ESRI
GPS Device
Accelerometer
Others
PALMS
Study StudyStudy
Study
Filtering Filtering Filtering
Scoring
Analyzing
Scoring Scoring
Analyzing Analyzing
External Data
Subject Data Raw Data
Others
...
...
Google Maps Viewer Other Local Viewer
Authorable & Discoverable
Data Flow (CI)
33
Rich Services
34
Messenger
Router/Interceptor
Policy
Ser
vice
/Dat
aC
onne
ctor
Messenger
Router/Interceptor
Failure Manager
...
<<Rich Service>> S
Ser
vice
/Dat
aC
onne
ctor
...
<<Rich Service>> S.n
Service/DataConnector }<<
Rich Infrastructure
Services>>
EncryptionService/Data
Connector
LoggingService/Data
Connector
Failure Manager
Service/DataConnector
...
Service/DataConnector
S.1
Service/DataConnector
S.2
Service/DataConnector
}<<
Rich Application Services
>>
S.n.2
Service/DataConnector
S.n.m
Service/DataConnector
}
<<Rich
Application Services
>>
S.n.1
Service/DataConnector
Service/DataConnector
Logging
Service/DataConnector
Encryption
Service/DataConnector
Policy ...
Service/DataConnector
Service/DataConnector
<<Rich
Infrastructure Services
>>}
From tightly to l o o s e l y coupled systems
a hierarchically decomposed structure supporting
“horizontal” and “vertical” service integration
Rich Service Blueprint
35
Event Logger Access Policies
PALMS Integration System
Integration Adapter
Data Repository
HIPAA Policies
Service/ Data
ConnectorViewerViewer
Adapter
Consumer Systems
Service/ Data
ConnectorSensor AdapterSensor
Producer Systems
Subject Repository
Service/ Data
ConnectorAuthoringCalculation
Repository
Calculation Systems
ExecutionPrototyping
Failure Detection/Mitigation
Logical Architecture
36
Rich Services Virtual Network
Rich ServicesRAS4
Services
Service S1
Roles
U1
U2
U3
U4
U5
Use Case Graph
ConcernsC1 C2 C3
C4CC1
CC2CC3
Domain Model
R1 R2
R3 R4
R5 R6
R1 R2
msg
R3
CC1CC2
Role Domain Model
R1 R2
R3 R4
R5 R6
CC1 CC2 CC3
Router/Interceptor
Messenger/Communicator
RAS1 RAS2
CC1 CC4 CC5
Router/Interceptor
Messenger/Communicator
RAS5 RAS6RAS3
S/D
S/D
RIS:
RIS:
Serv
ice
Elic
itatio
nR
ich
Serv
ice
Arc
hite
ctur
e
RAS7
System of Systems Topology
H1 H2
H3
H5
H6
H7
H8
H9H4
RAS1 RAS2 RAS3
RAS5 RAS6 RAS7
Infrastructure Mapping
H1:RAS1 H2:RAS2
H3:CC1
H5:RAS2
H6:RAS5
H7:RAS7H8:RAS7
H9:RAS6
H4:RAS3
Opt
imiz
atio
n ImplementationRAS1 RAS2
RAS3 RAS4
RAS5 RAS6
RAS7 CC1
CC2 CC3
CC4 CC5
Ana
lysi
s
Syn
thes
is
Ana
lysi
s
Iden
tific
atio
n
Def
initi
on
Con
solid
atio
n
Refinement
Hierarchic composition
Refinement
Logical Model
Syst
em A
rchi
tect
ure
Def
initi
on
Logical Architecture Loop
Deployment Loop
Rich Service Development Process
37
Spectrum of Sharing1
Trust Publish Interaction Quality Privacy Enablers
No one Nothing No one - - -
Friends & Family
Subsets/ derivatives
Word of mouth
Person to person
Handshake promise
None
Community ″ Conference booths/ papers
Curation2 De-ident & agreement
Auto de-ident, Agreement template3,4
Public ″ Repository/ registry
Taxonomies/ semantics
″ ″
1 C. Fennema-Notestine. Enabling Public Data Sharing: Encouraging Scientific Discovery and Education2 Strong metadata, use common ontological framework, collection conditions & semantics, validated calculation &
visualization 3 Suggested IRB or HIPAA wording4 Promise to not re-identify, use data at own risk, no quality guarantees, properly acknowledge data source
38
Deployment
Web Browser(UI)
PALMSService
GWT RPC
Mule Messaging
Browser Proxy (UI)
PALMS Subservices
CXF Web ServicesMule Messaging
CXF Web Services GWT RPC
PALMS Server VMPC Browser PALMS Server Machine
JAVA (GWT) JAVA (Mule ESB)