This is my great little announcement. We got lost there. MRJ225 is done. For those of you still working with that, it should be available early next week, sometime next week. So we're going to talk about security features on OS X for Java. And specifically we got a couple of questions we want to answer today. And These are questions we've seen on Java dev through DTS.

and I will be talking about this in a few informal conversations as well. First of all, is there any difference between what Apple did as far as Java security is concerned and what Sun did on Windows and Solaris? Second of all, will my signed applet work on OS X? And last of all, we don't integrate with Internet Explorer like we did on 9. So how do you get a secure connection? We'll talk about all these things today.

And specific, what you're going to learn about, I'm going to give you an introduction to Java 2 Security Model plus the very few OS X specific details that there are about it. We're going to talk about how to sign JAR files so we work with Internet Explorer on OS X and the Windows version of Netscape. And finally, how to make a secure connection without Internet Explorer. That includes in your application. And finally, I'll give you some tips for how to debug security problems in your code if you ever get an exception that you don't know how to deal with.

First of all, we have a little bit of news as far as the security management on Java and OS X works. The security architecture is completely identical to other platforms. We've made no changes, there are no compromises, there are no things you have to leave out to get your security related code working on OS X.

There's no support for extra features such as JAR signing, JAR caching, or any of those other things in the Applet Launcher or the Command Line Applet Viewer. We'll talk about why that is, and that's mainly because we want to keep those two tools, Applet Launcher and Applet Viewer, as close to the baseline Applet Viewer that's available on all platforms.

The signed apple support is the same as that which you get in MRJ. And we'll talk about exactly what that means. But what it means is that if you sign an apple in MRJ, it will continue to work in OS X. So let's talk a little bit about the old 1.1X security model and how the way things used to work.

First of all, security was an all or nothing proposition. You could either sign your jar or your application had full access or it had no access at all. Now this is good or bad depending on your point of view. The sandbox restrictions on an applet were just way too limiting for real works, particularly in a corporate environment.

If you deliver your code as an applet and you want to be able to write to the user's hard drive, for example, you had to sign the applet, you had to do a whole lot of--jump through a lot of hoops just to do something pretty basic in an environment that you control.

Security checks were not easily accessible, and by that we mean that if you wanted to add a new permission, you wanted to add something new to what your code could do, it was really a pain in the butt to do. You had to write your own, a whole new security manager, you had to, um, You know, carefully construct it so that your code knew about that security manager.

Just a lot of work that really shouldn't have been necessary. A locally installed apple is too easily trusted. If I download an apple to my hard drive, there's nothing that says that apple could wipe out my drive just as easily as an application could. So the new model doesn't assume that there's trusted code.

Security managers are too easily broken. And in 1.1, very often security was determined by the current stack depth. And if you make a change somewhere in your code that relies on that stack depth, that changes that, you've suddenly broken your security model. That's really more fragile than it really ought to be.

So going forward, we have the new Java 2 security model. It's a policy-based architecture. I'll talk a little bit about what policy-based means in a minute. You get a collection of permissions specified for a particular code base. And we'll see examples of that in the system-wide Java policy.

Code is granted permission to perform actions based on where it came from. So what you do is you can specify a particular applet or particular application, give it different abilities than you would any other piece of code on your system, and give it different abilities than any other application or Java application.

Finally, no code is trusted by default regardless of location. This is probably the biggest change between Java 2 and Java 1.1. Just because you put it on your hard drive doesn't mean it's automatically trusted. If you put your jar in /lib/ext, it is fully trusted, but that's the only location.

So here's what a policy file entry looks like. And what you'll see is, We have a grant and the sign-by and a code base. And the signer name, as you see, you know, sign-by signer name are both in the grant and for the particular permission. The signer names are aliases that come out of your key store. So if you import some certificates and you want to associate those certificates with particular permissions, that's how you make the linkage.

And another thing I want to point out is we have a permission, permission class name, target name, and action. Target name and action can be thought of as arguments, if you will, to the permission. So for example, you'll have something called a property permission. And the target name is the name of the property that you want to allow access to, and the action is what the user can do to it. Or the code, I should say, can do to that property. It can read it or write it, for example. Okay, if we go to first demo machine here, I'm going to show you what Java.policy looks like on the default system. I'm sorry, the system-wide policy.

