<commit_before><?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="viewDocbook.css"?>
<chapter id="Security">
  <title>ProActive Security Mechanism</title>

  <para>In order to use the Proactive Security features, you have to
  install<emphasis role="bold">the Java(TM) Cryptography Extension (JCE)
  Unlimited Strength Jurisdiction Policy Files</emphasis> available at 
  <ulink url="http://www.java.sun.com">Sun's website</ulink>. Extract the file 
   and copy jar files to your &lt;jre_home&gt;/lib/security.</para>

  <sect1 >
    <title>Overview</title>

    <para>Usually, applications and security are developed for a specific use.
    We propose here a security framework that allows to dynamically deploy
    applications and to configure security according to this
    deployment.</para>

    <para>ProActive security mechanism provides a set of security features
    from basic ones like communications authentication, integrity,
    confidentiality to more high-level features including migration security
    mechanism, hierarchical security policies, dynamically negotiated
    policies. All theses features are expressed inside the meta-level of the
    middleware and used transparently by applications.</para>

    <para>It is possible to attach security policies to Runtimes, Virtual
    Nodes, Nodes and Active Objects. Policies are expressed inside an XML
    descriptor.</para>
  </sect1>

  <sect1 >
    <title>Security Architecture</title>

    <sect2 >
      <title>Base model</title>

      <para>A distributed or concurrent application built using
      <emphasis>ProActive</emphasis> is composed of a number of medium-grained
      entities called <emphasis>active objects</emphasis>. Each active object
      has one distinguished element, the <emphasis>root</emphasis>, which is
      the only entry point to the active object; all other objects inside the
      active object are called <emphasis>passive objects</emphasis> and cannot
      be referenced directly from objects which are outside this active object
      (see following figure); the absence of sharing is important with respect
      to security.</para>

      <para><figure>
          <title>A typical object graph with active objects</title>

          <mediaobject>
            <imageobject>
              <imagedata fileref="security_images/activeObjects.png"
                         format="PNG"  contentwidth="100" width="6in"/>
            </imageobject>
          </mediaobject>
        </figure></para>

      <para>The security is based on Public Key Infrastructure. Each entity
      owns a certificate and an private key generated from the certificate of
      a user.</para>

      <para>Certificates are generated automatically by the security
      mechanism. The validity of a certificate is checked by validating its
      certificate chain. As shown in the next figure, before validating the
      certificate of an active object, application certificate and user
      certificate will be checked. If a valid path is found so object
      certificate is validated.</para>

      <para><figure>
          <title>Certificate chain</title>

          <mediaobject>
            <imageobject>
              <imagedata fileref="security_images/certificateGeneration.png"
                         format="PNG" />
            </imageobject>
          </mediaobject>
        </figure></para>
    </sect2>

    <sect2 >
     <title>Security is expressed at different levels</title>
     
     <para>Security is expressed at different levels, according to who wants
      to set policy:</para>

      <itemizedlist>
        <listitem>
          <para>Administrators set policy at domain level. It contains general
          security rules.</para>
        </listitem>

        <listitem>
          <para>Resource provider set policy for resource. People who have
          access to a cluster and wants to offer cpu time under some
          restrictions. The runtime loads its policy file at launch
          time.</para>
        </listitem>

        <listitem>
          <para>Application level policy is set when an application is
          deployed through an XML descriptor.</para>
        </listitem>
      </itemizedlist>

      <para><figure>
          <title>Hierarchical security</title>

          <mediaobject>
            <imageobject>
              <imagedata fileref="security_images/security-hierarchy.png"
                         format="PNG" />
            </imageobject>
          </mediaobject>
        </figure></para>

      <para>When an interaction is happening, all participating entities'
      security policy are verified and combined to find the policy to enforce
      to the interaction.</para>
    </sect2>
  </sect1>

  <sect1 >
    <title>Detailed Security
    Architecture</title>

    <sect2 >
      <title>Virtual Nodes and Nodes</title>

      <para>The security architecture relies on two related abstractions for
      deploying Grid applications: <emphasis>Node</emphasis> and
      <emphasis>Virtual Node</emphasis>. A node gathers several objects in a
      logical entity. It provides an abstraction for the physical location of
      a set of activities. Objects are bound to a node at creation or after
      migration. In order to have a flexible deployment (eliminating from the
      source code machine names, creation protocols), the system relies on
      <emphasis>Virtual Nodes</emphasis> (VNs). A VN is identified as a name
      (a simple string), used in a program source, defined and configured in
      an descriptor. The user can attach policy to these virtual nodes.
      Virtual Nodes are used within application code to structure it. By
      example, an object which will be used as a server will be set inside a
      virtual node named Server_VN, client objects will be set inside
      Client_VN. The user expresses policy between server and client object
      inside a descriptor file. The correspondence between Virtual Nodes and
      Nodes, the mapping, is done at application starting time.</para>
    </sect2>

    <sect2  id="Security_html_SECTION00033000000000000000">
      <title>Hierarchical Security Entities</title>

      <para>Grid programming is about deploying processes (activities) on
      various machines. In the end, the security policy that must be ensured
      for those processes depends upon many factors: first of all, the
      application policy that is needed, but also the machine locations, the
      security policies of their administrative domain, and the network being
      used to reach those machines.</para>

      <para>Previous section defined the notions of <emphasis>Virtual
      Nodes</emphasis>, and <emphasis>Nodes</emphasis>. Virtual Nodes are
      application abstractions, and nodes are only a run-time entity resulting
      from the deployment: a mapping of Virtual Nodes to processes and hosts.
      A first decisive feature allows to define application-level security on
      those application-level abstractions:</para>

      <para><informalfigure>
          <mediaobject>
            <imageobject>
             <imagedata fileref="security_images/img3.png" format="PNG" contentwidth="100" width="6in"/>
            </imageobject>
          </mediaobject>
        </informalfigure></para>

      <para>As such, virtual nodes are the support for intrinsic application
      level security. If, at design time, it appears that a process always
      requires a specific level of security (e.g. authenticated and encrypted
      communications at all time), then that process should be attached to a
      virtual node on which those security features are imposed. It is the
      designer responsibility to structure his/her application or components
      into virtual node abstractions compatible with the required security.
      Whatever deployment occurs, those security features will be maintained.
      We expect this usage to be rather occasional, for instance in very
      sensitive applications where even an intranet deployment calls for
      encrypted communications.</para>

      <para>The second decisive feature deals with a major Grid aspect:
      deployment-specific security. The issue is actually twofold:</para>

      <orderedlist>
        <listitem>
          <para>allowing organizations (security domains) to specify general
          security policies,</para>
        </listitem>

        <listitem>
          <para>allowing application security to be specifically adapted to a
          given deployment environment.</para>
        </listitem>
      </orderedlist>

      <para>Domains are a standard way to structure (virtual) organizations
      involved in a Grid infrastructure; they are organized in a hierarchical
      manner. They are the logical concept allowing to express security
      policies in a hierarchical way.</para>

      <para><informalfigure>
          <mediaobject>
            <imageobject>
             <imagedata fileref="security_images/img4.png" format="PNG" contentwidth="100" width="6in"/>
            </imageobject>
          </mediaobject>
        </informalfigure></para>

      <para>This principle allows to deal with the two issues mentioned
      above:</para>

      <para>(1) the administrator of a domain can define specific policy rules
      that must be obeyed by the applications running within the domain.
      However, a general rule expressed inside a domain may prevent the
      deployment of a specific application. To solve this issue, a policy rule
      can allow a well-defined entity to weaken it. As we are in a
      hierarchical organization, allowing an entity to weaken a rule means
      allowing all entities included to weaken the rule. The entity can be
      identified by its certificate;</para>

      <para>(2) a Grid user can, at the time he runs an application, specify
      additional security based on the domains being deployed onto.</para>

      <para>The Grid user can specify additional rules directly in his
      deployment descriptor for the domains he deploys onto. Note that those
      domains are actually dynamic as they can be obtained through external
      allocators, or even Web Services in an OGSA infrastructure 
      (see <citation><xref linkend="foster98security" endterm="foster98security.abbrev"/></citation>).
      Joker rules might be important in that case to cover all cases, and to provide
      a conservative security strategy for un-forecasted deployments.</para>

      <para>Finally, as active objects are active and mobile entities, there
      is a need to specify security at the level of such entities.</para>

      <para><informalfigure>
          <mediaobject>
            <imageobject>
             <imagedata fileref="security_images/img6.png" format="PNG" contentwidth="100" width="6in"/>
            </imageobject>
          </mediaobject>
        </informalfigure></para>

      <para>In open applications, e.g. several principals interacting in a
      collaborative Grid application, a JVM (a process) launched by a given
      principal can actually host an activity executing under another
      principal. The principle above allows to keep specific security
      privileges in such case. Moreover, it can also serve as a basis to
      offer, in a secure manner, hosting environments for mobile
      agents.</para>

      <para><figure>
          <title>Syntax and attributes for policy rules</title>

          <mediaobject>
            <imageobject>
              <imagedata fileref="security_images/img8.png" format="PNG" />
            </imageobject>
          </mediaobject>
        </figure></para>
    </sect2>

    <sect2  id="Security_html_SECTION00034000000000000000">
      <title>Resource provider security features</title>

      <para>Prior to start application on a Grid, a user needs to acquire some
      resources (CPU time, disk storage, bandwidth) from the Grid. A
      <emphasis>Resource provider</emphasis> is an individual, a research
      institute, an organization who wants to offer some resources under a
      certain security policy to a restricted set of peoples. According to our
      definition, resource provider will set up one or more runtime where
      clients will be able do perform computation. Each runtime is set with
      its own policy. Theses runtimes could be worldwide distributed.</para>
    </sect2>

    <sect2  id="Security_html_SECTION00037000000000000000">
      <title>Interactions, Security Attributes</title>

      <para>Security policies are able to control all the
      <emphasis>interactions</emphasis> that can occur when deploying and
      executing a multi-principals Grid application. With this goal in mind,
      interactions span over the creation of processes, to the monitoring of
      activities (Objects) within processes, including of course the
      communications. Here is a brief description of those
      interactions:</para>

     <indexterm><primary>Migration</primary><secondary>security</secondary></indexterm>
 
     
     <itemizedlist>
        <listitem>
          <para>RuntimeCreation (RC): creation of a new Runtime process</para>
        </listitem>

        <listitem>
          <para>NodeCreation (NC): creation of a new Node within a Runtime (as
          the result of Virtual Node mapping)</para>
        </listitem>

        <listitem>
          <para>CodeLoading (CL): loading of bytecode within a Node, used in
          presence of object migration.</para>
        </listitem>

        <listitem>
          <para>ObjectCreation (OC): creation of a new activity (active
          object) within a Node</para>
        </listitem>

        <listitem>
          <para>ObjectMigration (OM): migration of an existing activity object
          to a Node</para>
        </listitem>

        <listitem>
          <para>Request (Q), Reply (P): communications, method calls and
          replies to method calls</para>
        </listitem>

        <listitem>
          <para>Listing (L): list the content of an entity; for Domain/Node
          provides the list of Node/Objects, for an Object allows to monitor
          its activity.</para>
        </listitem>
      </itemizedlist>

      <para>For instance, a domain is able to specify that it accepts
      downloading of code from a given set of domains, provided the transfers
      are authenticated and guaranteed not to be tampered with. As a policy
      might leave open the integrity of communications, and also because not
      allowing confidentiality can be a domain (or even a country) policy,
      those 3 security attributes can be specified in 3 modes: Required
      (<emphasis role="bold">+</emphasis>), Optional (<emphasis
      role="bold">?</emphasis>), Disallowed (<emphasis
      role="bold">-</emphasis>)</para>

      <para>For a given interaction, a tuple [+A,?I,-C] means that
      authentication is required, integrity is accepted but not required, and
      confidentiality is not allowed.</para>

      <para>As a Grid operates in decentralized mode, without a central
      administrator controlling the correctness of all security policies,
      these policies must be <emphasis>combined</emphasis>,
      <emphasis>checked</emphasis>, and <emphasis>negotiated</emphasis>
      dynamically. The next two sections present that aspect.</para>
    </sect2>

    <sect2  id="Security_html_SECTION00038000000000000000">
      <title>Combining Policies</title>

      <para>As the proposed infrastructure takes into account different actors
      of the Grid (domain administrator, Grid user), even for a
      single-principal single-domain application, there are potentially
      several security policies activated. This section deals with the
      combination of those policies to obtain the final security tuples of a
      single entity. An important principle being that a sub-domain cannot
      weaken a super-domain's rule.</para>

      <para>During execution, each activity (Active Object) is always included
      in a <emphasis>Node</emphasis> (due to the Virtual Node mapping) and at
      least in one <emphasis>Domain</emphasis>, the one used to launch a JVM 
      (D<subscript>0</subscript>).   <xref linkend="HierarchicalSecurityLevels"/>
      hierarchically represents the security rules that can be activated at
      execution: from the top, hierarchical domains 
      (D<subscript>1</subscript> to D<subscript>0</subscript>), the virtual node policy (VN), and the Object
      (O) policy. Of course, such policies can be inconsistent, and there must
      be clear principles to combine the various sets of rules.</para>

     <para><figure id="HierarchicalSecurityLevels">
          <title>Hierarchical Security Levels</title>

          <mediaobject>
            <imageobject>
              <imagedata fileref="security_images/img11.png" format="PNG" />
            </imageobject>
          </mediaobject>
        </figure></para>

      <para>There are three main principles: (1) choosing the <emphasis>most
      specific rules</emphasis> within a given domain (as a single Grid actor
      is responsible for it), (2) an interaction is valid only if all levels
      accept it (absence of weakening of authorizations), (3) the security
      attributes retained are the most constrained based on a partial order
      (absence of weakening of security).</para>

      <screen>          Domain[*] -&gt; Domain[*]: Q,P: [+A,+I,+C] 
          Domain[CardPlus] -&gt; Domain[CardPlus]: Q,P: [+A,?I,?C] </screen>

      <para>within the CardPlus domain, the second rule will be chosen
      (integrity and confidentiality will be optional). Of course, comparison
      of rules is only a partial order, and several incompatible most specific
      rules can exist within a single level (e.g. both ACCEPT and DENY most
      specific rules for the same interaction, or both +A and -A).</para>

      <para>Between levels, an incompatibility can also occur, especially if a
      sub-level attempts to weaken the policy on a given interaction (e.g. a
      domain prohibits confidentiality [-C] while a sub-domain or the Virtual
      Node requires it [+C], a domain D<subscript>i</subscript> prohibits
      loading of code while D<subscript>j</subscript> (j &lt;= i) authorizes
      it). In all incompatible cases, the interaction is not authorized and an
      error is reported.</para>
    </sect2>

    <sect2 >
      <title>Dynamic Policy Negotiation</title>

      <para>During execution, entities interact by pair with each other. Each
      entity, for each interaction (JVM creation, communication, migration,
      ...), will want to apply a security policy based on the resolution
      presented in the previous section. Before starting an interaction, a
      <emphasis>negotiation</emphasis> occurs between the two entities
      involved. <xref linkend="Result_of_security_negotiations"/>
      shows the result of such negotiation. For example, if for a given
      interaction, entity A's policy is [+A,?I,?C], and B's policy is
      [+A,?I,-C], the negotiated policy will be [A,?I,-C]. If, for a result
      rule, one of the communication attributes is optional, the attribute is
      not activated.</para>

      <para>Besides the interactions not being accepted by an entity, two
      other cases lead to an error: when an attribute is required by one, and
      disallowed by the other. In such cases, the interaction is not
      authorized and an error is reported. If a valid security policy is found
      between two entities, the interaction can occur. In the case that the
      agreed security policy includes confidentiality, the two entities
      negotiate a session key.</para>

     <table id="Result_of_security_negotiations" frame="none">
          <title>Result of security negotiations</title>
          <tgroup cols="1">
            <tbody>
              <row>
                <entry align="center"> 
                 <para><informalfigure id="SecurityNegotiation">
                  <mediaobject>
                   <imageobject>
                    <imagedata fileref="security_images/negotiation.png" format="PNG" />
                   </imageobject>
                  </mediaobject>
                 </informalfigure></para>
                </entry>
              </row>
            </tbody>
          </tgroup>
        </table>
    </sect2>

    <sect2>

     <title>Migration and Negotiation</title>

		 <indexterm><primary>Migration</primary><secondary>security</secondary></indexterm>
      
		 <para>In large scale Grid applications, migration of activities is an
      important issue. The migration of Active Objects must not weaken the
      security policy being applied.</para>

      <para>When an active object migrates to a new location, three cases may
      happen:</para>

      <itemizedlist>
        <listitem>
          <para>the object migrates to a node belonging to the same virtual
          node and included inside the same domain. In this case, all already
          negotiated sessions remain valid.</para>
        </listitem>

        <listitem>
          <para>the object migrates to a known node (created during the
          deployment step) but which belongs to another virtual node. In this
          case, all already negotiated sessions can be invalid. This kind of
          migration imposes re-establishing the object policy, and upon a
          change, re-negotiating with interacting entities.</para>
        </listitem>

        <listitem>
          <para>The object migrates to an unknown node (not known at the
          deployment step). In this case, the object migrates with a copy of
          the application security policy. When a secured interaction will
          take place, the security system retrieves not only the object's
          application policy but also policies rules attached to the node on
          which the object is to compute the policy.</para>
        </listitem>
      </itemizedlist>
    </sect2>
  </sect1>

  <sect1 >
    <title>Activating security
    mechanism</title>

    <para>Within descriptor, the tag &lt;security&gt; is used to specify the
    policy for the deployed application. It will be the policy for all Nodes
    and active that will be created.</para>

    <para>the descriptor is:</para>

    <screen> 1:&lt;?xml version='1.0' encoding='UTF-8'?&gt;
 2:&lt;ProActiveDescriptor xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'  xsi:noNamespaceSchemaLocation='DescriptorSchema.xsd'&gt;
 3: &lt;security file='../../descriptors/applicationPolicy.xml'&gt;&lt;/security&gt;
 4: &lt;componentDefinition&gt;
 5: &lt;virtualNodesDefinition&gt;
 6: &lt;virtualNode name='Locale' property='unique'/&gt;
 7: &lt;virtualNode name='vm1' property='unique'/&gt;
 8: &lt;virtualNode name='vm2' property='unique'/&gt;
 9: &lt;/virtualNodesDefinition&gt;
 10: &lt;/componentDefinition&gt;
 11: ....
 50:&lt;infrastructure&gt;
 51: &lt;processes&gt; 
 52: &lt;processDefinition id='linuxJVM'&gt;
 53: &lt;jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'&gt;
 54: &lt;classpath&gt;
 ....
 74: &lt;/classpath&gt;
 75: &lt;jvmParameters&gt;
 &lt;parameter value='-Dproactive.runtime.security=/.../descriptors/jvm1-sec.xml'/&gt;
 82: &lt;/jvmParameters&gt;
 83: &lt;/jvmProcess&gt;
 84: &lt;/processDefinition&gt;
 ....</screen>

    <para>Inside the policy file, you can express policy between entities
    (domain, runtime, node, active object).</para>

    <para>The entity tag can be used to:</para>

    <itemizedlist>
      <listitem>
        <para>express policies on entities described inside the descriptor
        (lines 13, 15)</para>
      </listitem>

      <listitem>
        <para>express policies on existing entities by specifying theirs
        certificates (line 32).</para>
      </listitem>
    </itemizedlist>

    <sect2 >
      <title>Construction of an XML policy:</title>

      <para>A policy file must begin with:</para>

      <screen> 1:&lt;?xml version='1.0' encoding='UTF-8'?&gt;
 2:&lt;Policy&gt;</screen>

      <para>next, application specific informations are given.</para>

      <screen> 3: &lt;ApplicationName&gt;Garden&lt;/ApplicationName&gt; </screen>

      <para>&lt;ApplicationName&gt; sets the application name. This allows to
      identify easily which application an entity belongs to.</para>

      <screen> 4: &lt;Certificate&gt;/.../appli.cert&lt;/Certificate&gt;
 5: &lt;PrivateKey&gt;/.../appli.key&lt;/PrivateKey&gt;</screen>

      <para>&lt;Certificate&gt; is the X509 certificate of the application,
      generated from a user certificate, and</para>

      <para>&lt;PrivateKey&gt; the private key associated to the
      certificate.</para>

      <screen> 6: &lt;CertificationAuthority&gt;
 7: &lt;Certificate&gt;/.../ca.cert&lt;/Certificate&gt;
 8: &lt;/CertificationAuthority&gt;</screen>

      <para>&lt;CertificationAuthority&gt; contains all trusted certificate
      authority. Each &lt;Certificate&gt; contains a certification authority
      certificate.</para>

      <screen> 10: &lt;Rules&gt; </screen>

      <para>Then we can define policy rules. All rules are located within the
      &lt;Rules&gt;</para>

      <para>A &lt;Rule&gt; is constructed according the following syntax:</para>

      <screen> 11: &lt;Rule&gt; </screen>

      <para>&lt;From&gt; tag contains all entities from which the interaction
      is made. It is possible to specify many entities in order to match a
      specific fine-grained policy.</para>

      <screen> 12: &lt;From&gt;
 13: &lt;Entity type='VN' name='vm2'/&gt;
 14: &lt;/From&gt;</screen>

      <para>&lt;Entity&gt; is used to define an entity. the 'type' parameter
      can be 'VN', 'certificate'.</para>

      <itemizedlist>
        <listitem>
          <para>'VN' (Virtual Node) referrers to virtual nodes defined inside
          the deployment descriptor.</para>
        </listitem>

        <listitem>
          <para>'DefaultVirtualNode' is a special tag. It allows to specify a
          default policy.</para>
        </listitem>

        <listitem>
          <para>'certificate' supposes that a path to a file is set inside the
          'name' parameters.</para>
        </listitem>
      </itemizedlist>

      <para>&lt;To&gt; tag contains all entities onto the interaction is made.
      As &lt;From&gt; tag, many entities can be specified.</para>

      <screen> 15: &lt;To&gt;
 16: &lt;Entity type='VN' name='Locale'/&gt;
 17: &lt;/To&gt;</screen>

      <para>The &lt;Communication&gt; tag defines security policies to apply
      to requests and replies.</para>

      <screen> 18: &lt;Communication&gt; </screen>

      <para>&lt;Request&gt; sets the policy associated a request. the 'value'
      parameter can be:</para>

      <itemizedlist>
        <listitem>
          <para>'authorized' means a request is authorized.</para>
        </listitem>

        <listitem>
          <para>'denied' means a request is denied.</para>
        </listitem>
      </itemizedlist>

      <para>Each &lt;Attribute&gt; (authentication,integrity, confidentiality)
      can be required, optional or denied.</para>

      <screen>  19: &lt;Request value='authorized'&gt;
  20:   &lt;Attributes authentication='required' integrity='optional' confidentiality='optional'/&gt; 
  21: &lt;/Request&gt;</screen>

      <para>&lt;Reply&gt; tag has the same parameters that
      &lt;Request&gt;</para>

      <screen> 22:&lt;Reply value='authorized'&gt;
 23: &lt;Attributes authentication='required' integrity='required' confidentiality='required'/&gt;
 24:&lt;/Reply&gt;
 25:&lt;/Communication&gt;</screen>

      <para>&lt;Migration&gt; allows or not migration from &lt;from&gt;
      entities to &lt;To&gt; entities. Values can be 'denied' or
      'authorized'.</para>

      <screen> 26: &lt;Migration&gt;denied&lt;/Migration&gt; </screen>

      <para>&lt;OACreation&gt; allows or not creation of active objects by
      &lt;From&gt; entities onto &lt;To&gt; entities.</para>

      <para>Values can be 'denied' or 'authorized'.</para>

      <screen> 27: &lt;OACreation&gt;denied&lt;/OACreation&gt; </screen>

      <screen> 1:&lt;?xml version='1.0' encoding='UTF-8'?&gt;
 2:&lt;Policy&gt;
 3: &lt;ApplicationName&gt;Garden&lt;/ApplicationName&gt;
 4: &lt;Certificate&gt;/net/home/acontes/certif/appli.cert&lt;/Certificate&gt;
 5: &lt;PrivateKey&gt;/net/home/acontes/certif/appli.key&lt;/PrivateKey&gt;
 6: &lt;CertificationAuthority&gt;
 7: &lt;Certificate&gt;&lt;/Certificate&gt;
 8: &lt;/CertificationAuthority&gt;
 9:
 10: &lt;Rules&gt;
 11: &lt;Rule&gt;
 12: &lt;From&gt;
 13: &lt;Entity type='VN' name='vm2'/&gt;
 14: &lt;/From&gt;
 15: &lt;To&gt;
 16: &lt;Entity type='VN' name='Locale'/&gt;
 17: &lt;/To&gt;
 18: &lt;Communication&gt;
 19: &lt;Request value='authorized'&gt;
 20: &lt;Attributes authentication='required' integrity='required' confidentiality='required'/&gt;
 21: &lt;/Request&gt;
 22: &lt;Reply value='authorized'&gt;
 23: &lt;Attributes authentication='required' integrity='required' confidentiality='required'/&gt;
 24: &lt;/Reply&gt;
 25: &lt;/Communication&gt;
 26: &lt;Migration&gt;denied&lt;/Migration&gt;
 27: &lt;OACreation&gt;denied&lt;/OACreation&gt;
 28:
 29: &lt;/Rule&gt;
 30: &lt;Rule&gt;
 31: &lt;From&gt;
 32: &lt;Entity type='certificate' name='certificateRuntime1.cert'/&gt;
 33: &lt;/From&gt;
 34: &lt;To&gt;
 35: &lt;Entity type='VN' name='Locale'/&gt;
 36: &lt;/To&gt;
 37: &lt;Communication&gt;
 38: &lt;Request value='authorized'&gt;
 39: &lt;Attributes authentication='required' integrity='required' confidentiality='required'/&gt;
 40: &lt;/Request&gt;
 41: &lt;Reply value='authorized'&gt;
 42: &lt;Attributes authentication='required' integrity='required' confidentiality='required'/&gt;
 43: &lt;/Reply&gt;
 44: &lt;/Communication&gt;
 45: &lt;Migration&gt;denied&lt;/Migration&gt;
 46: &lt;OACreation&gt;denied&lt;/OACreation&gt;
 47:
 48: &lt;/Rule&gt;
 ...
 90: &lt;Rule&gt;
 91: &lt;From&gt;
 92: &lt;Entity type='DefaultVirtualNode' name='*'/&gt;
 93: &lt;/From&gt;
 94: &lt;To&gt;
 95: &lt;Entity type='DefaultVirtualNode' name='*'/&gt;
 96: &lt;/To&gt;
 97: &lt;Communication&gt;
 98: &lt;Request value='denied'&gt;
 99: &lt;Attributes authentication='optional' integrity='optional' confidentiality='optional'/&gt;
 100: &lt;/Request&gt;
 101: &lt;Reply value='denied'&gt;
 102: &lt;Attributes authentication='optional' integrity='optional' confidentiality='optional'/&gt;
 103:
 104: &lt;/Reply&gt;
 105: &lt;/Communication&gt;
 106: &lt;Migration&gt;denied&lt;/Migration&gt;
 107: &lt;OACreation&gt;authorized&lt;/OACreation&gt;
 108:
 109: &lt;/Rule&gt;
 110:
 111: &lt;/Rules&gt;
 112:&lt;/Policy&gt;
