Transcript Using Views for Customizing Reusable Components in Component-Based Frameworks

Using Views for
Customizing Reusable Components in
Component-Based Frameworks
Anca-Andreea Ivan
Vijay Karamcheti
New York University
PDSG
NYU
1
Application Adaptation
Motivation:
Applications run in heterogeneous environments.
Network state changes over time.
Problem:
Changes in environment state often impact application
performance in a negative way.
Solution:
Flexibly adapt the application to environment changes.
PDSG
NYU
2
Choices for Application Adaptation
Two classes of application adaptation:
Applications adapt by themselves
 Requires code modification
Systems adapt applications:
 Applications expose knobs: Tunability Framework
 Systems adapt applications by deploying components:
• Static linkages: CCM, .NET
• Dynamic linkages: Partitionable Services Framework-PSF,
CANS
PDSG
NYU
3
Running Example:
Web-Based Mail Application
Components:
Mail Server
Cache
Mail Server
Mail Client
Weak Mail
Client
Cipher
Clients can require certain quality of service levels:
 Minimum operation time (send/receive).
 Confidentiality : privacy required (or not).
PDSG
NYU
4
Partitionable Services Framework
PSF
A
B
secure, fast
insecure, slow
PDSG
NYU
5
Partitionable Services Framework - Protocol
User makes request
PSF authorizes user
PSF customizes comp
PSF extracts properties
PSF creates plan
PSF authorizes nodes
PSF deploys comp
Nodes authorize comp
Nodes link/run comp
PDSG
NYU
6
Challenges
Descriptive application specification that comprises
general application properties. [HPDC 2002]
Efficient planning process that considers application and
environment properties. [IPDPS 2003]
Efficient and flexible component customization.
Distributed, single sign-on, cross-domain authorization.
Efficient and secure deployment process.
PDSG
NYU
7
Challenges
Descriptive application specification that comprises
general application properties. [HPDC 2002]
Efficient planning process that considers application and
environment properties. [IPDPS 2003]
Efficient and flexible component customization.
Distributed, single sign-on, cross-domain authorization.
Efficient and secure deployment process.
PDSG
NYU
8
Component Customization - Summary
Definition of component customization
Advantages of component customization
View definition
 Example
View run-time support
 View generator
 View deployment system
PDSG
NYU
9
Component Customization
“Component customization” denotes the automatic
creation of new components based on old components and
a few simple rules.
 Base component is
and implements
• MessageInterface
• AddressInterface
• NotesInterface
 One possible component is
and implements
• MessageInterface
• AddressInterface
PDSG
NYU
10
Advantages of Component Customization
Increased chances to find a valid deployment plan:
 New components can have different properties.
Customized, single sign-on access control:
 Customizing / removing / adding methods.
 Distributing only the minimum necessary code to users .
 No need to access sources (Java bytecode modification).
Ease the programming effort:
 Defining simple rules instead of duplicating code.
PDSG
NYU
11
View Definition
A view (
) represents a component, if
 Its functionality is derived from the component functionality.
is a
for
 Its data is a subset of the data used by the component.
is a
PDSG
NYU
for
12
Using Views
class MailClient
view WeakMailClient
MessageInterface
m1
x=3
AddressInterface
m2
y=6
y=4
NotesInterface
m3
PDSG
NYU
zz++
++
m4
a = 10
13
XML View Description
<View name = WeakMailClient />
<Represents name = MailClient />
<Restricts>
<Interface name = MessageInterface />
<Interface name = AddressInterface />
<Adds_Methods>
<MSign> m4
<MBody> a = 10
<Customizes_Methods>
<MSign> m2
<MBody> y = 6
PDSG
NYU
14
View Generation Tool - VIG
VIG is an automatic view generator.
 Input: original component + view definition rules
 Output: new component (e.g. view)
 Based on bytecode modifier (Javassist)
Operations allowed when defining a view:
 Add new fields; copy fields from the original component;
 Add new methods; copy or customize methods from the
original component;
 Restrict interfaces; add new interfaces.
PDSG
NYU
15
Views – Run-Time System
A
PDSG
NYU
PSF
 User makes request.
 PSF authorizes user.
 PSF customizes components.
 PSF extracts link & node &