If you take a look here, we see that here's a list of, in the first section we see this grant with no arguments to it. That means that any code has these permissions assigned to it. And in particular, Any code is allowed to listen to a socket above 1024 or above. We have this list of property permissions that you're allowed to get at. Java.version, line.separator, things like that.

And down here at the end, We have the Apple specific properties, in particular MRJ.version. And we think it's important that you still be able to know what version of MRJ you're looking at. And finally the last one is com.apple Mac OS.uscreenMenubar. And this is used in Swing to get the menu bar to appear where you want it to appear, at the top of the screen.

I believe that, I can't remember right now exactly. I think by default it's false. But the important thing is that you can set it to where you want it and there won't be any issues. Now, if your code is cross platform and you do set either of those last two properties, you may get a security exception on another system.

That's not a big deal. All you have to do is wrap that set property call with the try catch block and catch the security exception that comes back. And, you know, you just know if it's a security exception for that particular property, big deal. Go on and continue on in your code. So these are some examples of permissions and what they look like. You can create your own permissions, we won't get into that in this session.

But, uh, you

So there are a number of ways you establish the policy on OS X. You can do it in one of three ways. Actually not one, you can do it any of these three ways in any combination. There's a system-wide policy which I just showed you in the last demo there. And that's stored in the Java home directory which is /library/java/home. And then you continue on through libsecurity/java.policy. That's where that file lives.

You can set it on a per user basis. In your home directory if you create a file called .java.policy, put any number of permissions, those will be added on to the default system-wide set. And finally you can set it on a per application basis and you can bundle a policy spec inside your Java app. We'll show that in a little bit how you would go about doing that.

This is important. Policy files do not supersede each other. They're always additive. So if I put things in my .java.policy, they don't-- I suppose it's possible to get like contradictory permissions, but they would just add together. So if something in the default policy only allows you read access, you could theoretically add on a write access and stomp over everything.

So you have to watch what you're doing. So as an example, we're going to look at GENIE. We took a lot of heat because GENIE didn't work in, which is a, GENIE is a distributed environment and it didn't work, it didn't work at all in the public beta. It does work in GM.

I believe it works very well. We've gotten good feedback about that. So we've got two applications, one that wraps up the basic providers and another one that's the simple service browser. The browser needs its own policy file and there are a number of additional permissions that are needed for that to run. We can do everything in MRJ App Builder. And if we head back over to the demo machine, I'll show you how we do that.

So, here's the Genie services application. Just show how that's running there. Here we have MRJ App Builder. And what I've done is I've set up The main class here and the genie examples, just like you do in and any other MRJ app builder app. If you look over here on the Java properties page, you'll see down here I've specified java.security.policy.

java.security.policy and then the name of the policy file. And one thing to note is actually pretty important in this. If you notice that the class pass says content/resources/java. But the java.property, since the security policy property is geniebrowser.policy, so there's no additional path information. When you bundle it, all the jars and the policies will all be together in one directory. And the way that we load the class is it's not necessary to specify that extra path information. And to show you briefly what that policy file looks like, I'll open it up here.

Okay. And here I've granted on a global basis the additional ability to connect and accept connections on local host, or actually to any server, that's what the star means. And again, I can connect to anybody's web server on port 80. And down here I have the Genie specific properties, and in specific I've granted the ability to connect and accept on the multicast ports, and I've also got the permission to look at the discovery, to use the discovery permission properties.

When I do that, I can bundle everything up with MRJ App Builder, and I've already done that for you here. If we cross our fingers, the browser is going to identify all the services running on this machine. I say cross your fingers because as those of you who have worked with networking know, you need to specify a host name. We don't have DNS set up for these guys. So hopefully this will show up something.

Look at that. It did find it. Great. Yay. So there you go. Genie's up and running and if that's something you're interested in, go ahead and 10 is a great platform for developing for it. So let's go back to the slides please. Why should you care? This is new stuff to learn.

What we're going to learn today is not going to be enough to completely learn everything there is to learn about security, so why should you take the extra effort? Policy files make sense when you have control over the environment. If you're in a corporate setting, you've got your own machines that you have control over, where you can set the environment to your liking, then you should consider using a policy file instead of going to the extra hassle of signing your application or signing your code.

