3.2.2 Secure JiniME Architecture
3.2.2.4 Mobile-Client-to-Sessile-Service Bridge
As illustrated in Figures 3-6 and 3-7, Mobile-Client-to-Sessile-Service Bridge, which includes following, is exactly the reverse of the Sessile-Client-to-Mobile-Service Bridge.
z Sessile Service Bridge Builder application. It does the following:
1. The builder application logins the KDC belongs to Realm B and discovers all the Jini LUS on the wired side using the Jini discovery protocols, then
registers to receive notifications of added, changed, and removed services.
2. From each Jini Lookup Service, the builder application obtains all the Jini service items. Each of these is a Sessile Service (S.S.).
3. For each Sessile Service, the builder application uses reflection to construct a standard Jini service, called the Sessile Service Bridge (S.S.B.), that has the same interfaces as the Sessile Service and that is implemented to delegate all method invocations to the Sessile Service's proxy object.
4. The builder application runs each newly-constructed Sessile Service Bridge.
5. When the builder application detects that a Jini service has disappeared, the builder application shuts down the corresponding Sessile Service Bridge.
Figure 3-6 Constructing a Bridge for a Sessile Service and registering it with the JiniME federation
z Sessile Service Bridges. Each Sessile Service Bridge which the bridge builder constructs does the following:
1. Adds its Jini service item to the Jini Bridge's own Secure JiniME Lookup Service in the Secure JiniME federation. The Jini service item consists of:
i. The same service ID as the Sessile Service.
ii. The same service attributes as the Sessile Service.
iii. A service proxy object which uses the previously-described techniques to let Secure JiniME client applications invoke the Sessile Service Bridge.
2. Exports its service proxy object's codebase via the Jini Bridge's HTTPS or HTTPMD server.
3. When a message arrives from the Sessile Service Bridge proxy object,
translates the message into a method call on the Sessile Service proxy object.
4. When shut down, removes its service item from the Jini Bridge's Secure JiniME Lookup Service.
Figure 3-7 A JiniME clients discovering a Sessile Service and invoking it via the Sessile Service Bridge
Chapter 4 Implementation
In this chapter, the way an overview will be provided for the implementation of the proposed modified version of [2, 3]: (1) coding snips of Secure JiniME, (2) the way system is set up, and (3) the execution of program. For the first topic, it includes some code snips such as Client, Service, HTTPMD Server, and Jini Bridge that we will be described in Sections 4.1 - 4.4; for the second topic, we will describe how to set security properties and system properties and how to set JAAS configuration as well as the security policy of access control in Section 4.5; for the last topic, which will describe how to prepare to running program in Section 4.6.
4.1 Client Code Snip
As described in Section 3.2.2, Secure JiniME Architecture consists of two devices.
Specifically, the role of Secure JiniME-capable device could be a client to request services, a server to offer services, or both. In this Section, we will discuss some implementation details about client code. The Secure JiniME Client uses Kerberos to authenticate and login with KDC as follows:
final Configuration config = ConfigurationProvider.getInstance(args);
LoginContext loginContext = (LoginContext) config.getEntry(
"com.sun.securejinime.hello.Client", "loginContext",LoginContext.class, null);
if (loginContext == null) {
System.out.println("No JAAS login is performed!”));
} else {
loginContext.login();
Subject.doAsPrivileged(loginContext.getSubject(), new PrivilegedExceptionAction() {
public Object run() throws Exception {
mainAsSubject(config);
return null; } }, null);
}
In order to login KDC, client needs to instantiate LoginContext and Configuration objects. LoginContext uses Configuration to configure itself. The purpose of a login context is to allow retrieval of an authenticated user, which is represented as a subject object. The Subject class is used to represent an authenticated user. In fact, each user is represented as an array of Principal objects stored by this class. There is an array of objects because each user is likely to have several identifying characteristics.
After obtain a user login object, the program issues a method call (the doAS( ) or doAsPrivileged( ) method), passing in the user login object and the code that should be executed on behalf of that user. As in following code, “ServiceTemplate” describes service attributes and Client uses “serviceDiscovery” to lookup it. If succeeded, it will return the service’s proxy. Otherwise, it will throw Exception.
static void mainAsSubject(Configuration config) throws Exception {
ServiceDiscoveryManager serviceDiscovery;
try {
serviceDiscovery = (ServiceDiscoveryManager) config.getEntry(
"com.sun.securejinime.hello.Client",
"serviceDiscovery",ServiceDiscoveryManager.class);
} catch (NoSuchEntryException e) {
/* Default to search in the public group */
serviceDiscovery = new ServiceDiscoveryManager(
new LookupDiscovery(new String[] { "" }, config),
null, config);
}
ServiceItem serviceItem = serviceDiscovery.lookup(
new ServiceTemplate(null, new Class[] { Hello.class }, null),null, Long.MAX_VALUE);
Hello server = (Hello) serviceItem.service;
ProxyPreparer preparer = (ProxyPreparer) config.getEntry(
"com.sun.securejinime.hello.Client",
"preparer", ProxyPreparer.class, new BasicProxyPreparer());
server = (Hello) preparer.prepareProxy(server);
System.out.println("Server says: " + server.sayHello());
System.exit(0);
}
4.2 Server Code Snip
In this Section, we will discuss some implementation details about server code in this Section because the role of Secure JiniME-capable device could be a server to offer services. The Secure JiniME server uses Kerberos to authenticate and login with KDC as follows:
protected void init() throws Exception {
LoginContext loginContext = (LoginContext) config.getEntry(
"com.sun.securejinime.hello.Server", "loginContext", LoginContext.class, null);
if (loginContext == null) {
System.out.printlin(“No JAAS login is performed!”);
} else {
loginContext.login();
Subject.doAsPrivileged(
loginContext.getSubject(), new PrivilegedExceptionAction() {
public Object run() throws Exception { initAsSubject();
return null;
}
}, null);
} }
In the code above, it first instantiates a LoginContext object then uses config object to configure itself and login with KDC. It behaves in the same way as a client as discussed in Section 4-1, the only different is the behavior of the method call (the doAsPrivileged( ) or doAS( ) method). After login, it instantiates proxy, discovery manager, and join manager objects then makes use of DiscoveryManagement object to discover lookup services. If succeeded, server joins local lookup service; otherwise, it prints error message.
protected void initAsSubject() throws Exception {
/* Get the discovery manager, for discovering lookup services */
DiscoveryManagement discoveryManager;
try {
discoveryManager = (DiscoveryManagement) config.getEntry(
"com.sun.securejinime.hello.Server", "discoveryManager", DiscoveryManagement.class);
/* Get the join manager, for joining lookup services */
JoinManager joinManager =
new JoinManager(smartProxy, null /* attrSets */, getServiceID(), discoveryManager, null /* leaseMgr */, config);
} catch (NoSuchEntryException e) {
/* Print error message */
System.out.println(“Can’t find local lookup service!”);
} }
4.3 HTTPMD Code Snip
A preferred class provider computes HTTP Message Digest (HTTPMD) URLs to use as the class annotation for classes in the application and bootstrap classpath.
public class MdClassAnnotationProvider
extends PreferredClassProvider {
private final String codebase =
HttpmdUtil.computeDigestCodebase(
System.getProperty("export.codebase.source"), System.getProperty("export.codebase"));
public MdClassAnnotationProvider()
throws IOException, MalformedURLException {
super(false);
}
protected String getClassAnnotation(ClassLoader loader) {
return codebase;
} }
The following system properties control the HTTPMD URLs created:
z Dexport.codebase: Space-separated lists of the HTTPMD URLs for use as codebase. The digest values specified in the URLs will be ignored. The path portion of the URLs, without the message digest parameters, will be used to
specify the source files, relative to the source directory, to use for computing message digests.
z Dexport.codebase.source: The name of the directory containing the source files corresponding to the URLs in the codebase
4.4 Jini Bridge Code Snip
The Secure JiniME Sessile-Client-to-Mobile-Service Bridge uses Kerberos to authenticate and login with KDC as follows:
final Configuration config = ConfigurationProvider.getInstance(args);
LoginContext loginContext = (LoginContext) config.getEntry(
"com.sun.securejinime.hello.SCMSBridge","loginContext", LoginContext.class,null);
if(loginContext == null){
System.out.println("No JAAS login performed!");
} else{
loginContext.login();
Subject.doAsPrivileged(
loginContext.getSubject(),
new PrivilegedExceptionAction() {
We can see the code above, it first instantiates LoginContext object and uses config object to configure itself and login with KDC. It behaves the same as client discussed in Section 4-1. After login, it instantiates discovery manager object then uses service
discovery manager object to discovery services and stores all information in lookup cache.
Afterward, it constructs each M.S.Proxy for each service to export service proxy and issues run method to login Jini federation KDC, discovers Jini federation Lookup service,
registers itself and exports M.S.B proxy.
protected void builderAsSubject(Configuration config) throws Exception {
final int maxMatches = 100;
ServiceItem[] serviceitem;
ServiceDiscoveryManger serviceDiscovery;
MSBridge msBridge[];
try{
serviceitem = new int[maxMatches];
serviceDiscovery = (ServiceDiscoveryManager) config.getEntry(
"com.sun.securejinime.hello.SCMSBridge","serviceDiscovery", ServiceDiscoveryManager.class,null);
/* Use ServiceDiscoveryManager to discovery services and store all information in Lookup Cache */
ServiceCache serviceCache =
serviceDiscovery.createLookupCache(null,null,serviceChange);
serviceitem = serviceCache.lookup(null,maxMatches);
msBridge = new MSBridge[maxMatches];
for(int i=0;i<maxMatches;i++){
/* Each M.S.Bridge setMSProxy will prepare for M.S.Proxy, The serviceCache implements LookupCache which uses serviceChange that implement ServiceDiscoveryListener,
if any serives change occur */
msBridge[i].setMSProxy(serviceitem[i]);
msBridge[i].run();
/* run( ) method will do the same behavior as client: login
System.out.println("No such entry!”);
} }
The Mobile-Client-to-Sessile-Service Bridge code is exactly similar with the Sessile-Client -to-Mobile-Service Bridge code, so that we omitted it.
4.5 Properties Setting
As mentioned, we have discussed some implementation details of Secure JiniME coding. In subsequent contents, we will describe properties setting of Secure JiniME. We will discuss Kerberos requirements in Section 4.5.1, setting security properties in Section 4.5.2, login configuration file in Section 4.5.3, and policy file in Section 4.5.6.