1 / 49

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

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,

Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related