In-house apps, special purpose networking such as GENIE as I showed before, intranet applets. If you deliver your code with an applet, instead of going through the trouble of signing it, you can just say, you know, this applet has full permissions or this applet has permission to read and write files off the disk. What if you can't control it? Say you want to send out something that's available to everybody, you want to put it out on the internet proper. If that's what you're going to do, then you need to use a sign jar file.

We're going to talk about signed JAR file support on OS X. It's available in the OS X embedded Java that's in Internet Explorer. That's the only place it's available. provides that you'll get a pop-up dialog to let the user validate the signer. I will see a demo of that in a few minutes.

It will continue to support jar files that were signed for MRJ 2.2 or .x. That's the old DSA with the identity object. Those things continue to work. With some extra setup work, we will support RSA signed applets. We'll talk about what that means here on the next slide. And if your certificate is based on a VeriSign or Thoughts certificate, that will also work on OS X. You'll get identical support to what you get on Internet Explorer or Navigator.

So what do I mean by a little bit of extra work? Well, there's two things you could do. You can install the Java Secure Sockets Extension 102. That gives you the RSA provider that you need to read and understand the RSA signature and to do the signing for that matter. Or you could copy sunrsasign.jar from a Windows installation from the JRE. That's a pure Java file. It'll just come over and work just fine on 10.

Signed JAR files get full execution permission, and using the lingo of what we've been talking about for Java 2 security, that's the equivalent of Java.security.all permission. And as far as what used to work in MRJ, that's, you get the same behavior that you would have had, that you have when you sign an applet app, when you sign a JAR file on MRJ.

You can use either Java 2's code signing tools from the command line, or you can use the Netscape signing tools if that's something you've done in the past. There's currently no control panel, so to speak, for the management of certificates. Apple's got a lot of good technologies for managing certificates and keys and things like that now, and we're going to be looking at integrating those in the future. No promises, we need to think about the right way to handle this, but we're not going to do just a simple straight port of what you saw on Windows with the plug-in in particular.

I'd like to bring up Ted who's going to show you how to do JAR signing on OS X. Good morning. Happy Friday. So, let's clean this up a little bit. How many of you have signed applets on MRJ? Yeah, that was fun, huh? So, Mac OS X is much easier. You look at the books for UNIX, and it's the same thing.

I'm going to start out with the key store. Create the key store. Let me remove one. Okay, great. There's none in there. And let me just type this in right now. We're going to generate the key store. The key store is where your certificates are stored. So use the key tool. And what we're going to do is generate a key. And we're going to use the alias.

So this goes through and it'll ask you for your default key store password. And for this, I'm just going to use key store PSWD. I wouldn't recommend that for most actual secure environments. It'll ask for your name. This whole thing, it's going through when you're generating a certificate.

The certificate carries with it the information about who you are and all that. So I'll go

California, and that's US. Yes, that's all correct. It takes a few seconds to do this. It's generating large numbers and, uh,

generate a simple hello world applet that I changed to actually Get the user directory, which is normally not allowed of applets.

Let's see, let's bring that actually up.

For some reason, Project Builder isn't liking me. So let's go ahead and just quit Project Builder.

I have a shell script that goes ahead, signs the jar, the alias MOV and the key store password. I have it set up also so that if MOV has a separate password you can add that to the end and it will pass that all in to the jar signing tool. So that makes it much easier than the old MRJ signing process. So right now it's going through.

and I'll just show you really quick bringing this up in IE. Now for this you're going to need the new IE that came out on software update. You also need to install the Java Secure Socket Extension. But once you do that, you

So you see it's a lot easier than it used to be. And hopefully we get less questions about how to do this now. Let's talk a little bit about how you go about debugging problems with security on OS X.

You can find out why you're getting security exceptions. I still run into this all the time. When I was doing all my demos for this talk, I would get things like, "Oh, you don't have this property permission." I'd say, "Well, what do you mean? "I just put it in the policy file. "What do you mean I don't have permission?" So I pull my hair out for a little bit. And then I set the property Java.security.debug.

And in specific, well, that will tell you how to get all the available options. But the one I used for--to debug the problems with my demos is I set equal to policy. And the cool thing about that is that it will go through every policy that's currently defined for your current application on the user level and at the system level and will dump all the policies currently in effect. So you can see what permissions are set and, you know, what Java thinks that the permissions currently are.

