Denis Caromel, Arnaud Contes

1

Declarative Security for GRID Applications
ProActive

• Denis Caromel, Arnaud Contes
• www.inria.fr/oasis/ProActive
• OASIS Team
• INRIA -- CNRS - I3S -- Univ. of Nice
  Sophia-Antipolis
• 1. Introduction to the GRID
• 2. ProActive Remote Objects, Groups, Mobile
  Objects,
• Graphical Interface (IC2D), XML
  Deployment,
• 3. Declarative Security
• 4. Demonstration

2
1. Grid and the Internet

• GRID definition
• GRID electric network in the US
• A gripping idea
• Like electricity, computer cycles cannot be
  stored, if not used they are lost
• A definition
• Grid is a parallel and distributed system that
  enables the use, sharing,
• selection, and aggregation of resources across
  multiple administrative domains
• based on their availability and capability.
• Not limited to cycles
• Computational GRID, Data GRID
• Inter, Intra-company, but multi-locations Grid
  (computational, and data)

SECURITY ISSUES
3
Hierarchical Domains for Internet Grid
4
Issues at hand for Grid Security

• Authentication of Computers, Users, and
  Applications
• Authentication, Integrity and Confidentiality
  (AIC) of communications
• Creation, connection to, and monitoring of
  activities
• Hierarchical domains
• Security Policies Application, Domain,
  (sub-domain), High-level!
• Variation in Grid network links
• LAN, Wireless (Wifi, GPRS/UMTS), VPN, Internet,
  or unknown !
• Variation in deployment, but maintain as much as
  possible performance

5
2. ProActive A Java API Tools for Parallel,
Distributed Computing

• A uniform framework An Active Object
  pattern
• A formal model behind Prop. Determinism,
  insensitivity to deploy.
• Main features
• Remotely accessible Objects
• Asynchronous Communications with synchro
  automatic Futures
• Group Communications, Migration (mobile
  computations)
• XML Deployment Descriptors
• Interfaced with various protocols
  rsh,ssh,LSF,Globus,Jini,RMIregistry
• Visualization and monitoring IC2D
• In the www. ObjectWeb .org Consortium (Open
  Source middleware)
• since April 2002 (LGPL license)

6
ProActive Creating active objects

• An object created with A a new A (obj, 7)
• can be turned into an active and remote object
• Instantiation-based
• A a (A)ProActive.newActive(A, params,
  node)
• The most general case.

foo (A a) a.g (...) v a.f (...) ...
v.bar (...)
JVM
7
Standard system at Runtime
No sharing between activities
8
ProActive Groups
Typed and polymorphic Groups of active and remote
objects
A ag newActiveGroup (A,,Nodes) V v
ag.foo(param) v.bar()
A
V
Typed Group
Remote Object
9
ProActive Migration of active objects
Migration is initiated by a primitive
migrateTo The active object migrates with
pending requests, objects, futures Automatic
and transparent forwarding of requests, replies
Remote references remain valid
10
ProActive Migration of active objects
Migration is initiated by a primitive
migrateTo The active object migrates with
pending requests, objects, futures Automatic
and transparent forwarding of requests, replies
Remote references remain valid
11
ProActive Migration of active objects
Migration is initiated by a primitive
migrateTo The active object migrates with
pending requests, objects, futures Automatic
and transparent forwarding of requests, replies
Remote references remain valid
direct
12
ProActive Migration of active objects
Migration is initiated by a primitive
migrateTo The active object migrates with
pending requests, objects, futures Automatic
and transparent forwarding of requests, replies
Remote references remain valid
direct
direct
13
ProActive Migration of active objects
Migration is initiated by a primitive
migrateTo The active object migrates with
pending requests, objects, futures Automatic
and transparent forwarding of requests, replies
Remote references remain valid
direct
forwarder
direct
14
ProActive Migration of active objects
Migration is initiated by a primitive
migrateTo The active object migrates with
pending requests, objects, futures Automatic
and transparent forwarding of requests, replies
Remote references remain valid
direct
forwarder
direct
15
ProActive Migration of active objects
Migration is initiated by a primitive
migrateTo The active object migrates with
pending requests, objects, futures Automatic
and transparent forwarding of requests, replies
Remote references remain valid
direct
forwarder
direct
16
ProActive Abstract Deployment Model

• A key principle
• Abstract Away from source code
• Machine names, Creation Protocols, Lookup and
  Registry Protocols
• In program source
• Virtual Node (VN, a string name)
• In XML descriptors
• Mapping of VN to JVMs (leads to Node in a JVM on
  Host)
• Register or Lookup VNs
• Create or Acquire JVMs
• Program Source
  Descriptor (RunTime)
• ----------------------------------
  -------------------------------------------
