]> Introduction Invocation constraints Method constraints Logging Protocols TCP SSL Proxy preparer File classifier server Integrity Client TCP server SSL server Proxy verification HTTPMD Calculating HTTPMD URLs Reggie Proxy verifier Client with proxy verification SSL trusted server Errors Confidentiality Client SSL confidential server Mix 'n Match Identity Management JAAS Keystores Authenticating Server Client requiring authentication Alternative constraints Authenticating Client Server Requiring Authentication Authorisation Conclusion Jini from the beginning has used the Java security model to control the actions of proxies when they are run from clients. However, this does not control security of the transport aspects of remote method calls. Jini 2.0 introduced a wide-ranging set of mechanisms largely aimed at such issues as encryption, authorisation, etc Prior to version 2.0, Jini just used the standard Java security mechanism. This was designed to deal with code downloaded from a remote location, and was put in place to limit what foreign code could be in a local virtual machine. This is a capability-based model, in which the client grants to foreign code the capability of performing certain activities. So for example, foreign code cannot write to the local file system unless this permission has been granted. This was covered in detail on the chapter on Basic Security. What this has ignored is a range of issues concerning the network transport. For example Integrity: have the classes and instance data reached the client in the form they started, or has someone along the way corrupted them? Authentication: did the data come from whom you expected, or did it come from someone else? The client may need to authenticate itself to the server, or vice-versa Authorisation: once you know who it came from, what rights will you grant it? This was covered in the Basic Security chapter Confidentiality: has the data been encrypted so that others cannot read it? These are standard network security concerns. However, Jini gives them some special wrinkles. For example, instance data for a proxy may be sent from a server to a client either directly or via a lookup server. In addition to the instance data, class files often have to be loaded, and these may come from a third party HTTP server. There are even subtleties in where a service may be running: an activatable service doesn't run in the server that started it, but in a third party activation service. The security considerations act as constraints on normal execution: something that might have been allowed will be restricted. For example, a client may put the constraint that communications be encrypted. It might not want to know many details of how this has been done (that sort of detail can be left to the middleware itself). But if it hasn't been done, then it will just not accept the communication. Jini 2.0 defines a set of objects that specify constraints on behaviour. They don't specify how a constraint is implemented, just what the constraint is. Some of these are Integrity.YES: Detect when message contents (both requests and replies) have been altered by third parties, and if detected, refuse to process the message and throw an exception Integrity.NO: Do not detect when message contents have been altered by third parties In between YES and NO is DON'T CARE. There is no specific object to express this constraint (or lack of it). If you don't care whether it is checked or not, then you don't specify either a YES or NO constraint - you just don't mention the constraint at all Confidentiality.YES: Transmit message contents so that they cannot easily be interpreted by third parties (typically by using encryption) Confidentiality.NO: Transmit message contents in the clear (no use of encryption) Similarly, in between YES and NO is DON'T CARE. There is no specific object to express this constraint (or lack of it). You just don't use either the YES or NO object to mean that you don't care if it is confidential or not - this is common to all constraints ClientAuthentication.YES: The client must authenticate to the server ClientAuthentication.NO: Do not authenticate the client to the server. This has a special meaning in that the client will refuse to say who it is: the client remains anonymous. This may be important for applications where participants wish to preserve their privacy ServerAuthentication.YES : Authenticate the server to the client ServerAuthentication.NO : Do not authenticate the server to the client, so that the server remains anonymous The JavaDoc for InvocationConstraint lists all its subclasses, and within each of these will be constant objects such as the above. Each InvocationConstraint can potentially limit client or server activity. We can make up two sets of constraints: mandatory constraints that must be satisified and preferences that should be satisfied if they do not conflict with a mandatory one. For eaxmple, if both Integrity.YES and Integrity.No are specified as mandatory then any call must fail. If however one is specified as mandatory and the other as preferred, then the mandatory one must be satisfied. An InvocationConstraints (note the plural) takes a set of mandatory and a set of preferred constraints. These can be specified as collections or arrays to a constructor. class InvocationConstraints { InvocationConstraints(Collection reqs, Collection prefs); InvocationConstraints(InvocationConstraint[] reqs, InvocationConstraint[] prefs); InvocationConstraints(InvocationConstraint req, InvocationConstraint pref); ... } Whenever a method call is made, constraint checks should be made. For example, a bank method withdraw() should always authenticate the caller. It should be done on each call, not just once - a certificate that is valid for one call may not be valid the next time a call is made. The MethodConstraints interface allows each method to have its own set of constraints: for example a method that sends credit card details might require encryption whereas a "browse" request would not. A BasicMethodConstraints class is usually used as implementation of this interface. In this all methods can be set to use the same set of constraints or it can be set up on a per-method basis. class BasicMethodConstraints { BasicMethodConstraints(InvocationConstraints constraints); BasicMethodConstraints(BasicMethodConstraints.MethodDesc[] descs); ... } It is difficult to get security right, and hard to debug. The Logger is your friend here (see the chapter on Logging). Security is handled by the net.jini.security.Security and this writes to three loggers net.jini.security.integrity net.jini.security.trust net.jini.security.policy Sample code to get logging information from the client is static final String TRUST_LOG = "net.jini.security.trust"; static final String INTEGRITY_LOG = "net.jini.security.integrity"; static final String POLICY_LOG = "net.jini.security.policy"; static final Logger trustLogger = Logger.getLogger(TRUST_LOG); static final Logger integrityLogger = Logger.getLogger(INTEGRITY_LOG); static final Logger policyLogger = Logger.getLogger(POLICY_LOG); private static FileHandler trustFh; private static FileHandler integrityFh; private static FileHandler policyFh; private static void installLoggers() { try { // this handler will save ALL log messages in the file trustFh = new FileHandler("log.client.trust.txt"); integrityFh = new FileHandler("log.client.integrity.txt"); policyFh = new FileHandler("log.client.policy.txt"); // the format is simple rather than XML trustFh.setFormatter(new SimpleFormatter()); integrityFh.setFormatter(new SimpleFormatter()); policyFh.setFormatter(new SimpleFormatter()); trustLogger.addHandler(trustFh); integrityLogger.addHandler(integrityFh); policyLogger.addHandler(policyFh); trustLogger.setLevel(java.util.logging.Level.ALL); integrityLogger.setLevel(java.util.logging.Level.ALL); policyLogger.setLevel(java.util.logging.Level.ALL); } catch(Exception e) { e.printStackTrace(); } } There is a range of different protocols that can be used to shift data around the network. These include TCP and HTTP (which of course is layered above TCP), and those designed with security in mind such as HTTPS, SSL (now officially TLS) and others. A service uses TCP by using a BasiJeriExporter with TCP server. Typically the exporter will be defined in a configuration file such as TCP does not support any of the security mechanisms of this chapter. So we use it as a "bad example" once and then no longer consider it. The server can use Jeri over SSL, by a configuration such as config/security/jeri-ssl-minimal.config SSL is designed to support encryption using a secret key mechanism following open negotiation. It can also support authentication of both client and server using public key certificates. When a client gets a proxy from a server, the server may already have placed some constraints on it. But any of these constraints are those that the server requires, not those that the client may require. So the client has to set its own constraints on the service proxy. It does this by creating a new proxy from the original by adding in its own constraints. The is described by both an interface and sample implementations. The interface is ProxyPreparer interface ProxyPreparer { Object prepareProxy(Object proxy) throws RemoteException; } and an implementation is BasicProsyPreparer class BasicProxyPreparer { BasicProxyPreparer(); BasicProxyPreparer(boolean verify, MethodConstraints methodConstraints, Permission[] permissions); BasicProxyPreparer(boolean verify, Permission[] permissions); } The second constructor is the one most likely to be used by a client: get a proxy from a service, create a basic proxy preparer with constraints and permissions (and whether or not to verify the proxy - see later) and use this to prepare a new proxy with the constraints and permissions. The new proxy is then used for all calls on the service. A client that finds a file classifier and prepares a new service proxy, taking the proxy preparer from a configuration file is A minimal configuration file for this client is config/security/preparer-minimal.config This can be run directly by java ... client.TestFileClassifierProxyPreparer \ config/security/preparer-minimal.config or from the Ant build files by ant run -DrunFile=client.TestFileClassifierProxyPreparer \ -Dconfig=config/security/preparer-minimal.config This client will run successfully with any service that does not impose any constraints on the client. So, for example, it will run with any service of earlier chapters which do not impose any contraints at all. However, using this configuration it will not run with some of the examples later in this chapter which do impose client-side constraints. A file classifier server using configuration has already been given in the chapter Configuration. The version here is almost the same, with the addition of placing the service name in the configuration (since we might need to run different versions of the service for different security requirements). This server can be run using a configuration file such as a standard Jeri over TCP configuration config/security/jeri-tcp.config This can be run from gthe command line by java ... security.FileClassifierServer \ config/security/jeri-tcp.config or from the Ant build files by ant run -DrunFile=security.FileClassifierServer \ -Dconfig=config/security/jeri-tcp.config The server with the rmi.FileClassifierImpl and config/security/jeri-tcp.config configuration has no security features, and will be discarded by a client that imposes any constraints. However, by changing the service class or configuration file it can meet various client requirements. To build the server and run it with various configuration files I use the Ant file security.FileClassifierServer.xml. This configuration file is a bit trickier than earlier ones in that it needs to set different parameters for different situations. For example, in the following section on Integrity ordinary HTTP URLs can be used but in the later section on Proxy Trust a different type of URL, HTTPMD ones must be used. This is controlled by various command line "defines" which can run specialised targets such as httpmd if the Ant file is run with a command-line define of -Ddo.trust=yes. This sets the property codebase.httpd to an HTTPMD URL. Otherwise, the target is not run and a default value of this property as an HTTP URL is used. The Ant file is Integrity ensures that each method call sent from the client to server gets there in original form - that is, it is not altered in any way, and similarly that replies are not altered. It does not guarantee privacy - anyone can look at messages (that is the role of confidentiality). It also does not guarantee that the entity you are sending messages to is the one you think it is (that is the role of authentication). A client can enforce integrity by requiring that the proxy support the constraint Integrity.YES. With the example client above, this can be done by using the config/security/preparer-integrity.config configuration file To run the client using this configuration, run java ... client.TestFileClassifierProxyPreparer \ config/security/preparer-integrity.config or ant run -DrunFile=client.TestFileClassifierProxyPreparer \ -Dconfig=config/security/preparer-integrity.config instead of java ... client.TestFileClassifierProxyPreparer \ config/security/preparer-minimal.config or ant run -DrunFile=client.TestFileClassifierProxyPreparer \ -Dconfig=config/security/preparer-minimal.config Note that only the configuration file has changed. TCP does not support integrity checking. Using TCP, we can expect integrity to fail. The server can use Jeri over TCP, by a configuration such as config/security/jeri-tcp.config It can be run by java ... security.FileClassifierServer config/security/jeri-tcp.config or from the Ant file by ant run -DrunFile=security.FileClassifierServer \ -Dconfig=config/security/jeri-tcp.config The client can find the service, and create a new proxy for it. But when it tries to call a method through this proxy, integrity checking will fail. This shows by the client throwing an exception java.rmi.ConnectIOException: I/O exception connecting to BasicObjectEndpoint[e42fc746-e7c7-444b-bbc9-b124217439c4, TcpEndpoint[127.0.0.1:43084]]; nested exception is: net.jini.io.UnsupportedConstraintException: cannot satisfy constraint: Integrity.YES This exception is thrown when the client attempts to call any method on the proxy. In the example above, it occurs in the first method call to the proxy type = classifier.getMIMEType(fileName) TCP not only fails to support integrity checking, it also fails to support any of the other security mechanisms of this chapter. We will not consider it any further in this chapter. SSL (or TLS) does support integrity checking. The server can use Jeri over SSL, by a configuration such as config/security/jeri-ssl-minimal.config It can be run by java ... security.FileClassifierServer config/security/jeri-ssl-minimal.config or from the Ant file by ant run -DrunFile=security.FileClassifierServer \ -Dconfig=config/security/jeri-ssl-minimal.config The service used here is still the RMI service discussed in earlier chapters rmi.FileClassifierImpl The service needs no changes to satisfy integrity - integrity is supplied by the SSL protocol. This service/server/configuration combination works with no exceptions thrown. This section was the "teaser": Look how easy it is to implement advanced security! Just add a constraint to the client and use an appropriate protocol for the service! The following sections look at other aspects of security, and it does get a little more complex :-) When a client finds a service, it goes through several stages: it prepares a service description and asks lookup services if they have any services matching that description. If they do, then the lookup service downloads a MarshalledObject for the service. This basically contains two things: the instance data for the service and a URL for the class files of the service. The service places class or jar files on the HTTP server. The client gets these files from the HTTP server. In Jini 1.2 both the service and client trust the HTTP server. For a secure system this trust should be demonstrable. The client needs to able to verify that the class files it got from the server are the class files that the service put there. This can be done in many ways, but the Jini team has come up with a neat way, called HTTPMD. There is no integrity or other security aspects in getting files from an HTTP server. The standard way of ensuring security means using a protocol such as HTTPS, but this is quite heavyweight, and not really suited to the purpose of proxy verification: while we can get a verified document from an HTTPS server, we still don't know whether or not to trust that server! What we want to get from an HTTP server is a jar file for the classes that are provided by the service. It is only the service that knows if they are correct or not. That is, it doesn't really matter whether or not the HTTP server can be trusted, but whether we can get information from the service to verify the jar file. A common way of checking that two files are identical is to use a hash of each file. A hash is a number (often 128 bits) that is calculated from the file contents. Hash algorithms are designed with two properties If two files have the same hash, then it is "almost certain" that they are the same file (that is, have the same contents) Given a hash value, it is "nearly impossible" to create a file with that hash value So a service can put a jar file on an HTTP server and a client can download it. If the hash calculated by the client is the same as the service thinks it should be, then the client can be "almost certain" that it has the correct file. There are many hash algorithms. Popular ones are MD5 SHA When you get a marshalled object from a lookup service, it contains the URL for the class files. This URL was inserted by the service. If the URL contained the hash for the class files, then it would be possible for a client to verify that it had obtained the correct files. (Of course, this assumes that the lookup service and HTTP server are not in collusion to deliver false hash values - see later for trusting the lookup service.) Jini defines an HTTPMD (HTTP + Message Digest) URL that adds the hash value as component of the URL. The scheme is changed from "http" to "httpmd" and the hash is added as an extra component, along with a statement of the hash algorithm. For example, a URL of http:jan.newmarch.name/classes/FileClassifierServer-dl.jar would change to httpmd:jan.newmarch.name/classes/FileClassifierServer-dl.jar;\ md5=7ef2019216d0e9069308cec29b779bc0 using the MD5 hash algorithm. The service can specify such a URL in its java.rmi.server.codebase property. There is a small hiccup: this is a non-standard protocol that is not recognised by the standard Java virtual machine. There is however a standard mechanism for adding new handlers to a JVM. The process for doing this is described by Brian Maso in the article A New Era for Java Protocol Handlers at http://java.sun.com/developer/onlineTraining/protocolhandlers. The HTTPMD handler is part of the Jini package. It only needs to be installed into the JVM. This is done by defining an appropriate property java -Djava.protocol.handler.pkgs=net.jini.url ... which looks for the class net.jini.url.httpmd.Handler whenever it needs to handle an HTTPMD document. http://java.sun.com/developer/onlineTraining/protocolhandlers/ There are often tools available in any Operating System for calculation of message digests. For example, most Linux distributions include the md5sum command for MD5 digests and shasum for SHA digests. Use of such tools is O/S specific, and must be run by hand or automatically from some sort of script. There is an message digest class in java.security package. This can be used in a platform-independent way. However, it won't directly handle an HTTPMD URL. Jini 2.0 includes the HttpmdUtil class which will calculate digests from a URL. It has two methods class HttpmdUtil { static String computeDigest(URL url, String algorithm); static String computeDigestCodebase(String sourceDirectory, String codebase); } The first method useful if you already have a jar file installed in an HTTP server and wish to calculate its digest. So for example you could call HttpmdUtil.computeDigest("http://localhost/classes/ClassFiles.jar", "MD5"); The resulting digest could be appended to a new URL of type HTTPMD. Note that for this mechanism to be valid, the program using this must trust the HTTP server! A simple program to calculate and print the hash value of a URL using this is PrintDigest We use this program in our Ant files which assume a local trusted HTTP server. The second method is useful before deployment of the jar file to an HTTP server. It returns a new URL for a given URL with a new digest value. For example, the call HttpmdUtil.computeDigestCodebase("dist", "httpmd://localhost/classes/ClassFiles.jar;md5=0"); This strips the scheme, host and digest value from the URL and appends the directories and jar filename to the given directory. In this case it calculates the digest for the local file dist/classes/ClassFiles.jar. It then rebuilds the URL as e.g. httpmd://localhost/classes/ClassFiles.jar;md5=.... This only involves local trust. However, it does rely on a consistent directory convention between local files and HTTP URLs - and I didn't obey that convention :-( A third technique is given in the Jini "hello" example source/vob/jive/src/com/sun/jini/example/hello. This is a sophisticated method and not for the faint-hearted. It installs a new RMIClassLoaderSpi called MdClassAnnotationProvider. The getClassAnnotation() method of this class uses the second method of the HttpmdUtil to generate an HTTPMD URL on demand from an HTTP URL. The standard setup for reggie does not recognise the HTTPMD protocol. I'm not sure why it is looking inside the marshalled objects for this, but it will cause an exception to be thrown in services if it does not understand it. This is an easy fix: add the property -Djava.protocol.handler.pkgs=net.jini.url to the command that starts reggie. When the client gets a proxy for a service, it gets a marshalled object with instance data and a URL for the class files. Assuming that the URL has not been tampered with, it can download the class files from an HTTP server. If it is an HTTPMD URL then it can verify that the class files are correct - as long as it trusts the proxy. This is a tricky problem: how to verify that the proxy is correct when you have a - possibly - false and misleading proxy? Moreover, this possibly antagonistic proxy is the only way you have of talking to the service. The only entity that can really verify that the proxy is correct is the original service. So can we send the proxy to the service and get it to tell us? Well, no: if we ask the untrusted proxy to send itself for verification to the service, then it might just lie and claim that, yes, it has done so. What we have to do is to get an object from the service that can perform verification locally - under the client's eyes, as it were. The mechanism adopted by Jini to solve this is to use several levels of proxy: the (untrusted) service proxy is asked to deliver a "bootstrap" proxy that can deliver a verifier. This verifier is the object that will deliver the verdict on whether the proxy can be trusted, so it must be trustworthy itself. Jini ensures this by insisting that the class files for this verifier are local to the client and so are trusted just like any other local code. The client needs to have a list of local verifiers that it trusts just because they are local. A standard set is given in the Jini library jsk-platform.jar file. This jar file contains the following verifiers: ConstraintTrustVerifier BasicJeriTrustVerifier SslTrustVerifier KerberosTrustVerifier ProxyTrustVerifier ConstrainableLookupLocatorTrustVerifier DiscoveryConstraintTrustVerifier To require trust from a service, the client must do three things Include jsk-platform.jar in its classpath to get a set of proxy verifiers Install an HTTPMD handler by the runtime property java.protocol.handler.pkgs=net.jini.url Specify trust checking by setting the first argument of BasicProxyPreparer to true. A configuration file to require trust checking (and nothing else) is config/security/preparer-trust.config A command line to run this client is java ... client.TestFileClassifierProxyPreparer \ config/security/preparer-trust.config or using Ant ant run -DrunFile=client.TestFileClassifierProxyPreparer \ -Dconfig=config/security/preparer-trust.config SSL will allow trust checking to be performed. The service does not need to be adapted, and can still be the rmi.FileClassifierImpl given above The server needs to install an HTTPMD handler by the runtime property java.protocol.handler.pkgs=net.jini.url The security.FileClassiferServer-dl.jar jar file needs to be created with contents common/MIMEType.class, common/FileClassifier.class, rmi/RemoteFileClassifier.class, rmi/FileClassifierImpl.class and copied to an HTTP server A hash needs to be performed on this security.FileClassiferServer-dl.jar jar file. In this tutorial we use the HttpmdUtil to caculate this as explained earlier (we trust the local HTTP server) The codebase should be an HTTPMD URL, including the hash value from the last step The service does not need to specify anything other than that it uses SSL for transport (the server supplies the HTTPMD codebase). The server can use the config/security/jeri-ssl-minimal.config configuration A command line to run this server is java ... -Djava.rmi.server.codebase=httpmd://... \ security.FileClassiferServer \ config/security/jeri-ssl-minimal.config or from Ant ant run -DrunFile=security.FileClassiferServer \ -Dconfig=config/security/jeri-ssl-minimal.config \ -Ddo.trust=yes This server/configuration will handle a client that requires trust verification. If the trust logger file for the client is examined it will contain lines such as FINE: trust verifiers [net.jini.constraint.ConstraintTrustVerifier...] Aug 16, 2004 9:59:35 PM net.jini.security.Security$Context isTrustedObject FINE: net.jini.jeri.ssl.SslTrustVerifier@df1832 trusts SslEndpoint[127.0.0.1:39693] Aug 16, 2004 9:59:35 PM net.jini.security.Security$Context isTrustedObject FINE: net.jini.jeri.BasicJeriTrustVerifier@1a116c9 trusts BasicObjectEndpoint[...,SslEndpoint[...]] Aug 16, 2004 9:59:35 PM net.jini.security.Security$Context isTrustedObject FINE: net.jini.constraint.ConstraintTrustVerifier@1d1e730 trusts InvocationConstraints[reqs: {}, prefs: {}] Aug 16, 2004 9:59:35 PM net.jini.security.Security$Context isTrustedObject FINE: net.jini.constraint.ConstraintTrustVerifier@1d1e730 trusts BasicMethodConstraints{default => null} Aug 16, 2004 9:59:35 PM net.jini.security.Security$Context isTrustedObject FINE: net.jini.jeri.BasicJeriTrustVerifier@1a116c9 trusts Proxy[RemoteFileClassifier, BasicInvocationHandler[BasicObjectEndpoint[...]] This shows that the SslTrustVerifier trusts the SslEndpoint, and that because of that the BasicJeriTrustVerifier trusts the BasicObjectEndpoint which contains the SslEndpoint. Trust is also applied to the constraints after which the proxy is declared to be trusted. It is important to note the limits of what has been achieved in this section: we have downloaded a proxy that we can trust - but whose proxy is it? We have been assured that the code we have got has not been tampered with by anyone else, but we could still be getting code from "Antagonistic Alice". All that we know at this point is that we have the code that Alice intended to send to us and that Mallory in the middle hasn't tampered with it! If you forget to include jsk-platform.jar in the client's classpath, then it won't be able to find the standard verifiers and won't be able to verify any proxies. The client will throw a SecurityException java.lang.SecurityException: object is not trusted: Proxy[RemoteFileClassifier,BasicInvocationHandler[ BasicObjectEndpoint[1c4c3ec0-f91e-46a6-827b-626575702a07, SslEndpoint[127.0.0.1:56641]]]] at net.jini.security.Security.verifyObjectTrust(Security.java:268) at net.jini.security.BasicProxyPreparer.verify(BasicProxyPreparer.java:309) The trust logger will also show FINE: trust verifiers [] Aug 16, 2004 5:54:27 PM net.jini.security.Security$Context isTrustedObject FAILED: no verifier trusts Proxy[RemoteFileClassifier,BasicInvocationHandler[Bas icObjectEndpoint[1c4c3ec0-f91e-46a6-827b-626575702a07,SslEndpoint[127.0.0.1:5664 1]]]] with the failure caused by an empty verifiers list If the server uses HTTP URLs instead of HTTPMD URLs, then the client is unable to perform an integrity check. This will result in the client throwing a SecurityException java.lang.SecurityException: URL does not provide integrity: http://192.168.1.13/classes/security.FileClassifierServer-dl.jar at net.jini.security.Security.verifyCodebaseIntegrity(Security.java:343) The integrity logger will also show FINE: integrity verifiers [net.jini.url.httpmd.HttpmdIntegrityVerifier@1b5998f, net.jini.url.https.HttpsIntegrityVerifier@17494c8, net.jini.url.file.FileIntegrityVerifier@d3db51] Aug 16, 2004 6:01:27 PM net.jini.security.Security verifyCodebaseIntegrity FAILED: no verifier verifies http://192.168.1.13/classes/security.FileClassifierServer-dl.jar It is necessary to install the HTTPMD handler in the server, the client and in reggie. If you omit to include it in the server, then the discovery logger reports INFO: exception occurred during unicast discovery java.net.MalformedURLException: unknown protocol: httpmd at java.net.URL.>init<(URL.java:544) If you leave this handler out of the client it throws an exception during service discovery java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.net.MalformedURLException: unknown protocol: httpmd at com.sun.jini.reggie.RegistrarProxy.lookup(RegistrarProxy.java:130) If you omit to install the HTTPMD handler in reggie, then when the server runs, it gets an error thrown from reggie which shows in a message from the JoinManager logger: INFO: JoinManager - failure java.rmi.ServerException: RemoteException in server thread; nested exception is: java.rmi.UnmarshalException: unmarshalling method/arguments; nested exception is: java.net.MalformedURLException: unknown protocol: httpmd at net.jini.jeri.BasicInvocationDispatcher.dispatch(...) A conversation is confidential if no-one can overhear it, or even if they can hear it then they cannot understand it. Typically applications use encryption to ensure that messages cannot be read by others. Either a client or a server can specify confidentiality. A client specifies this by making adding a Confidentiality.YES constraint to the proxy preparer. For example, the config/security/preparer-conf.config configuration file can contain To run the client using this configuration, run java ... client.TestFileClassifierProxyPreparer \ config/security/preparer-conf.config or ant run -DrunFile=client.TestFileClassifierProxyPreparer \ -Dconfig=config/security/preparer-conf.config Note that only the configuration file has changed. SSL supports confidentiality. Indeed, that is the major purpose behind its design. So all that is needed is for a server to specify that it is using SSL, which can be done using the earlier config/security/jeri-ssl-minimal.config configuration file A command line to run this server is java ... security.FileClassiferServer \ config/security/jeri-ssl-minimal.config or from Ant ant run -DrunFile=security.FileClassiferServer \ -Dconfig=config/security/jeri-ssl-minimal.config So far we have tried the following combinations preparer-minimal.config and jeri-tcp.config" - no security on either side, and this works the same way as examples in earlier chapters without security preparer-integrity.config and >jeri-tcp.config - this failed due to lack of support by TCP for integrity checking preparer-integrity.config and jeri-ssl-minimal.config - this succeeds since SSL supports integrity checking preparer-trust.config and >jeri-ssl-minimal.config with HTTPMD URLs - this works because SSL supports trust of messages and the HTTPMD URLs allow the client to trust the HTTP server preparer-conf.config and jeri-ssl-minimal.config - this works because SSL supports confidentiality through encryption We can try variations on these: for example, a client that requires trust and integrity with a server that requires encryption. This is just an additive process: add in the extra constraints to the appropriate configuration and ensure that the client or server has the correct runtime to handle the constraints. The client configuration in this case is config/security/preparer-trust-integrity.config and the server configuration is config/security/jeri-ssl-conf.config configuration file These can be run by java ... client.TestFileClassifierProxyPreparer \ config/security/preparer-trust-integrity.config java ... -Djava.rmi.server.codebase=httpmd://... \ security.FileClassiferServer \ config/security/jeri-ssl-conf.config or from Ant ant run -DrunFile=client.TestFileClassifierProxyPreparer \ -Dconfig=config/security/preparer-trust-integrity.config ant run -DrunFile=security.FileClassiferServer \ -Dconfig=config/security/jeri-ssl-.config \ -Ddo.trust=yes This combination works satisfactorily. The client logs are indicative of what has happened. The trust logger shows (with much text elided) FINE: HttpmdIntegrityVerifier verifies httpmd://... FINE: trust verifiers [...] FINE: SslTrustVerifier trusts SslEndpoint[...] FINE: BasicJeriTrustVerifier trusts BasicObjectEndpoint[...] FINE: ConstraintTrustVerifier trusts Confidentiality.YES FINE: ConstraintTrustVerifier trusts InvocationConstraints[reqs: {Confidentiality.YES}, prefs: {}] FINE: ConstraintTrustVerifier trusts BasicMethodConstraints{default => InvocationConstraints[reqs: {Confidentiality.YES}, prefs: {}]} FINE: BasicJeriTrustVerifier trusts Proxy[...] This shows that the HttpmdIntegrityVerifier trusts the HTTPMD URL; The SslTrustVerifier trusts the SslEndpoint; the ConstraintTrustVerifier trusts Confidentiality; and hence the ConstraintTrustVerifier trusts the BasicMethodConstraints; and so finally, the BasicJeriTrustVerifier trusts the proxy. Similarly, the integrity log shows FINE: integrity verifiers [...] FINE: HttpmdIntegrityVerifier verifies httpmd://... showing that the HttpmdIntegrityVerifier verifies the HTTPMD URL. By way of contrast, if the client is run with one constraint and the server is run with its opposite, then the constraints cannot be satisfied. For example, if the client has set Confidentiality.NO and the server has set Confidentiality.YES, then the client will throw an exception java.rmi.ConnectIOException: I/O exception connecting to BasicObjectEndpoint[...,SslEndpoint[...]]; nested exception is: net.jini.io.UnsupportedConstraintException: Constraints not supported: InvocationConstraints[reqs: {Confidentiality.NO, Confidentiality.YES}, prefs: {}] If you want to give different individuals different access rights, then you need to be able to verify their identity. This means that they must have some way of expressing what their identity is in a form that you will recognise. People (and things) may have a number of identities: the father of a particular person, the staff id number, the driving license number, their name, and so on. Essentially, different labels for the one entity. The terminology adopted is that the entity is called a subject, and in Java this is represented by the Subject class in the javax.security.auth package. The different identities for a subject are called principals, and they too have a Java class, the Principal class. A subject authenticates itself to a service using a principal and information to verify itself as that principal. For example, you log into a computer using your username as principal and password for verification. Other mechanisms could be used. For example, you verify yourself to the police officer who has just pulled you over by the photo on your drivers license. A credential (such as a driver's license) is used to authenticate a subject to later services. In the computer world, these include be X.509 certificates and Kerberos tickets. A white paper describing JAAS is at USER AUTHENTICATION AND AUTHORIZATION IN THE JAVA(TM) PLATFORM (http://java.sun.com/security/jaas/doc/acsac.html), with other information such as "JavaTM Authentication and Authorization Service (JAAS) Reference Guide" which should be in the Java distribution directory docs/guide/security/jaas/JAASRefGuide.html and "JAAS Authentication" at http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/AcnOnly.html JAAS (Java Authentication and Authorization Service) is a framework for verifying common identities. These include JNDI KeyStore Kerberos Windows NT Unix Information on these can be found at http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/LoginConfigFile.html. JAAS augments the standard Java security model by adding support for principals. So security access is not just granted on the properties of the code itself (signed, etc) but also on the principals running the code. In order to use JAAS, you firstly need to create a LoginContext. This picks up information from a configuration file to decide which principal it is authenticating as, and how to do it. The configuration file is similar in concept to the Jini configuration files, but the syntax is different and the contents depend upon the mechanism used. Once you have a context, you attempt to login(). If successful, you are then a recognised entity, and are a subject with identity. As a subject, you may be able to do more things than if you have no identity. For example, in an SSL interaction you will be able to present certificates for this identity if required. Similarly with Kerberos: if challenged, you have an identity and a ticket credential to prove it. You then add the JAAS security checks to code by running it as the privileged subject. The code for this looks like LoginContext loginContext = new LoginContext("..."); if (loginContext == null) { // do some action without JAAS security } else { loginContext.login(); Subject.doAsPrivileged( loginContext.getSubject(), new PrivilegedExceptionAction() { public Object run() throws Exception { // do the same action, but now // as a particular subject return null; } }, null); } A keystore is a place to store certain types of credentials, such as X.509 certificates which are used by SSL. A keystore is manipulated by the keytool command. Conventionally, your own private (and associated public keys) are stored in a keystore... file while public keys from others are stored in a truststore... file. We can create private keys for the client by keytool -keystore keystore.client -genkey This will prompt for X.509 information, which assumes that you are an individual working for an organisation Enter keystore password: client What is your first and last name? [Unknown]: Client What is the name of your organizational unit? [Unknown]: IT What is the name of your organization? [Unknown]: Monash What is the name of your City or Locality? [Unknown]: Melbourne What is the name of your State or Province? [Unknown]: Vic What is the two-letter country code for this unit? [Unknown]: AU Is CN=Client, OU=IT, O=Monash, L=Melbourne, ST=Vic, C=AU correct? [no]: yes Enter key password for <mykey> (RETURN if same as keystore password): Similarly, we can set up a keystore for the server keytool -keystore keystore.server -genkey Enter keystore password: server What is your first and last name? [Unknown]: Server What is the name of your organizational unit? [Unknown]: IT What is the name of your organization? [Unknown]: Monash What is the name of your City or Locality? [Unknown]: Melbourne What is the name of your State or Province? [Unknown]: Vic What is the two-letter country code for this unit? [Unknown]: AU Is CN=Server, OU=IT, O=Monash, L=Melbourne, ST=Vic, C=AU correct? [no]: yes Enter key password for <mykey> (RETURN if same as keystore password): We can export the server's public key from the its keystore and import it into the client's truststore under the alias "Server" by keytool -keystore keystore.server -export -file server.cert Enter keystore password: server Certificate stored in file <server.cert> keytool -keystore truststore.client -import -file server.cert -alias Server Enter keystore password: client Owner: CN=Server, OU=IT, O=Monash, L=Melbourne, ST=Vic, C=AU Issuer: CN=Server, OU=IT, O=Monash, L=Melbourne, ST=Vic, C=AU Serial number: 4123f906 Valid from: Thu Aug 19 10:49:10 EST 2004 until: Wed Nov 17 11:49:10 EST 2004 Certificate fingerprints: MD5: 6E:24:70:EB:E2:2C:A0:72:C5:B9:9B:95:72:39:87:B1 SHA1: 2B:AB:0D:80:4F:DF:B8:66:3B:E7:49:66:3D:53:EC:C5:B8:3A:91:5E Trust this certificate? [no]: yes Certificate was added to keystore and similarly we can export the client's public key and import it into the server's truststore under the alias "Client" keytool -keystore keystore.client -export -file client.cert Enter keystore password: client Certificate stored in file <client.cert> keytool -keystore truststore.server -import -file client.cert -alias Client Enter keystore password: server Owner: CN=Client, OU=IT, O=Monash, L=Melbourne, ST=Vic, C=AU Issuer: CN=Client, OU=IT, O=Monash, L=Melbourne, ST=Vic, C=AU Serial number: 4123f88d Valid from: Thu Aug 19 10:47:09 EST 2004 until: Wed Nov 17 11:47:09 EST 2004 Certificate fingerprints: MD5: EA:4A:67:E3:A6:58:2D:F4:52:00:FE:CF:2C:AC:7A:6A SHA1: 8C:68:E3:9C:E8:08:4A:33:F5:12:E4:9D:73:D6:EF:A4:A5:82:B2:79 Trust this certificate? [no]: yes Certificate was added to keystore A server that is prepared to authenticate itself must be able to offer suitable credentials when challenged. For SSL, this would be an X.509 certificate, for Kerberos it would be a Kerberos ticket, etc. If JAAS is used to provide these credentials then it must be able to "login" to gets it authentication information. The server code needs to be modified slightly to get a login context and then login using a principal to get a subject. If this succeeds then it can run the rest of the code as that subject. The changes to the file classifier server are given as static code to execute before creating the server. The security/FileClassifierServerAuth is This login context uses a hard-coded string to specify the name "security.FileClassifierServerAuth" used by JAAS to find information from the JAAS configuration file; this string could better be given in a Jini configuration file in a production environment. A few other pieces need to be put in place in order that this server can authenticate itself The server needs to be run with an additional runtime property. The property java.security.auth.login.config needs to be set to the login configuration file, as in java ... -Djava.security.auth.login.config=ssl-server.login ... The JAAS login file specifies how JAAS is to get its credentials. For example, for SSL it will need a certificate which it can get from a keystore. So for an SSL authenticating server the ssl-server.login could contain The configuration name "security.FileClassifierServerAuth" is the same as the parameter to the LoginContext constructor. The file also specifies the alias to be used in looking up entries (the default is "mykey" if not specified during creation of the keystore), the keystore and a file that contains the password to access this keystore The password file password.server just contains the password we set earlier: "server". This server can be run from the command line java ... security.FileClassiferServerAuth \ config/security/jeri-ssl-minimal.config or from Ant ant run -DrunFile=security.FileClassiferServerAuth \ -Dconfig=config/security/jeri-ssl-minimal.config The server does not need to set any constraints (since it just authenticates itself), so the minimal server configuration file can be used. The client can require that the server have a proof of identity, or that it identifies itself as a particular subject. This is just like asking "Do you have a card that proves you are over eighteen?" versus "Do you have a card that proves you are Joe Bloggs?". The first case ("do you have a credential?") can be specified in the client configuration file by just adding the ServerAuthentication.YES constraint The client is the previous TestFileClassiferProxyPreparer used throughout this chapter. However, although it doesn't look up any certicates it does seem to need a trust store to be specified - a bug? This can be done by adding the property to the runtime -Djavax.net.ssl.trustStore=truststore.client The second case requires specifying which principal(s) the server is required to authenticate as. The most common case is when the client requires a single principal as identity. The ServerMinPrincipal is used for this, with constructors for a single principal or for a set of principals. In order to get an SSL principal, we need to do something like pull it out of a keystore. This involves the steps of: get the users from a keystore and get a single user from this list. The KeyStores class in Jini allows these steps to be done from within a configuration file. The client is still unaltered from TestFileClassifierProxyPreparer. The configuration file is now preparer-auth-server.config Classes such as ServerMinPrincipal can take a set of principals and AND them together: "are you Jan Newmarch AND are you over eighteen AND are you the father of Katy Newmarch?" A client may want to express a set of alternatives such as "do you have a driver's license OR do you have a social security card?" The ConstraintAlternatives class can be used to handle these cases. The same mechanism used for a server to authenticate itself is used by the client. That is, it sets up a login context, logs in and then runs code as a particular subject. The modified code is client.TestFileClassifierAuth Like the server, other pieces need to be in place order that this client can authenticate itself The client needs to be run with an additional runtime property. The property java.security.auth.login.config needs to be set to the login configuration file, as in java ... -Djava.security.auth.login.config=ssl-client.login ... The JAAS login file specifies how JAAS is to get its credentials. For example, for SSL it will need a certificate which it can get from a keystore. So for an SSL authenticating server the ssl-client.login could contain The configuration name "security.TestFileClassifierAuth" is the same as the parameter to the LoginContext constructor. The file also specifies the alias to be used in looking up entries (the default is "mykey" if not specified during creation of the keystore), the keystore and a file that contains the password to access this keystore The password file password.client just contains the password we set earlier: "client". If the server requires the client to authenticate as a particular user then it can be the config.FileClassifierServer. It does not need to have the authentication code itself. It can specify client authentication by the jeri-ssl-auth-client.config configuration file In addition to this, the server needs to be run with a define -Djavax.net.ssl.trustStore=resources/security/truststore.server to locate the truststore file it will use to verify certificates from the client. Standard Java uses policy files to determine what foreign code is allowed to do. This policy is installed when the application starts, so is a static policy mechanism. In Jini 2.0, when a service is discovered, it may wish to ask for a policy to be applied at that time, ie dynamically. Extensions to the basic security model in JDK 1.4 allow this to occur, by permitting dynamic policy setting on class loaders. In order to allow dynamic policy granting, the Java runtime must have the appropriate classes installed and trusted. This is the purpose of the jsk-policy.jar file from the Jini library. As part of the installation process for Jini, you are recommended to install this into the jre/lib/ext directory of your Java distribution. This allows the Java runtime to pick these up as trusted classes when it starts. The runtime needs to be told about these classes. This can be done by using the runtime define -Djava.security.properties=security.properties where security.properties is a file containing the single line saying which Jini class to use for dynamic policies For the client, an array of permissions specifies the permissions it will grant to a proxy. This array is set in the BasicProxyPreparer. The server can set a permission in the BasicILFactory. This permission is used to perform server-side access control on incoming remote calls. Ensuring security on the network is a complex task anyway, and the Jini possibilities of mobile code increases the security risks. This chapter has presented an "end-programmers" view of the new Jini 2.0 security. The architecture behind this is highly configurable, and what has been presented is one set of "plugins" to make it (relatively) easy for the programmer. However, if you want more control over any part of this process, then you can dig further into this architecture and "roll your own" for almost all parts of it. ©right;