Okay, a good thing to check is debug equal access and that will show you all the property check, the permission checks that are going on through your code. And if you open up the console window, well, if you're running an MRJ app builder or project builder build application, go to the console and you'll be able to see all these things dumped out. If you're running a command line app, it will just spew out on the terminal window. I know that this is thoroughly documented anywhere, but if you start with DebugEagle's help, you'll get the whole list of options that are available to you.

Scott Kovatch, Ted Jucevic It's also possible to use the Java 2 security features to test your signed applet even before you go to the effort of signing it. So you're basing it on a commercial-based security and it takes a little bit of time to get that certificate. That doesn't stop you from doing your work.

created a file called thatjava.policy in your home directory. Now this will set it on the user basis again. and add this entry: Grant the code base and the path to your JAR file, permission java.security.allpermission. You'll effectively have the same thing as when you do sign your applet. That's the exact same permission that you're going to get when the user accepts your certificate.

You'll be able to see these in the slides later on in the video. So--and I've also posted this to Java Dev, so if you search around the archives, you'll find this as well. Okay, let's switch gears now and we'll talk about how to do secure connections in MRJ, or talk about secure connections in general. And first let's talk about what you had available to you in MRJ. In MRJ you could only make a secure connection that was based around a URL connection. And even then, you can only do it inside of IE5. And even then, it was buggy.

makes secure connections on OS X using the Java Secure Socket Extension. That's a pure Java implementation of SSL v3. Also supports TLS, which is the more open standard of SSL. Go to java.sun.com/products/jsSE. You'll get all the information you need on how to download it, how to install it. You're basically copying three jars over to your /lib/ext directory and modifying a security file. You can also bundle it into your application. You know, they're just JAR files. You can, you know, attach it on your application without any intervention on the user's part.

The JSSE is what's called a non-commercial reference implementation, which means it works, works well enough as far as Sun's concerned, but it doesn't have a full-blown set of documentation, support, and all the goodies that come along with a real product. The main purpose of JSSE is to establish the API that will be used going forward for secure sockets. So if you write to the API that comes along with this package, you'll be good for future versions that may be better or third-party solutions that will be available, hopefully, based on this API.

Pay attention to what you download. The US and Canada version will allow third parties to write their own RSA implementations and plug those into the JSSE architecture. The international version has the same level of The same strength of encryption. I believe they both have 128 bit encryption. The international version will not allow you to plug in somebody else's RSA implementation, for example. You can only use what Sun will ever provide.

Okay, I want to briefly show you an example of an application that's bundled in SSL and how it would work. And that's something called SecureFTP. You can get this from www.glub.com. and unfortunately due to some networking problems, I'm not going to be able to show you how to make a, how to do an actual secure FTP. They're also going to be in the future making a little wrapper so you can make a secure FTP server out of your default FTP server that's built into OS X.

As you can see, this is actually a pretty good looking Aqua application. Got some internal frames.

So to show you what you can do with it, you can specify-- You know, where you want to go to, username and password. Over here you can set whether you're going to use SSL or not use a secure connection.

Passive FTP encrypt what you're getting if you need a proxy to do the actual communication. This actually ends up being a less than interesting demonstration, but it is a good example of how you can use SSL in your application to

So, if we go back to the slides, we'll actually talk about how you can do this in your code now.

So what can you do with JSSE? You can create an HTTPS based URL connection, the same way you do now. It's almost identical. There's like one or two extra steps that you need to do. You can create a secure connection at the socket API level. So you can get back a socket that's got a secure connection backing it and talk to it just the same way as you would a plain socket. And again, once you have that socket or URL connection, you talk to it exactly the same way as you did now.

How do you use it? Well, there's a couple ways you can do it. There's three jars that you bundle into your application. I'm going to talk about the case where you bundle the jars in with your app because I think that's going to be the most common use of this package.

Okay, what you need to do next is in the first line of your code or near the beginning of your code, you want to register the SSL provider with the security system. And the way you see to do that is you create an instance of that big, long, ugly package name and create the SSL provider and register it with add provider.

Now what you do next depends on what you're going to try to accomplish with JSSE. For an HTTPS connection, first thing you have to do is define this property, java.protocol.handler.pkgs. And what this will do is it will add that handler package to the search path of the, add it to the search path when we look up a URL connection.

You can either do this on the command line, if you're just writing a command line app. You can set it in your app's property file with MRJ App Builder, or you can set it explicitly with set property in your code. Before I continue on Secure Sockets, I'm going to show you some code that does that. Go to the demo machine here. And, let's see, we had to quit Project Builder, so I'll open it up again.