• Activities (AO) --gt VN VN --gt
  JVMs --gt Hosts
• Runtime structured entities 1 VN --gt n
  Nodes in n JVMs

17
Hierarchical Domains for Internet Grid
18
Descriptors Mapping Virtual Nodes

• Component Dependencies
• Provides Uses ...
• VirtualNodes
• Dispatcher ltRegisterIn RMIregistry, Globus,
  Grid Service, gt
• RendererSet
• Mapping
• Dispatcher --gt DispatcherJVM
• RendererSet --gt JVMset
• JVMs
• DispatcherJVM Current // (the current JVM)
• JVMset//ClusterSophia.inria.fr/ ltProtocol
  GlobusGram 10 gt
• ...

Example of an XML file descriptor
19
Monitoring of RMI, Globus, Jini, LSF cluster
Nice -- Baltimore
IC2D Width of links proportional to the
number of com- munications
20
3. Declarative Security
21
Whats a secured ProActive application?

• Composed of classic active objects, no change
  in sources
• Using
• Public Key Infrastructure, X.509 Identity
  Certificates, Access control lists
• XML description language
• PKI Certification chain to identify users, JVMs,
  objects
• User certificate gt Application certificate
  gtactive object certificate
• user private key used only once for generating
  application certificate
• Security policies set by deployment descriptors
• Mobility compliant

22
Security Rule
Entity -gt Entity Interactions Security
Attributes

• Interactions
• JVMCreation
• NodeCreation
• CodeLoading
• ActiveObjectCreation
• ActiveObjectMigration
• Request (Q)
• Reply (P)
• Listing

• Entities
• Domain
• User
• Virtual Node
• Active Object
• Each entity owns a certificate and depends on a
  Certification Authority.

• Attributes
• Authentication (A)
• Integrity (I)
• Confidentiality (C)
• Each attribute can be
• Required ()
• Optional (?)
• Disallowed (-)

23
Descriptors Mapping Virtual Nodes

• VirtualNodes
• Dispatcher ltRegisterIn RMIregistry, Globus,
  Grid Service, gt
• RendererSet
• SECURITY
• VN Renderer -gt VN Dispatcher Q,P
  ?A,?I,?C
• VN Dispatcher -gt VN Renderer Q,P
  ?A,?I,?C
• Domain CardPlus -gt VN Dispatcher Q,P
  A,?I,?C
• Mapping
• Dispatcher --gt DispatcherJVM
• RendererSet --gt JVMset
• JVMs
• DispatcherJVM Current // (the current JVM)
• JVMset//ClusterSophia.inria.fr/ ltProtocol
  GlobusGram 10 gt

Example of an XML file descriptor
24
Certification Chain
main
obj3
obj1
obj2
Generate certificate for
obj4
25
Hierarchical Security Domains

• Logical way to group many entities that have the
  same security needs.
• Domains are hierarchical.
• Sub-domains inherits parents security policies.
• Default Sub-domains cannot weaken parents
  security policies.
• Can override a domain authorizes an entity to
  override its policies (doPrivileged)

26
Multi-level Policies
Computing a security policy according all
matching rules from domains, Virtual Node and
Active Object.
Application-level policy
NegotiatedSecurity policy
Administrator-/ User-level policy
27
Combining Policies

• Search for the most specific rule in each domain
  (if exists).
• Retrieve all matching rules in the Domain
  hierarchy, the Virtual Node and the Active
  Object.
• Compute policies according to security attributes.

28
Migration Security

• Migration can invalidate negotiated policies
• migration to a node of the same domain
• migration to a node of another domain
• gt New Security Negotiation

29
4. Demonstration Declarative Security with
Mobility

• C3D Collaborative 3D renderer in //
• a standard ProActive application
• with the IC2D monitor IC2D Interactive
  Control Debug for Distributionwork with any
  ProActive applicationFeatures Graphical and
  Textual visualization Monitoring and Control

30
C3D Collaborative 3D renderer in //
31
Comparisons with Related Work

• ProActive Basic Features
• Authentication of users and applications
• Authentication, integrity and confidentiality of
  communications
• Security model for fully mobile applications
• Dynamically negotiated policies, non-functional
  security
• Logical representation security is easily
  adaptable to the deployment
• Security Frameworks
• .Net, Legion, Globus no notion of application
  mobility
• Globus Grid Security Infrastructure (GSI)
• single sign on, delegation, and credential
  mapping,
• but no high-level control, no easy encryption of
  communications
• Security in Agent platforms
• Ajanta, Mole, Aglets, MAP limited code mobility
  (fixe host mobile agent)

32
Conclusion

• ProActive Perspectives
• Group communication (key management, find common
  policy)
