Denis Caromel, Arnaud Conteswww.inria.fr/oasis/ProActive

OASIS TeamINRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis

1. Introduction to the GRID2. ProActive: Remote Objects, Groups, Mobile Objects,

Graphical Interface (IC2D), XML Deployment,

3. Declarative Security4. Demonstration

Declarative Security for GRID Applications: ProActive

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

Hierarchical Domains for Internet Grid

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

• 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)

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

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.

ProActive : Creating active objects

JVM

foo (A a){ a.g (...); v = a.f (...); ... v.bar (...);}

Standard system at Runtime

No sharing between activities

ProActive: Groups

Typed Group Remote Object

A ag = newActiveGroup («A»,…,Nodes)V v = ag.foo(param); v.bar();

V

A

Typed and polymorphic Groups of active and remote objects

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

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

ProActive : Migration of active objects

direct

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

ProActive : Migration of active objects

direct

direct

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

ProActive : Migration of active objects

direct

direct

forwarder

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

ProActive : Migration of active objects

direct

direct

forwarder

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

ProActive : Migration of active objects

direct

direct

forwarder

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

ProActive: Abstract Deployment ModelA 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) --> VN VN --> JVMs --> Hosts

Runtime structured entities: 1 VN --> n Nodes in n JVMs

Hierarchical Domains for Internet Grid

Descriptors: Mapping Virtual NodesComponent Dependencies:

Provides: … Uses: ...

VirtualNodes:

Dispatcher <RegisterIn RMIregistry, Globus, Grid Service, … >

RendererSet

Mapping:

Dispatcher --> DispatcherJVM

RendererSet --> JVMset

JVMs:

DispatcherJVM = Current // (the current JVM)

JVMset=//ClusterSophia.inria.fr/ <Protocol GlobusGram … 10 >

...

Example of

an XML file

descriptor:

Monitoring of RMI, Globus, Jini, LSF cluster Nice -- Baltimore

IC2D

Width of links

proportional

to the number

of com-

munications

3. Declarative Security

What’s 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 => Application certificate =>active object certificate

• user private key used only once for generating application certificate

• Security policies set by deployment descriptors

• Mobility compliant

Security Rule

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.

Entity -> Entity : Interactions # Security Attributes

Attributes :• Authentication (A)

• Integrity (I)

• Confidentiality (C)

Each attribute can be :• Required (+)

• Optional (?)

• Disallowed (-)

Descriptors: Mapping Virtual NodesVirtualNodes:

Dispatcher <RegisterIn RMIregistry, Globus, Grid Service, … >

RendererSet

SECURITY:

VN [Renderer] -> VN [Dispatcher] : Q,P # [?A,?I,?C]

VN [Dispatcher] -> VN [Renderer] : Q,P # [?A,?I,?C]

Domain [CardPlus] -> VN [Dispatcher] : Q,P # [+A,?I,?C]Mapping:

Dispatcher --> DispatcherJVM

RendererSet --> JVMset

JVMs:

DispatcherJVM = Current // (the current JVM)

JVMset=//ClusterSophia.inria.fr/ <Protocol GlobusGram … 10 >

Example of

an XML file

descriptor:

Certification Chain

main

Generate certificate for

obj1 obj2 obj3

obj4

Hierarchical Security Domains

• Logical way to group many entities that have the same security needs.

• Domains are hierarchical.

• Sub-domains inherits parent’s security policies.

• Default : Sub-domains cannot weaken parent’s security policies.

• ‘Can override‘ : a domain authorizes an entity to override its policies (doPrivileged)

Multi-level Policies

Dn

Accept Deny

D0

Accept Deny

Dn-1

Accept Deny

VN

Accept DenyAO

Accept Deny

Computing a security policy according all matching rules from domains, Virtual Node and Active Object.

NegotiatedSecurity policyAdministrator-/

User-level policy

Application-level policy

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.

Required (+)

Required (+)

Optional (?)

Disallowed (-)

Optional (?)

Disallowed (-)

SenderReceiver

+ +

+ ?

- -

-

invalid

invalid

Migration & Security

• Migration can invalidate negotiated policies :

• migration to a node of the same domain

• migration to a node of another domain

===> New Security Negotiation

4. Demonstration: Declarative Security with Mobility

C3D : Collaborative 3D renderer in // a standard ProActive application

with the IC2D monitor IC2D: Interactive Control & Debug for Distribution

work with any ProActive applicationFeatures:

Graphical and Textual visualization Monitoring and Control

C3D : Collaborative 3D renderer in //

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)

ConclusionProActive 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)

Extra Material

www.inria.fr/oasis/ProActive

Object Diagram for C3D

Monitoring: graphical and textual com.

Standard system at Runtime

2.2 Programming vs. Composing

A model of computation is still needed

1.7 Conclusion on the basics:Component 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, streamNon-Functional: instantiate, deploy, start/stop, inner/outer, re-bind

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 !

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

Descriptor Example: Primitive Component

<primitive-component

implementation="test.component.car.MotorImpl” name="motor_1"

virtualNode="Node2">

<requires> <interface-type cardinality="single” contingency="mandatory"

name="controlWheel" signature="test.component.car.Wheel" />

</requires>

<provides> <interface-type name="controlMotor"

signature="test.component.car.Motor" /> </provides>

</primitive-component>

Descriptor Example: Composite Component

<composite-component name="composite2" virtualNode="Node2"> <provides> <interface-type name="controlComposite2" signature="test.component.car.Motor" /> </provides> <composite-component name="composite1" virtualNode="Node2">

<provides> <interface-type name="controlComposite1” signature="test.component.car.Motor" />

</provides> <primitive-component …..

Not to be written nor read by humans !!TOOLS

WP1

WP2

WP3

M1

M2

Motors and Wheels demo case

WP4

WP5

W1

W2

composite2composite1

WP6 parallel2

parallel1

3. Conclusion

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, …)

Conclusion -- PerspectivesNot all models are equivalent: Component Orientedness

Level 1: Configuration 2: Assembly 3: Hierarchic 4:Reconfiguration

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 ---> 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, ...

Adaptive GRIDThe 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

Security extra

• Find the first common domain if exists

• A domain has a policy server + a certification authority

• Dynamically configurable via SSL connections