1. 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 Declarative Security for GRID Applications: ProActive

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

6. 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 (...); }

7. Standard system at Runtime No sharing between activities

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

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

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

13. ProActive : Migration of active objects 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

14. ProActive : Migration of active objects 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

15. ProActive : Migration of active objects 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

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) --> VN VN --> JVMs --> Hosts Runtime structured entities: 1 VN --> n Nodes in n JVMs

17. Hierarchical Domains for Internet Grid

18. 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:

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

22. 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 (-)

23. 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:

24. Certification Chain main Generate certificate for obj1 obj2 obj3 obj4

25. 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)

26. Multi-level Policies DnDn Accept Deny D0D0 D n-1 Accept Deny VN Accept Deny AO Accept Deny Computing a security policy according all matching rules from domains, Virtual Node and Active Object. Negotiated Security policy Administrator-/ User-level policy Application-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. Required (+) Optional (?) Disallowed (-) Optional (?) Disallowed (-) Sender Receiver + + + ? - - - invalid

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

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 Distribution work with any ProActive application Features: 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 basics: Component Orientedness Level 1: Instantiate - Deploy - Configure Simple Pattern Meta-information (file, XML, etc.)JavaBeans, EJB Level 2: Assembly (flat) Use and client interfacesCCM Level 3: Hierarchic CompositeFractal 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 <primitive-component implementation="test.component.car.MotorImpl” name="motor_1" virtualNode="Node2">

43. Descriptor Example: Composite Component <interface-type name="controlComposite2" signature="test.component.car.Motor" /> <interface-type name="controlComposite1” signature="test.component.car.Motor" /> <primitive-component ….. Not to be written nor read by humans !! TOOLS

44. WP1WP2WP3 M1 M2 Motors and Wheels demo case WP4 WP5 W1 W2 composite2 composite1 WP6 parallel2 parallel1

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

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