• Sandboxing of nodes
• Role-based access control
• Components (Distributed, Parallel, Hierarchical)
  and Security
• General Perspectives
• OGSA Security Open Grid Services Architecture
• Globus new open architecture, Web Services based
• Security code no longer instantiated within the
  middleware
• the middleware (and applications) calls external
  Web Security Services
• but high-level abstractions, still needed
  (domain, application-level)

33
Extra Material
34
www.inria.fr/oasis/ProActive
35
Object Diagram for C3D
36
Monitoring graphical and textual com.
37
Standard system at Runtime
38
2.2 Programming vs. Composing

• A model of computation is still needed

39
1.7 Conclusion on the basicsComponent
Orientedness

• Level 1 Instantiate - Deploy - Configure
• Simple Pattern
• Meta-information (file, XML, etc.) JavaBeans,
  EJB
• Level 2 Assembly (flat)
• Use and client interfaces CCM
• Level 3 Hierarchic
• Composite Fractal
• Level 4 Reconfiguration
• Binding, Inclusion, Location On going work
• Interactions / Communications
• Functional Calls service, event, stream
• Non-Functional instantiate, deploy,
  start/stop, inner/outer, re-bind

40
Programming vs. Composing

• The underlying model of parallel and distributed
  computing being
• used is FUNDAMENTAL.
• How to build components that actually compose
• semantics, correctness,
• efficiency, predictability of performance, ...
• without a clearly defined programming model ?
• For 50 years, Computer Science have been looking
  for abstractions
• that compose functions, modules, classes,
  objects,
• The semantics of a composite is solely and well
  defined from the
• semantics of inner components.
  The quest is not over !

41
Component Descriptors

• Defining Provide and Use ports (Server, Client)
• Defining Composite
• Using the Fractal component model, and
• ADL Architecture Description Language
• ObjectWeb, Bruneton-Coupaye-Stefani
• XML descriptors
• Integration with Virtual Nodes

42
Descriptor Example Primitive Component

• ltprimitive-component
• implementation"test.component.car.MotorImpl
  name"motor_1"
• virtualNode"Node2"gt
• ltrequiresgt ltinterface-type cardinality"single
  contingency"mandatory" name"controlWheel"
  signature"test.component.car.Wheel" /gt
• lt/requiresgt
• ltprovidesgt ltinterface-type name"controlMotor"
  signature"test.component.car.Motor" /gt
  lt/providesgt
• lt/primitive-componentgt

43
Descriptor Example Composite Component

• ltcomposite-component name"composite2"
  virtualNode"Node2"gt
• ltprovidesgt ltinterface-type name"controlCompos
  ite2"
• signature"test.component.c
  ar.Motor" /gt
• lt/providesgt
• ltcomposite-component name"composite1"
  virtualNode"Node2"gt
• ltprovidesgt
• ltinterface-type
  name"controlComposite1
• 
  signature"test.component.car.Motor" /gt
• lt/providesgt
• ltprimitive-component ..
• Not to be written nor read by humans !!
• TOOLS

44
Motors and Wheels demo case
composite1
composite2
M1
W1
W2
M2
parallel1
WP4
WP5
WP6
parallel2
45
3. Conclusion
46
Next steps

• Interactively compose components with the
  component view
• Maintain component view at execution
• Formal Semantics of mixing
• Functional, with
• Non Functional calls (start/stop, rebind, in/out,
  )

47
Conclusion -- Perspectives

• Not all models are equivalent Component
  Orientedness
• Level 1 Configuration 2 Assembly 3
  Hierarchic 4Reconfiguration
• Specificity for GRID Components
• Parallel (HPC), Distributed, Collective Op.,
  Deployment, Reconfiguration
• Can programming models be independent of (Grid)
  Components ?
• Do not target the same objectives
• But can components compose, reconfigure
  without a clear model ?
• Reconfiguration is the next big issue
• Life cycle management, but with direct
  communications as much as possible
• For the sake of reliability and fault tolerance
  ---gt GRID
• Error, Exception handling across components
• Checkpointing independent, coordinated, memory
  channel, ...
• Other pending issues
• Peer-to-peer (even more volatile
  reconfiguration is a must), Security, ...

48
Adaptive GRID

• The need for adaptive middleware is now
  acknowledged,
• with dynamic strategies at various points in
  containers, proxies, etc.
• Can we afford adaptive GRID ?
• with dynamic strategies at various points
• (communications, checkpointing, reconfiguration,
  )
• for various conditions (LAN, WAN, network, P2P,
  ...)
• HPC vs. HPC
• High Performance Components vs. High Productivity
  Components

49
Security extra

• Find the first common domain if exists
• A domain has a policy server a certification
  authority
• Dynamically configurable via SSL connections