</screen>

      <para>Note that the JVM that reads the deployment descriptor should be
      started with security policy. In order to start a secure JVM, you need
      to use the property proactive.runtime.security and give a path a
      security file descriptor.</para>

      <para>Here an example: java -Dproactive.runtime.security=jvmlocal.xml
      TestSecureDeployment secureDeployment.xml</para>
    </sect2>
  </sect1>

  <sect1 >
    <title>How to quickly generate
    certificate?</title>

    <para>A GUI has been created to facilitate certificate generation.</para>

    <para>The first screenshot presents a root certificate. Notice that the
    certificate chain table is empty.</para>

    <para><figure>
        <title>The ProActive Certificate Generator (for oasis)</title>

        <mediaobject>
          <imageobject>
             <imagedata fileref="security_images/gui-oasis.png" format="PNG"  contentwidth="100" width="6in"/>
          </imageobject>
        </mediaobject>
      </figure></para>

    <para>The second screenshot presents a certificate generated from the
    previous one using menu entry 'Certificate -&gt; generate a
    sub-certificate'.</para>

    <para>Notice that the certification table contains one entry and
    Distinguished Name of the Entity ID 1 is the same as the subject DN of the
    certificate</para><commit_msg>updated the Security.xml doc source after moving the security descriptors<commit_after><?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="viewDocbook.css"?>
