Security Guide : Quality of Protection
Quality of Protection
VisiBroker's extensions of standard CORBA policies include an implementation of Quality of Protection (QoP) which provides another level of fine-grained control over your run-time security requirements.
There are two types of QoP:
•
Server QoP is usually installed on a Portable Object Adapter (POA)
•
Client QoP is usually installed on a object
Setting properties and QoP
There are several properties that can be used to ensure the Quality of Protection of a connection. These properties can be used to fine-tune connection quality.
For example, you can set the cipherList property for SSL connections to set cryptography strength:
vbroker.security.cipherList
This property is set to a list of comma-separated ciphers to be enabled by default on startup. If not set, a default list of cipher suites will be enabled.
QoP properties can also be set programmatically using ServerQoPConfig and the ClientQoPConfig for servers and clients, respectively. For more information, see “Configuring Quality of Protection(QoP)”.
These APIs allow you to set target trust (whether or not targets must authenticate), the transport policy (whether or not to use SSL or another secure transport mechanism specified separately). For servers, an AccessPolicyManager that can access the RoleDB is set to access policies for POA objects. For more information on AccessPolicyManager, see “class csiv2::AccessPolicyManager”.
Configuring Quality of Protection(QoP)
Configuring QoP for the server
The complete code of ServerQoPConfigValueFactory is as follows:
package com.borland.security.csiv2;
import com.borland.security.csiv2.ServerQoPConfigValueFactory;
import com.borland.security.csiv2.ServerQoPConfig;
import com.borland.security.csiv2.AccessPolicyManager
 
public class ServerQoPConfigDefaultFactory
implements ServerQoPConfigValueFactory {
public ServerQoPConfig createConfig ( boolean disable,
short transport,
short idType,
boolean
enableIdAssertion,
java.lang.String[]
 
realms, AccessPolicyManager access_manager )
 
{
return new ServerQoPConfigImpl(disable, transport, idType, enableIdAssertion, realms, access_manager);
 
}
}
disable = security is disabled/enabled for this POA, When security is disabled, the rest of the settings become irelevant.
In this package:
•
transport has three possible values:
•
CLEAR_ONLY: Uses only clear listener to accept request
•
SECURE_ONLY: Uses only SSL listener to accept request
•
ALL: Uses both clear and SSL.
•
idType has the possible values of com.borland.security.csiv2.ServerQoPPolicy.
Value
Description
NO_ID
Expecting no identity
UP
Expecting Username Password identity
PK
Expecting transport identity
UP_AND_PK
Expecting both to be present and valid
UP_OR_PK
Expecting either one to be present and valid
•
enableIdAssertion = true/false. When set to false, this server cannot accept caller identity propagated through a CSIV2 Authorization token.
•
realms[] is an array of strings, specifying the names of all realms that this POA can accept identity of. The default value is ‘null’ meaning there are no configured realms in this ORB.
•
access_manager is, for authorization purposes, the AccessPolicyManager responsible for this POA. The default value is ‘null’ meaning there is no authorization.
For configuring QoP for the server, follow the steps as given below:
1
To enable access controls, set disable = false
2
For a method to be secure, set transport = SECURE_ONLY
3
For the server to require a client’s credentials for authentication, set trust_in_client = true.
For more information on transport methods and other QoP related parameters, see “class vbsec::ServerConfigImpl”.
4
To create server QoP configuration object
ServerQoPConfig config = new ServerQoPConfigDefaultFactory().create(false,ServerQoPPolicy.SECURE_ONLY,true, null);
5
To activate the server with QoP:
Any any = orb.create_any();
ServerQoPConfigHelper.insert(any, config);
Policy qop = orb.create_policy(SERVER_QOP_CONFIG_TYPE.value, any);
Configuring QoP for the client
The initial step of creating a QoP is to create a QoPConfig and specify the security requirements that must be enforced through the config.
To create a ClientQoPConfig, you can use its default factory as follows:
...
...
com.borland.security.csiv2.ClientQoPConfig myconfig =
new com.borland.security.csiv2.ClientQoPConfigDefaultFactory().create
 
