| Prev | Part VII. Services and Advanced Features Chapter 33. Security Framework |
 |
Next |
In order to use the Proactive Security features, you have to install the Java(TM) Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files available at Sun's website. Extract the file and copy jar files to your <jre_home>/lib/security.
Usually, applications and security are developed for a specific use. We propose here a security framework that allows dynamic deployment of applications and security configuration according to this deployment.
ProActive security mechanism provides a set of security features from basic ones like communications authentication, integrity, and confidentiality to more high-level features including secure object migration, hierarchical security policies, and dynamically negotiated policies. All these features are expressed at the ProActive middleware level and used transparently by applications.
It is possible to attach security policies to Runtimes, Virtual Nodes, Nodes and Active Objects. Policies are expressed inside an XML descriptor.
A distributed or concurrent application built using ProActive is composed of a number of medium-grained entities called active objects. Each active object has one distinguished element, the root, which is the only entry point to the active object; all other objects inside the active object are called passive objects 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.
The security is based on Public Key Infrastructure. Each entity owns a certificate and an private key generated from the certificate of a user.
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, the application certificate and user certificate will be checked. If a valid path is found then the object certificate is validated.
Security is expressed at different levels, according to who wants to set policy:
Administrators set policy at domain level. It contains general security rules.
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.
Application level policy is set when an application is deployed through an XML descriptor.
The ProActive middleware will enforce the security policy of all entites interacting within the system, ensuring that all policies are adhered to.
The security architecture relies on two related abstractions for deploying Grid applications: Node and Virtual Node. 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 Virtual Nodes (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 mapping between Virtual Nodes and Nodes is done when the application starts.
Grid programming is about deploying processes (activities) on various machines. The final security policy that must be set for those processes depends upon many factors: primarily, this is dictated by the application's policy, but the machine locations, the security policies of their administrative domain, and the network being used to reach those machines must also be considered.
The previous section defined the notions of Virtual Nodes, and Nodes. 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 the definition of application-level security on those abstractions:
As such, virtual nodes are the foundation 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 case to occur infrequently, for instance in very sensitive applications where even an intranet deployment calls for encrypted communications.
The second decisive feature deals with a major Grid aspect: deployment-specific security. The issue is actually twofold:
allowing organizations (security domains) to specify general security policies,
allowing application security to be specifically adapted to a given deployment environment.
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 which allow the expression of security policies in a hierarchical way.
This principle deals with the two issues mentioned above:
(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;
(2) a Grid user can, at the time he runs an application, specify additional security based on the domains being deployed onto.
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 [FKTT98]). Catch-all rules might be important in that case to cover all cases, and to provide a conservative security strategy for unforseen deployments.
Finally, as active objects are active and mobile entities, there is a need to specify security at the level of such entities.
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 above principle specific security privileges to be retained in such a case. Moreover, it can also serve as a basis to offer, in a secure manner, hosting environments for mobile agents.
Prior to an application starting on a grid, a user needs to acquire some resources (CPU time, disk storage, bandwidth) from the grid. A resource provider 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, the resource provider will set up one or more runtimes where clients will be able to perform computation. Each runtime is set with its own policy. Theses runtimes could be globally distributed.
Security policies are able to control all the interactions that can occur when deploying and executing a multi-principals Grid application. With this goal in mind, interactions span 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:
RuntimeCreation (RC): creation of a new Runtime process
NodeCreation (NC): creation of a new Node within a Runtime (as the result of Virtual Node mapping)
CodeLoading (CL): loading of bytecode within a Node, used in presence of object migration.
ObjectCreation (OC): creation of a new activity (active object) within a Node
ObjectMigration (OM): migration of an existing activity object to a Node
Request (Q), Reply (P): communications, method calls and replies to method calls
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.
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 allow un-authenticated communications, or because a domain (or even country) policy may specify that all communications are un-encrypted, the three security attributes Authentication (A), Integrity (I) and Confidentiality (C) can be specified in three modes: Required (+), Optional (?), Disallowed (-)
For example, the tuple [+A,?I,-C] means that authentication is required, integrity is accepted but not required, and confidentiality is not allowed.
As grids are decentralized, without a central administrator controlling the correctness of all security policies, these policies must be combined, checked, and negotiated dynamically. The next two sections discuss how this is done.
As the proposed infrastructure takes into account different actors of the grid (e.g. domain administrator, grid user), even for a single-principal single-domain application, there are potentially several security policies in effect. 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 the rules of its super-domains.
During execution, each activity (Active Object) is always included in a Node (due to the Virtual Node mapping) and at least in one Domain, the one used to launch a JVM (D0). Figure 33.5, “Hierarchical Security Levels” hierarchically represents the security rules that can be activated at execution: from the top, hierarchical domains (D1 to D0), the virtual node policy (VN), and the Active Object (AO) policy. Of course, such policies can be inconsistent, and there must be clear principles to combine the various sets of rules.
There are three main principles: (1) choosing the most specific rules 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). Consider the following example, where the catch-all rule specifies that all Requests (Q) and Replies (P) must be authenticated, integrity checked, and confidential, however within the specific "CardPlus" domain integrity and confidentiality will be optional.
Domain[*] -> Domain[*]: Q,P: [+A,+I,+C]
Domain[CardPlus] -> Domain[CardPlus]: Q,P: [+A,?I,?C] This means that any activity taking place within the CardPlus domain the second rule will be chosen (integrity and confidentiality will be optional), as the catch-all rule is less-specific than the "CardPlus" domain rule, and there is no hierarchical domain relationship between the two rules. 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).
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 Di prohibits loading of code while Dj (j <= i) authorizes it). In all incompatible cases, the interaction is not authorized and an error is reported.
During execution, entities interact in a pairwise fashion. 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 negotiation occurs between the two entities involved. ??? 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 both policies specify an attribute as optional, the attribute is not activated.
The other case which leads to an error is 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 the two entities security policies agree, then the interaction can occur. In the case that the agreed security policy includes confidentiality, the two entities negotiate a session key.
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.
When an active object migrates to a new location, three scenarios are possible:
the object migrates to a node belonging to the same virtual node and included in the same domain. In this case, all negotiated sessions remain valid.
the object migrates to a known node (created during the deployment step) but which belongs to another virtual node. In this case, all current negotiated sessions become invalid. This kind of migration requires reestablishing the object security policy, and if it changes, renegotiating with interacting entities.
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 takes 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.
A GUI has been created to facilitate certificate generation. It is a RCP plugin shipped with the IC2D tool.
The first screenshot presents a root certificate. Notice that the certificate chain table is empty.
The second screenshot presents a certificate generated from the previous one using menu entry 'Certificate -> generate a sub-certificate'.
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
Using this GUI, a user is able to generate a certificate and if needed a certificate chain.
Certificates are saved under a PKCS12 format (extension .p12). This format is natively supported by the ProActive Security mechanism.
Within the deployment descriptor, the tag <security> is used to specify the policy for the deployed application. It will be the policy by all the Nodes and the Active Objects that will be created. Below is a fragment of a sample deployment descriptor:
2:<ProActiveDescriptor xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation='DescriptorSchema.xsd'>
3: <security>
<file uri='../../descriptors/security/applicationPolicy.xml'/>
</security>
4: <componentDefinition>
5: <virtualNodesDefinition>
6: <virtualNode name='Locale' property='unique'/>
7: <virtualNode name='vm1' property='unique'/>
8: <virtualNode name='vm2' property='unique'/>
9: </virtualNodesDefinition>
10:</componentDefinition>
11: ....
50:<infrastructure>
51: <processes>
52: <processDefinition id='linuxJVM'>
53: <jvmProcess
class='org.objectweb.proactive.core.process.JVMNodeProcess'>
54: <classpath>
....
74: </classpath>
75: <jvmParameters>
<parameter value='-Dproactive.runtime.security=/.../descriptors/security/jvm1-sec.xml'/>
82: </jvmParameters>
83: </jvmProcess>
84: </processDefinition>
....Inside the policy file, you can express policy between entities (domain, runtime, node, active object).
The entity tag can be used to:
express policies on entities described inside the descriptor (lines 13, 15)
express policies on existing entities by specifying theirs certificates (line 32).
A policy file must begin with:
2:<Policy>
next, application specific information is given.
3: <ApplicationName>Garden</ApplicationName>
<ApplicationName> sets the application name. This allows easy identification of which application an entity belongs to.
4: <PKCS12KeyStore>/.../appli.cert</PKCS12KeyStore>
<PKCS12KeyStore> describes the path to the keystore created using the graphical interface. The path could be either absolute or relative. An absolute path contains the whole path (starting with / under Unix systems or a letter under Windows systems). A relative path describes the path to follow from the policy file in order to find the keystore file. For instance, setting just the name of the keystore file indicates that the file is located under the same directory the policy file is.
6: <CertificationAuthority> 7: <Certificate>/.../ca.cert</Certificate> 8: </CertificationAuthority>
<CertificationAuthority> contains all trusted certificate authority certificates.
10: <Rules>
Then we can define policy rules. All rules are located within the <Rules>
A <Rule> is constructed according the following syntax:
11: <Rule>
<From> tag contains all entities from which the interaction is made (source). It is possible to specify many entities in order to match a specific fine-grained policy.
12: <From> 13: <Entity type='VN' name='vm2'/> 14: </From>
<Entity> is used to define an entity. the 'type' parameter can be 'VN', 'certificate', or 'DefaultVirtualNode'.
'VN' (Virtual Node) referrers to virtual nodes defined inside the deployment descriptor.
'DefaultVirtualNode' is a special tag. This is taken as the default policy. The "name" attribute is ignored.
'certificate' requires that the path to the certificate is set inside the 'name' parameters.
<To> tag contains all entities onto which the interaction is made (targets). As with the <From> tag, many entities can be specified.
15: <To> 16: <Entity type='VN' name='Locale'/> 17: </To>
The <Communication> tag defines security policies to apply to requests and replies.
18: <Communication>
<Request> sets the policy associated with a request. The 'value' parameter can be:
'authorized' means a request is authorized.
'denied' means a request is denied.
Each <Attribute> (authentication,integrity, confidentiality) can be required, optional or denied.
19: <Request value='authorized'> 20: <Attributes authentication='required' integrity='optional' confidentiality='optional'/> 21: </Request>
<Reply> tag has the same parameters that <Request>
22:<Reply value='authorized'> 23: <Attributes authentication='required' integrity='required' confidentiality='required'/> 24:</Reply> 25:</Communication>
<Migration> controls migration between <From> and <To> entities. Values can be 'denied' or 'authorized'.
26: <Migration>denied</Migration>
<OACreation> controls creation of active objects by <From> entities onto <To> entities.
Values can be 'denied' or 'authorized'.
27: <OACreation>denied</OACreation>
The following shows the complete security policy.
2: <Policy>
3: <ApplicationName>Garden</ApplicationName>
4: <Certificate>/net/home/acontes/certif/appli.cert</Certificate>
5: <PrivateKey>/net/home/acontes/certif/appli.key</PrivateKey>
6: <CertificationAuthority>
7: <Certificate>...</Certificate>
8: </CertificationAuthority>
9:
10: <Rules>
11: <Rule>
12: <From>
13: <Entity type='VN' name='vm2'/>
14: </From>
15: <To>
16: <Entity type='VN' name='Locale'/>
17: </To>
18: <Communication>
19: <Request value='authorized'>
20: <Attributes authentication='required'
integrity='required'
confidentiality='required'/>
21: </Request>
22: <Reply value='authorized'>
23: <Attributes authentication='required'
integrity='required'
confidentiality='required'/>
24: </Reply>
25: </Communication>
26: <Migration>denied</Migration>
27: <OACreation>denied</OACreation>
29: </Rule>
30: <Rule>
31: <From>
32: <Entity type='certificate' name='certificateRuntime1.cert'/>
33: </From>
34: <To>
35: <Entity type='VN' name='Locale'/>
36: </To>
37: <Communication>
38: <Request value='authorized'>
39: <Attributes authentication='required'
integrity='required'
confidentiality='required'/>
40: </Request>
41: <Reply value='authorized'>
42: <Attributes authentication='required'
integrity='required'
confidentiality='required'/>
43: </Reply>
44: </Communication>
45: <Migration>denied</Migration>
46: <OACreation>denied</OACreation>
48: </Rule>
...
90: <Rule>
91: <From>
92: <Entity type='DefaultVirtualNode' name='*'/>
93: </From>
94: <To>
95: <Entity type='DefaultVirtualNode' name='*'/>
96: </To>
97: <Communication>
98: <Request value='denied'>
99: <Attributes authentication='optional'
integrity='optional'
confidentiality='optional'/>
100: </Request>
101: <Reply value='denied'>
102: <Attributes authentication='optional'
integrity='optional'
confidentiality='optional'/>
103:
104: </Reply>
105: </Communication>
106: <Migration>denied</Migration>
107: <OACreation>authorized</OACreation>
109: </Rule>
110:
111: </Rules>
112:</Policy>Note that the JVM that reads the deployment descriptor should be started with a 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.
Here is an example:
java -Dproactive.runtime.security=descriptors/security/jvmlocal.xml TestSecureDeployment secureDeployment.xml
© 1997-2008 INRIA Sophia Antipolis All Rights Reserved