slide1
Download
Skip this Video
Download Presentation
Denis Caromel, Arnaud Contes inria.fr/oasis/ProActive OASIS Team

Loading in 2 Seconds...

play fullscreen
1 / 49

Denis Caromel, Arnaud Contes inria.fr/oasis/ProActive OASIS Team - PowerPoint PPT Presentation


  • 123 Views
  • Uploaded on

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,

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Denis Caromel, Arnaud Contes inria.fr/oasis/ProActive OASIS Team' - graiden-sykes


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1
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

1 grid and the internet
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)

SECURITYISSUES

issues at hand for grid security
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
2 proactive a java api tools for parallel distributed computing
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)
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.

ProActive : Creating active objects

foo (A a){

a.g (...);

v = a.f (...);

...

v.bar (...);

}

JVM

standard system at runtime
Standard system at Runtime

No sharing between activities

proactive groups
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

proactive migration of active objects
ProActive : Migration of active objects

Migrationis initiated by a primitive: migrateTo

The active object migrates with: pending requests, objects, futures

Automatic and transparent forwarding of: requests, replies

Remotereferencesremainvalid

proactive migration of active objects1
ProActive : Migration of active objects

Migrationis initiated by a primitive: migrateTo

The active object migrates with: pending requests, objects, futures

Automatic and transparent forwarding of: requests, replies

Remotereferencesremainvalid

proactive migration of active objects2
ProActive : Migration of active objects

Migrationis initiated by a primitive: migrateTo

The active object migrates with: pending requests, objects, futures

Automatic and transparent forwarding of: requests, replies

Remotereferencesremainvalid

direct

proactive migration of active objects3
ProActive : Migration of active objects

Migrationis initiated by a primitive: migrateTo

The active object migrates with: pending requests, objects, futures

Automatic and transparent forwarding of: requests, replies

Remotereferencesremainvalid

direct

direct

proactive migration of active objects4
ProActive : Migration of active objects

Migrationis initiated by a primitive: migrateTo

The active object migrates with: pending requests, objects, futures

Automatic and transparent forwarding of: requests, replies

Remotereferencesremainvalid

direct

forwarder

direct

proactive migration of active objects5
ProActive : Migration of active objects

Migrationis initiated by a primitive: migrateTo

The active object migrates with: pending requests, objects, futures

Automatic and transparent forwarding of: requests, replies

Remotereferencesremainvalid

direct

forwarder

direct

proactive migration of active objects6
ProActive : Migration of active objects

Migrationis initiated by a primitive: migrateTo

The active object migrates with: pending requests, objects, futures

Automatic and transparent forwarding of: requests, replies

Remotereferencesremainvalid

direct

forwarder

direct

proactive abstract deployment model
ProActive:AbstractDeploymentModel
  • A key principle:
    • Abstract Away from source code:
      • Machine names, Creation Protocols, Lookup and Registry Protocols
  • In program source:
      • VirtualNode (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
descriptors mapping virtual nodes
Descriptors: Mapping Virtual Nodes
  • Component Dependencies:
  • Provides: … Uses: ...
  • VirtualNodes:
  • Dispatcher
  • RendererSet
  • Mapping:
  • Dispatcher --> DispatcherJVM
  • RendererSet --> JVMset
  • JVMs:
  • DispatcherJVM = Current // (the current JVM)
  • JVMset=//ClusterSophia.inria.fr/
  • ...

Example of

an XML file

descriptor:

monitoring of rmi globus jini lsf cluster nice baltimore
Monitoring of RMI, Globus, Jini, LSF cluster Nice -- Baltimore

IC2D

Width of links

proportional

to the number

of com-

munications

what s a secured proactive application
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.

Security Rule

Entity -> Entity : Interactions # Security Attributes

  • Attributes :
    • Authentication (A)
    • Integrity (I)
    • Confidentiality (C)
  • Each attribute can be :
    • Required (+)
    • Optional (?)
    • Disallowed (-)
descriptors mapping virtual nodes1
Descriptors: Mapping Virtual Nodes
  • VirtualNodes:
  • Dispatcher
  • 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/

Example of

an XML file

descriptor:

certification chain
Certification Chain

main

obj3

obj2

obj1

Generate certificate for

obj4

hierarchical security domains
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

Dn-1

Accept Deny

Accept Deny

Accept Deny

Accept Deny

Accept Deny

D0

VN

AO

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

combining policies
Receiver

Required (+)

Optional (?)

Disallowed (-)

Sender

Required (+)

+

invalid

+

Optional (?)

?

-

+

Disallowed (-)

invalid

-

-

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.
migration security
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
4. Demonstration:Declarative Security with Mobility

C3D : Collaborative 3D renderer in //

a standard ProActive application

  • with the IC2D monitorIC2D: Interactive Control & Debug for Distributionwork with any ProActive applicationFeatures: Graphical and Textual visualization Monitoring and Control
comparisons with related work
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)
conclusion
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: OpenGridServicesArchitecture
      • 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)

2 2 programming vs composing

2.2 Programming vs. Composing

A model of computation is still needed

1 7 conclusion on the basics component orientedness
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, stream
  • Non-Functional: instantiate, deploy, start/stop, inner/outer, re-bind
programming vs composing
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
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
Descriptor Example: Primitive Component
  • implementation="test.component.car.MotorImpl” name="motor_1"
  • virtualNode="Node2">
descriptor example composite component
Descriptor Example: Composite Component
  • signature="test.component.car.Motor" />
  • Not to be written nor read by humans !!
  • TOOLS
slide44
WP1

WP2

WP3

Motors and Wheels demo case

composite1

composite2

M1

W1

W2

M2

parallel1

WP4

WP5

WP6

parallel2

next steps
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 perspectives
Conclusion -- Perspectives
  • Not 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 grid
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
security extra
Security extra
  • Find the first common domain if exists
  • A domain has a policy server + a certification authority
  • Dynamically configurable via SSL connections
ad