Denis Caromel, Arnaud Contes inria.fr/oasis/ProActive OASIS Team

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

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

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 Migrationis initiated by a primitive: migrateTo The active object migrates with: pending requests, objects, futures Automatic and transparent forwarding of: requests, replies Remotereferencesremainvalid

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

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

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

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

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

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

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

17. Hierarchical Domains for Internet Grid

18. Descriptors: Mapping Virtual Nodes • Component 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:

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

23. Descriptors: Mapping Virtual Nodes • VirtualNodes: • 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:

24. Certification Chain main obj3 obj2 obj1 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 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. 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

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

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 monitorIC2D: 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: 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)

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

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

44. WP1 WP2 WP3 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 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