<chapter id="Security">
  <title>ProActive Security Mechanism</title>

  <para>In order to use the Proactive Security features, you have to
  install<emphasis role="bold">the Java(TM) Cryptography Extension (JCE)
  Unlimited Strength Jurisdiction Policy Files</emphasis> available at 
  <ulink url="http://www.java.sun.com">Sun's website</ulink>. Extract the file 
   and copy jar files to your &lt;jre_home&gt;/lib/security.</para>

  <sect1 >
    <title>Overview</title>

    <para>Usually, applications and security are developed for a specific use.
    We propose here a security framework that allows to dynamically deploy
    applications and to configure security according to this
    deployment.</para>

    <para>ProActive security mechanism provides a set of security features
    from basic ones like communications authentication, integrity,
    confidentiality to more high-level features including migration security
    mechanism, hierarchical security policies, dynamically negotiated
    policies. All theses features are expressed inside the meta-level of the
    middleware and used transparently by applications.</para>

    <para>It is possible to attach security policies to Runtimes, Virtual
    Nodes, Nodes and Active Objects. Policies are expressed inside an XML
    descriptor.</para>
  </sect1>

  <sect1 >
    <title>Security Architecture</title>

    <sect2 >
      <title>Base model</title>

      <para>A distributed or concurrent application built using
      <emphasis>ProActive</emphasis> is composed of a number of medium-grained
      entities called <emphasis>active objects</emphasis>. Each active object
      has one distinguished element, the <emphasis>root</emphasis>, which is
      the only entry point to the active object; all other objects inside the
      active object are called <emphasis>passive objects</emphasis> and cannot
      be referenced directly from objects which are outside this active object
      (see following figure); the absence of sharing is important with respect
      to security.</para>

      <para><figure>
          <title>A typical object graph with active objects</title>

          <mediaobject>
            <imageobject>
              <imagedata fileref="security_images/activeObjects.png"
                         format="PNG"  contentwidth="100" width="6in"/>
            </imageobject>
          </mediaobject>
        </figure></para>

      <para>The security is based on Public Key Infrastructure. Each entity
      owns a certificate and an private key generated from the certificate of
      a user.</para>

      <para>Certificates are generated automatically by the security
      mechanism. The validity of a certificate is checked by validating its
      certificate chain. As shown in the next figure, before validating the
      certificate of an active object, application certificate and user
      certificate will be checked. If a valid path is found so object
      certificate is validated.</para>

      <para><figure>
          <title>Certificate chain</title>

          <mediaobject>
            <imageobject>
              <imagedata fileref="security_images/certificateGeneration.png"
                         format="PNG" />
            </imageobject>
          </mediaobject>
        </figure></para>
    </sect2>

    <sect2 >
     <title>Security is expressed at different levels</title>
     
     <para>Security is expressed at different levels, according to who wants
      to set policy:</para>

      <itemizedlist>
        <listitem>
          <para>Administrators set policy at domain level. It contains general
          security rules.</para>
        </listitem>

        <listitem>
          <para>Resource provider set policy for resource. People who have
          access to a cluster and wants to offer cpu time under some
          restrictions. The runtime loads its policy file at launch
          time.</para>
        </listitem>

        <listitem>
          <para>Application level policy is set when an application is
          deployed through an XML descriptor.</para>
        </listitem>
      </itemizedlist>

      <para><figure>
          <title>Hierarchical security</title>

          <mediaobject>
            <imageobject>
              <imagedata fileref="security_images/security-hierarchy.png"
                         format="PNG" />
            </imageobject>
          </mediaobject>
        </figure></para>

      <para>When an interaction is happening, all participating entities'
      security policy are verified and combined to find the policy to enforce
      to the interaction.</para>
    </sect2>
  </sect1>

  <sect1 >
    <title>Detailed Security
    Architecture</title>

    <sect2 >
      <title>Virtual Nodes and Nodes</title>

      <para>The security architecture relies on two related abstractions for
      deploying Grid applications: <emphasis>Node</emphasis> and
      <emphasis>Virtual Node</emphasis>. A node gathers several objects in a
      logical entity. It provides an abstraction for the physical location of
      a set of activities. Objects are bound to a node at creation or after
      migration. In order to have a flexible deployment (eliminating from the
      source code machine names, creation protocols), the system relies on
      <emphasis>Virtual Nodes</emphasis> (VNs). A VN is identified as a name
      (a simple string), used in a program source, defined and configured in
      an descriptor. The user can attach policy to these virtual nodes.
      Virtual Nodes are used within application code to structure it. By
      example, an object which will be used as a server will be set inside a
      virtual node named Server_VN, client objects will be set inside
      Client_VN. The user expresses policy between server and client object
      inside a descriptor file. The correspondence between Virtual Nodes and
      Nodes, the mapping, is done at application starting time.</para>
    </sect2>

    <sect2  id="Security_html_SECTION00033000000000000000">
      <title>Hierarchical Security Entities</title>

      <para>Grid programming is about deploying processes (activities) on
      various machines. In the end, the security policy that must be ensured
      for those processes depends upon many factors: first of all, the
      application policy that is needed, but also the machine locations, the
      security policies of their administrative domain, and the network being
      used to reach those machines.</para>

      <para>Previous section defined the notions of <emphasis>Virtual
      Nodes</emphasis>, and <emphasis>Nodes</emphasis>. Virtual Nodes are
      application abstractions, and nodes are only a run-time entity resulting
      from the deployment: a mapping of Virtual Nodes to processes and hosts.
      A first decisive feature allows to define application-level security on
      those application-level abstractions:</para>

      <para><informalfigure>
          <mediaobject>
            <imageobject>
             <imagedata fileref="security_images/img3.png" format="PNG" contentwidth="100" width="6in"/>
            </imageobject>
          </mediaobject>
        </informalfigure></para>

      <para>As such, virtual nodes are the support for intrinsic application
      level security. If, at design time, it appears that a process always
      requires a specific level of security (e.g. authenticated and encrypted
      communications at all time), then that process should be attached to a
      virtual node on which those security features are imposed. It is the
      designer responsibility to structure his/her application or components
      into virtual node abstractions compatible with the required security.
      Whatever deployment occurs, those security features will be maintained.
      We expect this usage to be rather occasional, for instance in very
      sensitive applications where even an intranet deployment calls for
      encrypted communications.</para>

      <para>The second decisive feature deals with a major Grid aspect:
      deployment-specific security. The issue is actually twofold:</para>

      <orderedlist>
        <listitem>
          <para>allowing organizations (security domains) to specify general
          security policies,</para>
        </listitem>

        <listitem>
          <para>allowing application security to be specifically adapted to a
          given deployment environment.</para>
        </listitem>
      </orderedlist>

      <para>Domains are a standard way to structure (virtual) organizations
      involved in a Grid infrastructure; they are organized in a hierarchical
      manner. They are the logical concept allowing to express security
      policies in a hierarchical way.</para>

      <para><informalfigure>
          <mediaobject>
            <imageobject>
             <imagedata fileref="security_images/img4.png" format="PNG" contentwidth="100" width="6in"/>
            </imageobject>
          </mediaobject>
        </informalfigure></para>

      <para>This principle allows to deal with the two issues mentioned
      above:</para>

      <para>(1) the administrator of a domain can define specific policy rules
      that must be obeyed by the applications running within the domain.
      However, a general rule expressed inside a domain may prevent the
      deployment of a specific application. To solve this issue, a policy rule
      can allow a well-defined entity to weaken it. As we are in a
      hierarchical organization, allowing an entity to weaken a rule means
      allowing all entities included to weaken the rule. The entity can be
      identified by its certificate;</para>

      <para>(2) a Grid user can, at the time he runs an application, specify
      additional security based on the domains being deployed onto.</para>

      <para>The Grid user can specify additional rules directly in his
      deployment descriptor for the domains he deploys onto. Note that those
      domains are actually dynamic as they can be obtained through external
      allocators, or even Web Services in an OGSA infrastructure 
      (see <citation><xref linkend="foster98security" endterm="foster98security.abbrev"/></citation>).
      Joker rules might be important in that case to cover all cases, and to provide
      a conservative security strategy for un-forecasted deployments.</para>

      <para>Finally, as active objects are active and mobile entities, there
      is a need to specify security at the level of such entities.</para>

      <para><informalfigure>
          <mediaobject>
            <imageobject>
             <imagedata fileref="security_images/img6.png" format="PNG" contentwidth="100" width="6in"/>
            </imageobject>
          </mediaobject>
        </informalfigure></para>

      <para>In open applications, e.g. several principals interacting in a
      collaborative Grid application, a JVM (a process) launched by a given
      principal can actually host an activity executing under another
      principal. The principle above allows to keep specific security
      privileges in such case. Moreover, it can also serve as a basis to
      offer, in a secure manner, hosting environments for mobile
      agents.</para>

      <para><figure>
          <title>Syntax and attributes for policy rules</title>

          <mediaobject>
            <imageobject>
              <imagedata fileref="security_images/img8.png" format="PNG" />
            </imageobject>
          </mediaobject>
        </figure></para>
    </sect2>

    <sect2  id="Security_html_SECTION00034000000000000000">
      <title>Resource provider security features</title>

      <para>Prior to start application on a Grid, a user needs to acquire some
      resources (CPU time, disk storage, bandwidth) from the Grid. A
      <emphasis>Resource provider</emphasis> is an individual, a research
      institute, an organization who wants to offer some resources under a
      certain security policy to a restricted set of peoples. According to our
      definition, resource provider will set up one or more runtime where
      clients will be able do perform computation. Each runtime is set with
      its own policy. Theses runtimes could be worldwide distributed.</para>
    </sect2>

    <sect2  id="Security_html_SECTION00037000000000000000">
      <title>Interactions, Security Attributes</title>

      <para>Security policies are able to control all the
      <emphasis>interactions</emphasis> that can occur when deploying and
      executing a multi-principals Grid application. With this goal in mind,
      interactions span over the creation of processes, to the monitoring of
      activities (Objects) within processes, including of course the
      communications. Here is a brief description of those
      interactions:</para>

     <indexterm><primary>Migration</primary><secondary>security</secondary></indexterm>
 
     
     <itemizedlist>
        <listitem>
          <para>RuntimeCreation (RC): creation of a new Runtime process</para>
        </listitem>

        <listitem>
          <para>NodeCreation (NC): creation of a new Node within a Runtime (as
          the result of Virtual Node mapping)</para>
        </listitem>

        <listitem>
          <para>CodeLoading (CL): loading of bytecode within a Node, used in
          presence of object migration.</para>
        </listitem>

        <listitem>
          <para>ObjectCreation (OC): creation of a new activity (active
          object) within a Node</para>
        </listitem>

        <listitem>
          <para>ObjectMigration (OM): migration of an existing activity object
          to a Node</para>
        </listitem>

        <listitem>
          <para>Request (Q), Reply (P): communications, method calls and
          replies to method calls</para>
        </listitem>

        <listitem>
          <para>Listing (L): list the content of an entity; for Domain/Node
          provides the list of Node/Objects, for an Object allows to monitor
          its activity.</para>
        </listitem>
      </itemizedlist>

      <para>For instance, a domain is able to specify that it accepts
      downloading of code from a given set of domains, provided the transfers
      are authenticated and guaranteed not to be tampered with. As a policy
      might leave open the integrity of communications, and also because not
      allowing confidentiality can be a domain (or even a country) policy,
      those 3 security attributes can be specified in 3 modes: Required
      (<emphasis role="bold">+</emphasis>), Optional (<emphasis
      role="bold">?</emphasis>), Disallowed (<emphasis
      role="bold">-</emphasis>)</para>

      <para>For a given interaction, a tuple [+A,?I,-C] means that
      authentication is required, integrity is accepted but not required, and
      confidentiality is not allowed.</para>

      <para>As a Grid operates in decentralized mode, without a central
      administrator controlling the correctness of all security policies,
      these policies must be <emphasis>combined</emphasis>,
      <emphasis>checked</emphasis>, and <emphasis>negotiated</emphasis>
      dynamically. The next two sections present that aspect.</para>
    </sect2>

    <sect2  id="Security_html_SECTION00038000000000000000">
      <title>Combining Policies</title>

      <para>As the proposed infrastructure takes into account different actors
      of the Grid (domain administrator, Grid user), even for a
      single-principal single-domain application, there are potentially
      several security policies activated. This section deals with the
      combination of those policies to obtain the final security tuples of a
      single entity. An important principle being that a sub-domain cannot
      weaken a super-domain's rule.</para>

      <para>During execution, each activity (Active Object) is always included
      in a <emphasis>Node</emphasis> (due to the Virtual Node mapping) and at
      least in one <emphasis>Domain</emphasis>, the one used to launch a JVM 
      (D<subscript>0</subscript>).   <xref linkend="HierarchicalSecurityLevels"/>
      hierarchically represents the security rules that can be activated at
      execution: from the top, hierarchical domains 
      (D<subscript>1</subscript> to D<subscript>0</subscript>), the virtual node policy (VN), and the Object
      (O) policy. Of course, such policies can be inconsistent, and there must
      be clear principles to combine the various sets of rules.</para>

     <para><figure id="HierarchicalSecurityLevels">
          <title>Hierarchical Security Levels</title>

          <mediaobject>
            <imageobject>
              <imagedata fileref="security_images/img11.png" format="PNG" />
            </imageobject>
          </mediaobject>
        </figure></para>

      <para>There are three main principles: (1) choosing the <emphasis>most
      specific rules</emphasis> within a given domain (as a single Grid actor
      is responsible for it), (2) an interaction is valid only if all levels
      accept it (absence of weakening of authorizations), (3) the security
      attributes retained are the most constrained based on a partial order
      (absence of weakening of security).</para>

      <screen>          Domain[*] -&gt; Domain[*]: Q,P: [+A,+I,+C] 
          Domain[CardPlus] -&gt; Domain[CardPlus]: Q,P: [+A,?I,?C] </screen>

      <para>within the CardPlus domain, the second rule will be chosen
      (integrity and confidentiality will be optional). Of course, comparison
      of rules is only a partial order, and several incompatible most specific
      rules can exist within a single level (e.g. both ACCEPT and DENY most
      specific rules for the same interaction, or both +A and -A).</para>

      <para>Between levels, an incompatibility can also occur, especially if a
      sub-level attempts to weaken the policy on a given interaction (e.g. a
      domain prohibits confidentiality [-C] while a sub-domain or the Virtual
      Node requires it [+C], a domain D<subscript>i</subscript> prohibits
      loading of code while D<subscript>j</subscript> (j &lt;= i) authorizes
      it). In all incompatible cases, the interaction is not authorized and an
      error is reported.</para>
    </sect2>

    <sect2 >
      <title>Dynamic Policy Negotiation</title>

      <para>During execution, entities interact by pair with each other. Each
      entity, for each interaction (JVM creation, communication, migration,
      ...), will want to apply a security policy based on the resolution
      presented in the previous section. Before starting an interaction, a
      <emphasis>negotiation</emphasis> occurs between the two entities
      involved. <xref linkend="Result_of_security_negotiations"/>
      shows the result of such negotiation. For example, if for a given
      interaction, entity A's policy is [+A,?I,?C], and B's policy is
      [+A,?I,-C], the negotiated policy will be [A,?I,-C]. If, for a result
      rule, one of the communication attributes is optional, the attribute is
      not activated.</para>

      <para>Besides the interactions not being accepted by an entity, two
      other cases lead to an error: when an attribute is required by one, and
      disallowed by the other. In such cases, the interaction is not
      authorized and an error is reported. If a valid security policy is found
      between two entities, the interaction can occur. In the case that the
      agreed security policy includes confidentiality, the two entities
      negotiate a session key.</para>

     <table id="Result_of_security_negotiations" frame="none">
          <title>Result of security negotiations</title>
          <tgroup cols="1">
            <tbody>
              <row>
                <entry align="center"> 
                 <para><informalfigure id="SecurityNegotiation">
                  <mediaobject>
                   <imageobject>
                    <imagedata fileref="security_images/negotiation.png" format="PNG" />
                   </imageobject>
                  </mediaobject>
                 </informalfigure></para>
                </entry>
              </row>
            </tbody>
          </tgroup>
        </table>
    </sect2>

    <sect2>

     <title>Migration and Negotiation</title>

		 <indexterm><primary>Migration</primary><secondary>security</secondary></indexterm>
      
		 <para>In large scale Grid applications, migration of activities is an
      important issue. The migration of Active Objects must not weaken the
      security policy being applied.</para>

      <para>When an active object migrates to a new location, three cases may
      happen:</para>

      <itemizedlist>
        <listitem>
          <para>the object migrates to a node belonging to the same virtual
          node and included inside the same domain. In this case, all already
          negotiated sessions remain valid.</para>
        </listitem>

        <listitem>
          <para>the object migrates to a known node (created during the
          deployment step) but which belongs to another virtual node. In this
          case, all already negotiated sessions can be invalid. This kind of
          migration imposes re-establishing the object policy, and upon a
          change, re-negotiating with interacting entities.</para>
        </listitem>

        <listitem>
          <para>The object migrates to an unknown node (not known at the
          deployment step). In this case, the object migrates with a copy of
          the application security policy. When a secured interaction will
          take place, the security system retrieves not only the object's
          application policy but also policies rules attached to the node on
          which the object is to compute the policy.</para>
        </listitem>
      </itemizedlist>
    </sect2>
  </sect1>

  <sect1 >
    <title>Activating security
    mechanism</title>

    <para>Within descriptor, the tag &lt;security&gt; is used to specify the
    policy for the deployed application. It will be the policy for all Nodes
    and active that will be created.</para>

    <para>the descriptor is:</para>

    <screen> 1:&lt;?xml version='1.0' encoding='UTF-8'?&gt;
 2:&lt;ProActiveDescriptor xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'  xsi:noNamespaceSchemaLocation='DescriptorSchema.xsd'&gt;
 3: &lt;security file='../../descriptors/security/applicationPolicy.xml'&gt;&lt;/security&gt;
 4: &lt;componentDefinition&gt;
 5: &lt;virtualNodesDefinition&gt;
 6: &lt;virtualNode name='Locale' property='unique'/&gt;
 7: &lt;virtualNode name='vm1' property='unique'/&gt;
 8: &lt;virtualNode name='vm2' property='unique'/&gt;
 9: &lt;/virtualNodesDefinition&gt;
 10: &lt;/componentDefinition&gt;
 11: ....
 50:&lt;infrastructure&gt;
 51: &lt;processes&gt; 
 52: &lt;processDefinition id='linuxJVM'&gt;
 53: &lt;jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'&gt;
 54: &lt;classpath&gt;
 ....
 74: &lt;/classpath&gt;
 75: &lt;jvmParameters&gt;
 &lt;parameter value='-Dproactive.runtime.security=/.../descriptors/security/jvm1-sec.xml'/&gt;
 82: &lt;/jvmParameters&gt;
 83: &lt;/jvmProcess&gt;
 84: &lt;/processDefinition&gt;
 ....</screen>

    <para>Inside the policy file, you can express policy between entities
    (domain, runtime, node, active object).</para>

    <para>The entity tag can be used to:</para>

    <itemizedlist>
      <listitem>
        <para>express policies on entities described inside the descriptor
        (lines 13, 15)</para>
      </listitem>

      <listitem>
        <para>express policies on existing entities by specifying theirs
        certificates (line 32).</para>
      </listitem>
    </itemizedlist>

    <sect2 >
      <title>Construction of an XML policy:</title>

      <para>A policy file must begin with:</para>

      <screen> 1:&lt;?xml version='1.0' encoding='UTF-8'?&gt;
 2:&lt;Policy&gt;</screen>

      <para>next, application specific informations are given.</para>

      <screen> 3: &lt;ApplicationName&gt;Garden&lt;/ApplicationName&gt; </screen>

      <para>&lt;ApplicationName&gt; sets the application name. This allows to
      identify easily which application an entity belongs to.</para>

      <screen> 4: &lt;Certificate&gt;/.../appli.cert&lt;/Certificate&gt;
 5: &lt;PrivateKey&gt;/.../appli.key&lt;/PrivateKey&gt;</screen>

      <para>&lt;Certificate&gt; is the X509 certificate of the application,
      generated from a user certificate, and</para>

      <para>&lt;PrivateKey&gt; the private key associated to the
      certificate.</para>

      <screen> 6: &lt;CertificationAuthority&gt;
 7: &lt;Certificate&gt;/.../ca.cert&lt;/Certificate&gt;
 8: &lt;/CertificationAuthority&gt;</screen>

      <para>&lt;CertificationAuthority&gt; contains all trusted certificate
      authority. Each &lt;Certificate&gt; contains a certification authority
      certificate.</para>

      <screen> 10: &lt;Rules&gt; </screen>

      <para>Then we can define policy rules. All rules are located within the
      &lt;Rules&gt;</para>

      <para>A &lt;Rule&gt; is constructed according the following syntax:</para>

      <screen> 11: &lt;Rule&gt; </screen>

      <para>&lt;From&gt; tag contains all entities from which the interaction
      is made. It is possible to specify many entities in order to match a
      specific fine-grained policy.</para>

      <screen> 12: &lt;From&gt;
 13: &lt;Entity type='VN' name='vm2'/&gt;
 14: &lt;/From&gt;</screen>

      <para>&lt;Entity&gt; is used to define an entity. the 'type' parameter
      can be 'VN', 'certificate'.</para>

      <itemizedlist>
        <listitem>
          <para>'VN' (Virtual Node) referrers to virtual nodes defined inside
          the deployment descriptor.</para>
        </listitem>

        <listitem>
          <para>'DefaultVirtualNode' is a special tag. It allows to specify a
          default policy.</para>
        </listitem>

        <listitem>
          <para>'certificate' supposes that a path to a file is set inside the
          'name' parameters.</para>
        </listitem>
      </itemizedlist>

      <para>&lt;To&gt; tag contains all entities onto the interaction is made.
      As &lt;From&gt; tag, many entities can be specified.</para>

      <screen> 15: &lt;To&gt;
 16: &lt;Entity type='VN' name='Locale'/&gt;
 17: &lt;/To&gt;</screen>

      <para>The &lt;Communication&gt; tag defines security policies to apply
      to requests and replies.</para>

      <screen> 18: &lt;Communication&gt; </screen>

      <para>&lt;Request&gt; sets the policy associated a request. the 'value'
      parameter can be:</para>

      <itemizedlist>
        <listitem>
          <para>'authorized' means a request is authorized.</para>
        </listitem>

        <listitem>
          <para>'denied' means a request is denied.</para>
        </listitem>
      </itemizedlist>

      <para>Each &lt;Attribute&gt; (authentication,integrity, confidentiality)
      can be required, optional or denied.</para>

      <screen>  19: &lt;Request value='authorized'&gt;
  20:   &lt;Attributes authentication='required' integrity='optional' confidentiality='optional'/&gt; 
  21: &lt;/Request&gt;</screen>

      <para>&lt;Reply&gt; tag has the same parameters that
      &lt;Request&gt;</para>

      <screen> 22:&lt;Reply value='authorized'&gt;
 23: &lt;Attributes authentication='required' integrity='required' confidentiality='required'/&gt;
 24:&lt;/Reply&gt;
 25:&lt;/Communication&gt;</screen>

      <para>&lt;Migration&gt; allows or not migration from &lt;from&gt;
      entities to &lt;To&gt; entities. Values can be 'denied' or
      'authorized'.</para>

      <screen> 26: &lt;Migration&gt;denied&lt;/Migration&gt; </screen>

      <para>&lt;OACreation&gt; allows or not creation of active objects by
      &lt;From&gt; entities onto &lt;To&gt; entities.</para>

      <para>Values can be 'denied' or 'authorized'.</para>

      <screen> 27: &lt;OACreation&gt;denied&lt;/OACreation&gt; </screen>

      <screen> 1:&lt;?xml version='1.0' encoding='UTF-8'?&gt;
 2:&lt;Policy&gt;
 3: &lt;ApplicationName&gt;Garden&lt;/ApplicationName&gt;
 4: &lt;Certificate&gt;/net/home/acontes/certif/appli.cert&lt;/Certificate&gt;
 5: &lt;PrivateKey&gt;/net/home/acontes/certif/appli.key&lt;/PrivateKey&gt;
 6: &lt;CertificationAuthority&gt;
 7: &lt;Certificate&gt;&lt;/Certificate&gt;
 8: &lt;/CertificationAuthority&gt;
 9:
 10: &lt;Rules&gt;
 11: &lt;Rule&gt;
 12: &lt;From&gt;
 13: &lt;Entity type='VN' name='vm2'/&gt;
 14: &lt;/From&gt;
 15: &lt;To&gt;
 16: &lt;Entity type='VN' name='Locale'/&gt;
 17: &lt;/To&gt;
 18: &lt;Communication&gt;
 19: &lt;Request value='authorized'&gt;
 20: &lt;Attributes authentication='required' integrity='required' confidentiality='required'/&gt;
 21: &lt;/Request&gt;
 22: &lt;Reply value='authorized'&gt;
 23: &lt;Attributes authentication='required' integrity='required' confidentiality='required'/&gt;
 24: &lt;/Reply&gt;
 25: &lt;/Communication&gt;
 26: &lt;Migration&gt;denied&lt;/Migration&gt;
 27: &lt;OACreation&gt;denied&lt;/OACreation&gt;
 28:
 29: &lt;/Rule&gt;
 30: &lt;Rule&gt;
 31: &lt;From&gt;
 32: &lt;Entity type='certificate' name='certificateRuntime1.cert'/&gt;
 33: &lt;/From&gt;
 34: &lt;To&gt;
 35: &lt;Entity type='VN' name='Locale'/&gt;
 36: &lt;/To&gt;
 37: &lt;Communication&gt;
 38: &lt;Request value='authorized'&gt;
 39: &lt;Attributes authentication='required' integrity='required' confidentiality='required'/&gt;
 40: &lt;/Request&gt;
 41: &lt;Reply value='authorized'&gt;
 42: &lt;Attributes authentication='required' integrity='required' confidentiality='required'/&gt;
 43: &lt;/Reply&gt;
 44: &lt;/Communication&gt;
 45: &lt;Migration&gt;denied&lt;/Migration&gt;
 46: &lt;OACreation&gt;denied&lt;/OACreation&gt;
 47:
 48: &lt;/Rule&gt;
 ...
 90: &lt;Rule&gt;
 91: &lt;From&gt;
 92: &lt;Entity type='DefaultVirtualNode' name='*'/&gt;
 93: &lt;/From&gt;
 94: &lt;To&gt;
 95: &lt;Entity type='DefaultVirtualNode' name='*'/&gt;
 96: &lt;/To&gt;
 97: &lt;Communication&gt;
 98: &lt;Request value='denied'&gt;
 99: &lt;Attributes authentication='optional' integrity='optional' confidentiality='optional'/&gt;
 100: &lt;/Request&gt;
 101: &lt;Reply value='denied'&gt;
 102: &lt;Attributes authentication='optional' integrity='optional' confidentiality='optional'/&gt;
 103:
 104: &lt;/Reply&gt;
 105: &lt;/Communication&gt;
 106: &lt;Migration&gt;denied&lt;/Migration&gt;
 107: &lt;OACreation&gt;authorized&lt;/OACreation&gt;
 108:
 109: &lt;/Rule&gt;
 110:
 111: &lt;/Rules&gt;
 112:&lt;/Policy&gt;