component properties.
 PSF creates a valid plan.
 PSF authorizes nodes.
 PSF deploys components on
nodes.
 Nodes authorize components.
 Nodes run & link components.
16
Challenges in deploying views
Expressing views properties (environment properties):
 General properties (e.g. privacy, OS - version)
 Different administrators.
Authorizing users, node, views:
 Different domains.
 No centralized certification authority.
 No total knowledge about the credential space.
Linking views:
 Secure communication channels.
 Continuous monitoring of the trust relationships.
PDSG
NYU
17
View – Run-Time System
Distributed trust managements system
 Each domain has its own certification root and defines its
own meaningful credentials.
 dRBAC [ICDCS 2002]
Communication abstraction to establish secure,
authenticated, and continuously monitored links between
components.
 Switchboard [RESH 2002]
PDSG
NYU
18
Using Views, dRBAC, and Switchboard
A.user
[Dell.linux→Mail.Node] Mail
A.partner
[[
A
[
PDSG
NYU
→ A.comp ] A
[
PSF
→A.partner
Dell.linux
→
]A ] Dell
→ A.comp ] A
19
Current status
JDK 1.4
Bouncycastle 1.16
Linux, Windows 2000 (XP)
Partitionable Services Framework
 http://www.cs.nyu.edu/pdsg/pdsg.htm - Software/PSF
 PSF, VIG, Sekitei
Disco:
 http://www.cs.nyu.edu/pdsg/pdsg.htm - Software
 dRBAC, Switchboard
PDSG
NYU
20
Related Work
Cross-domain authorization:
 DCE, DCOM, Corba
 Multiple certification roots
 No requirement for total knowledge
Expressing environment properties:
 CANS, Ninja, previous version of PSF
 Translating between environment and application props.
Granularity of access control:
 DCE, Corba, DCOM
 Flexible, single sign-on access control
PDSG
NYU
21
Contributions
Automatic creation of new components (e.g. views) by
customizing old components
 Increased chances of successful planning
 Customized, single sign-on access control
Distributed trust management and role-based access
control system (dRBAC)
 Expressing component and environment properties
Secure communication channels with continuous
monitoring of trust relationships (Switchboard)
PDSG
NYU
22
Thank you
[email protected]
http://www.cs.nyu.edu/~ivan
PDSG
NYU
23
Partitionable Services Framework - Protocol
User makes request to access service.
PSF authorizes user before granting access to service.
PSF customizes the set of available components.
PSF extracts link & node properties.
PSF creates a valid plan.
PSF authorizes nodes before deploying components.
PSF deploys components on the nodes.
Nodes authorize components before running them.
Nodes link & run components on nodes.
PDSG
NYU
24
dRBAC – Distributed RBAC
Self-certifying delegations:
[
 NY.user ]NY
Third-party delegations:
[
 NY.user ] SE
Assignment delegations:
[ SE  NY.user ‘] NY
Attributes for delegations
[
PDSG
NYU
 NY.user w/ BW=100kb ] NY
25
User Authorization
[
New York
Seattle
PDSG
NYU
 NY.user ] NY
[ SE  NY.user ‘ ] NY
[
 NY.user ] SE
26
Distributed Authorization
 NY.user ] SE
[
[
 NY.user ] NY
[ SE  NY.user ‘ ] NY
 NY.user ?
PDSG
NYU
27
Node Authorization &
Translation Environment Properties
New York
[
 Dell.linux ] Dell
Seattle
[
 IBM.xp ] IBM
Mail
PDSG
NYU
[ Dell.linux  Mail.node w/ Secure= T ] Mail
[ IBM.xp  Mail.node w/ Secure= F ] Mail
28
Component Authorization
New York
Seattle
PDSG
NYU
[
 NY.exec w/ CPU = 100 ] NY
[
 NY.exec w/ CPU = 100 ] NY
[
 NY.exec w/ CPU = 100 ] NY
[
 NY.exec w/ CPU = 100 ] NY
[NY.exec  SE.exec w/ CPU = 80 ] NY
29