/* transport = */ com.borland.security.csiv2.ClientQoPPolicyOperations.CLEAR_ONLY,
 
/* Other possible values for above are SECURE_ONLY and USE_ANY*/
 
/* trustInTarget= */ true
 
);
 
Transport methods
trustInTarget=true
trustInTarget=false
CLEAR_ONLY
Invalid configuration; will throw PolicyError.
For outgoing, use clear IIOP transport.
SECURE_ONLY
For outgoing, use SSL and make sure that server certificate is trusted.
For outgoing, use SSL and server certificate can be non-trusted.
USE_ANY
Invalid configuration; will throw PolicyError.
For outgoing, try SSL then fallback to clear when fail, server certificate can be non-trusted.
The complete code of ClientQoPConfigDefaultFactory is as follows:
package com.borland.security.csiv2;
 
public class ClientQoPConfigDefaultFactory
 
implements
com.borland.security.csiv2.ClientQoPConfigValueFactory {
public com.borland.security.csiv2.ClientQoPConfig create ( short trans,
boolean trustInTarget ) {
return new ClientQoPConfigImpl( trans, trustInTarget );
}
}
1
Initialize the ORB/
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
byte[] managerId = "BankManager".getBytes();
Note: For client, QoP is set as follows:
For method to be secure, set transport = secure only
Set trust in target = false. (With this, server need not provide authentication for client).
For more information on transport methods and other QoP parameters, see “class vbsec::ClientConfigImpl”.
ClientQoPConfig cc = new ClientQoPConfigDefaultFactory().create( ClientQoPPolicy.SECURE_ONLY, false);
 
org.omg.CORBA.Object managerObject =
Bank.AccountManagerHelper.bind( orb, "/bank_agent_poa", managerId );
2
Insert client QoP into any object:
Any any = orb.create_any();
ClientQoPConfigHelper.insert( any, cc);
3
Narrow the reference to Bank Manager using the policy
Bank.AccountManager manager = Bank.AccountManagerHelper.narrow(
managerObject._set_policy_override(
new Policy[] { orb.create_policy( CLIENT_QOP_CONFIG_TYPE.value, any)
},
SetOverrideType.SET_OVERRIDE));
4
Create or open an account for the user. This returns a generic Account object reference.
org.omg.CORBA.Object accountObject = manager.open( name);
5
Narrow the reference to Bank Account
Bank.Account account = Bank.AccountHelper.narrow(
accountObject._set_policy_override(
new Policy[] { orb.create_policy( CLIENT_QOP_CONFIG_TYPE.value, any) },
SetOverrideType.SET_OVERRIDE
)
);
6
Get the balance from the account and print it on the console
System.out.println("The balance in " + name + "'s account is $" + account.balance() );
} catch( Throwable e) {
synchronized( System.err) {
e.printStackTrace();
}
}
}
public static void main(String[] args) {
if ( args.length != 0) {
System.err.println( "Usage : vbj -DORBpropStorage=client.properties Client");
System.exit(1);
}
Client cln = new Client();
cln.test(args);
}
}
Configuring Quality of Protection (QoP) parameters
When clients and servers communicate, they both need to agree on some parameters for the Quality of Protection (QoP) that will be provided. The resource host (the server) will:
•
publish all the QoP parameters that it can support, and
•
impose a set of required QoP parameters on the clients.
Note
By definition, a required QoP is also a supported QoP.
For example, a server may support and require secure transport (SSL) while it may support authentication but not require it. This is useful, for example, in the case where some resources are not sensitive and anonymous access is acceptable. For more information about QoP and QoS parameters:
C++
See “QoP API” on page 146.
Java
See com.borland.security.csiv2 and “Security Properties for Java”.