</screen>

      <para>Note that the JVM that reads the deployment descriptor should be
      started with security policy. In order to start a secure JVM, you need
      to use the property proactive.runtime.security and give a path a
      security file descriptor.</para>

      <para>Here an example: java -Dproactive.runtime.security=descriptors/security/jvmlocal.xml
      TestSecureDeployment secureDeployment.xml</para>
    </sect2>
  </sect1>

  <sect1 >
    <title>How to quickly generate
    certificate?</title>

    <para>A GUI has been created to facilitate certificate generation.</para>

    <para>The first screenshot presents a root certificate. Notice that the
    certificate chain table is empty.</para>

    <para><figure>
        <title>The ProActive Certificate Generator (for oasis)</title>

        <mediaobject>
          <imageobject>
             <imagedata fileref="security_images/gui-oasis.png" format="PNG"  contentwidth="100" width="6in"/>
          </imageobject>
        </mediaobject>
      </figure></para>

    <para>The second screenshot presents a certificate generated from the
    previous one using menu entry 'Certificate -&gt; generate a
    sub-certificate'.</para>

    <para>Notice that the certification table contains one entry and
    Distinguished Name of the Entity ID 1 is the same as the subject DN of the
    certificate</para>
{'fraction_non_alphanumeric': 0.09803496492667896, 'fraction_numerical': 0.012573746883661871, 'mean_word_length': 3.090707544181922, 'pattern_counts': {'":': 0, '<': 1025, '<?xml version=': 8, '>': 1025, 'https://': 0, 'lorem ipsum': 0, 'www.': 4, 'xml': 21}, 'pii_count': 0, 'substrings_counts': 8, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2930168', 'n_tokens_mistral': 18315, 'n_tokens_neox': 17028, 'n_words': 6418}