Okay, so we take a look here and we have a very, I've written a very, very simple application that's going to fetch the home page from, from Amazon.com, which supports secure connections. And there you see the URL I'm using to do it. If you look down here, this do the fetch method is the actual interesting piece of code that's doing all the work.

If you didn't know that this was an SSL demonstration, that could be any, you know, that's very standard URL connection code. We'll do a, you know, open the stream, get the input stream, and we're going to just count how many lines we get back from it. However, if you look up here, Here's that line where I do the add provider that I mentioned before. And here's where I set the property that says to look in the SSL package for the protocol handler.

And instead of spewing out all the lines that we get back, I'm going to run this and I'm going to show you Some of the features of JSSE, or I'm sorry, one of the characteristics of it, it is running, it looks like we're hung, but that's because when JSSE starts up for the first time in your app it's spending some time generating keys and you know, building up a, you know, working with secure random.

The first thing I've done in this code is I actually do a fetch twice. And there you see we've got some results. So the first time it took, what is that, about 18.4 seconds to fetch 3500 lines of code. And the second time it took 1.6. So the first time you use a connection, it's going to be kind of slow, but after that you get pretty good performance out of it.

So, the secret to HTTPS connections are these two lines right here when you install JSSE. Okay, let's go back to the slides. Alright, now we'll talk about the other case, which is the Secure Socket case. Very similar to a plain socket, but again, with just a few extra steps to get your code to use a secure connection. You need to get an instance of the SSL socket factory. The JSSE introduces a new factory method of obtaining sockets, and the default one that comes with it will generate secure sockets. You ask the factory to create an SSL socket to a specific host.

And at that point, you've got now, you've basically got a socket, a Java net socket, and you can talk to it just as you would any other socket. You can get an input or output stream on the socket and just start pumping data in or out from it. Oh. So let's again go back to the demo machine.

I'm going to get the default SSL socket factory, and when you import javax.net.ssl.star, that's where you'll get the SSL factory. I ask you to create a socket to Amazon.com on the secure port of 443. And you might want to read these comments which talks about some of the problems that, you know, if you run into an SSL error along the way, you want to look at printrider.checkerror and that's how you'll get back the error that was generated. Next I call Socket.StartHandshake. This is a Let's see. I think the SSL socket will do it by default, but you can do it manually because that way you'll be able to see the IO exceptions that happen.

And once I've got that socket, from this point on, I've basically got ordinary socket code. And once again, it's almost identical to using an ordinary socket. So let's run that and I'll show you what happens here. Again, we're going to have a little bit of startup time, but what this is going to do is make a connection to Amazon.com and report back all the headers that we get back in response to it.

and I actually found it and we got a cookie back I think. And we actually see that it was an HTTPS connection. So, there you go. It's very easy to do this stuff. I have to admit the first time I looked at that I thought, "Oh, it can't be that easy." But it actually is. and I don't claim to be an SSL expert. I don't know the guts of its internal implementation or anything like that, but I don't have to, which I think is a good thing.

Okay, let's go back to the slides. Here are some resources for JSSE. I'll give you a chance to write all these down. The best place to start is the JSSE homepage, java.sun.com/products/jsse. And there was an excellent article earlier this year in Dr. Dobbs about using JSSE, and in particular, there was a good discussion about generating certificates that you can use with a JSSE to create a server that will, you know, create a server that will, you know, You can be a server recipient of an SSL connection, not just a client of an SSL session. and that's actually a very good article about how to do the housekeeping to get that to happen.

We can go back later on if you want to, you know, if you haven't written this down or you can look at it in the slides in a little bit. So what's next? I would recommend that if security is something that's in Java, that's something that's important to you, I would go out and get a book on the topic. Sun has published a really good book on the security architecture. If you look on Amazon.com, you'll find at least 10 books now on Java security.

I would get one and read it and learn about how to write your own properties, how to work with security architecture. Install JSSE if you haven't done so already. That'll get you the RSA provider that you need. And it's available right now and you can start figuring out how to use it. But before you do any of that, we've got the Java feedback forum right after this in J1. So please come to that if you've got any questions and give us feedback on all the great sessions we've had this year. If you've got any questions, Alan. See Alan.