The title of this slide was WebObjects and Security because that's what we thought we'd need after the last session, calling security in to manage the Objective-C issues. But I think that actually people are behaving pretty well, and I appreciate that. But obviously there's other kinds of security, such as making sure that the right people can see the right data and the wrong people don't. And for that, we have David Neumann. David? Okay.

Okay, I've got a lot to cover, so if I do this right, I'll talk real fast and hopefully be able to follow or it won't be too confusing. This basic things I'm going to cover include a security concept, some coding techniques, and I created a special kit for this conference that I call the Woe Security Kit, and it includes a bunch of stuff. And in demoing some of the concepts that you can roll your own, I'm also going to be demoing, in effect, aspects of the security kit at the same time. And then I'll be covering some B2B applications.

And security, this is a big word. I heard someone said in an earlier talk, "You know, I want to know about doing security with my application. Can you tell me about making my app, you know, doing security with it?" And, you know, that's a really big thing, and I'm not even going to be able to cover all of it. I'm going to focus on secrecy, which is what most people think of when they think of security, some detail on the concept of integrity, and a little bit, well, I say not covered there, but I mean there's this tiny smidgen on availability.

Okay, so this is sort of the outline of the talk. I'm going to talk about cryptography first, authentication techniques next, and that will be the heart of the thing, access control and enterprise objects, and finally, integrity of transactions. And time permitting, I'm going to get to the fourth bullet. Hopefully I'll be able to get to it.

Okay, cryptography. Originally, I wasn't even going to do the next five slides, but I'm going to go through it anyway just to make sure everyone has a good quickie background primer on the two kinds of cryptography, secret key and public key. Secret key is the kind of stuff that you're probably used to. Public key is the stuff that SSL is based on, among other things.

So the basic problem with a secret key cryptography is you have to have this secret in order to have a secure channel. So you've got to get a secure channel to get a secure channel, and that's a bit of a problem. So that's not a half of it.

Then there's the key distribution aspect of things. Once you've got this secret exchange with your customers, if you're Acme Corporation and you want to encrypt information with your customers, you pretty much have to establish this secure channel through some formal meeting with all of them, and that's a pretty inefficient sort of thing to want to do. So there's this key distribution issue. Now, you could give the same key to everybody, but then that would be very secure.

So let's move on to public key crypto. There is no secure channel problem in theory because there's two pieces to it. The key, the private key that only Acme knows, and the public key that they share, and that is a public artifact. It can be shared in the clear. And it also addresses the key distribution problem because it can be addressed in the clear. Everybody can get the same public key and talk to Acme in a secure fashion.

I say almost because there's two loopholes. The first one is covered by the issue, well, the question is how do you know Acme is the real Acme? And we have certificate authorities like VeriSign, Intra, and so on. We have certificate authorities like VeriSign, Intrust.net, CyberTrust, etc., etc., that you can use as a trusted third party to issue these kinds of public keys in the form of digital certificates. Now, there's other questions here as well I'm not going to be able to really get to in any detail.

What is a secure hash? What is a digital signature? How do you know which CAs to trust? How do you know it is trust VeriSign, for example? How can you tell that you don't have like a forged ID? You just have this information with a public key in it.

How do you know it's a trust? How do you know it's actually from a valid certificate authority? And how can you get the ID to encrypt a message? If you want to send something to Acme, it's an efficient way to get their public key. And I said there's two loopholes, and what's the second public key crypto loophole? I'll cover that one later.

Okay, SSL. We're getting closer to web objects now. This is an implementation of public key crypto on the web. The basics in one slide, if you can summarize SSL in one slide. Acme.com has a digital ID. Your browser checks that the ID is issued by a service. You check that the ID is issued by a CA that it trusts. Your browser encrypts some random secret and sends it to the server. The server uses that secret as a secret key for secret key cryptography. And you're doing secret key cryptography there for.

Now, in using this with web objects, in some instances, if you're the developer and not the system administrator, you're done, man. That's not your problem. If your app can only be accessed over SSL, you just push that whole puppy on the guy managing your Netscape server or IIS or Apache or whatever. But if you have an application where part of it is going to be secure and part of it is going to be insecure via, you know, SSL, then you have to know about some more things.

You have to know how to construct these URLs that are absolute instead of relative, which gets us to the next slide here. Sort of the problem, although it's not a problem per se, a problem in this particular context, but is web objects generates partial URLs. It does not generate absolute.

That way, your application code doesn't have to know about some of these things. Your application code doesn't have to know about some detail about the deployment, that detail being your web server. In code, it would be nice not to have to tell it what your web server is in any fashion.

And with a partial URL, you can do that. It just assumes whatever web server was used to access the application in the first place. But if you're going to force SSL from a non-secure page, you're going to have to create URLs that are full, that have the host name and the secure protocol in there.

So forcing this in web objects is a big problem. And web objects, there's three ways you can do it. There's some private Objective-C API you could use to form the full URLs, and that's documented in this tech info tech note that's online. That's the URL for it. Or you can create a custom WoW hyperlink and WoW form implementation. This is sort of what I've done in the past.

Or there's this clever little redirect technique, and this technique is also documented in the info center. And this method lets you basically use the normal elements. You have to create your own custom hyperlink or WoW form in order to do that. And you can create your own hyperlink or WoW form in order to make it work.

But the one downside of that third bullet is you can't control the granularity of this at the subpage granularity. The second technique is really nice and good for most applications, but if some of your links need to be secure and some need to be insecure, you may need to do the second bullet.

So here's just an example. If you were going to implement your own custom secure hyperlink, here's sort of the ingredients of it. Your secure hyperlink component would contain declaration very much like this. For a WoW generic container, it's got an element of A for anchor. It's got a couple of -- you've probably heard the href binding, which is basically the explicit href that's going to show in the page. You probably have not heard of the action -- excuse me, the invoke action binding. This is a neat way of basically saying for this href, invoke this server-side action. Normally you do that all in one. There's one binding in a WoW hyperlink.

It's action equals some method in your page. And after you've basically got two bindings for that, one that constructs the URL, you want to represent that action. And so this is how that works. And if you want a starting point, take a look at WX hyperlink in the component elements framework. That's in WebObjects examples frameworks. You'll find it in the info center.

And in your implementation of this component, you'd have a custom version of that method I'm calling href. And my simplistic method hardcodes the protocol and the host name and then appends that to the component action URL that you get from the context. And that's it. So it's actually fairly trivial to do. Except now you have to use secure hyperlink everywhere instead of WoW hyperlink. Okay.

So this is security. So it's going to be boring. My demos don't have any flash. There's nothing swirling around. It's just -- well, you'll see. Okay. This is my little test app. This is the application that I've included in the WoW security kit. Which, by the way, will be available at a download at the WWDC download site or whatever. I'll give you the URL for it later.

So it's got a bunch of different things I'm going to be testing here later. But right now we've got this go insecure and go secure. Right now I'm in secure mode. So I'll go insecure. And I'll go secure. Insecure. Secure. You see, you know, Steve has that action with the window, you know. I got this. Yeah.

Okay, that was that. That was demo number one. Okay, now sometimes you might want to encrypt programmatically. And why you'd want to do that, a few occasions, actually maybe a lot. The number of examples I gave there are if you've got some passwords in the database, some personal information, credit card numbers.

Some people I know at a company lost some of those. And the other question is how. This is kind of a sticky issue because there's all these export restrictions and national security agencies such a big tightwad about this and the export thing. So you just can't ship something that has strong cryptography usually. You have to ship something without it and you have to link the other stuff in later. And then you have to pay a fortune to, well, never. Anyway, you've got BSAFE here and JSAFE.

These are commercial crypto libraries. One is C-based, one is Java-based, and they're both from RSA data systems. I suppose these are the big ones, the ones that most people use. I don't know how many people out there use in the commercial space, but there are some free ones, or sort of free. Intel CDSA, I believe, includes some crypto stuff. Microsoft's CryptoLib is free, but it just runs on Win32. I think SS, I don't even know how to pronounce this thing. I think it's SS Lee. Some people say SS Leay, whatever.

Hey, it's for free. You can get it and do some cryptography with it. Now, on the encryption techniques, the one thing that is really simplistic is to explicitly encrypt stuff. But if you have some EOs and you have like a password thing in the enterprise object, you might add a couple accessor methods to it, like encrypted passwords, set encrypted password, and do the encryption and decryption in there. And you might actually add a little state to your object to have a cache so you don't have to keep doing that every time the thing is accessed. That's just one thing that I've seen done.

Now questions I'm not going to be able to answer here. Maybe we can talk about it at the end. Or what key size should you use for this sort of thing? And does my data get less secure as computing power increases? I've kind of got my own opinion about that.

Okay, this is basically the meat of the thing, authentication techniques. Authentication is basically broken into these, I call them like four types of compartments. You've got the logical and the physical. And on the logical part, you have to answer the questions, are you who you claim to be? And if so, do you have access? And then there's the physical piece, the presentation specific and the business policy specific. It turns out it's difficult to make a login panel. You think, well, a login panel is a couple text fields and a button.

It could be easier than that. But there's the questions about when to log in. Where do you go when you log in? There's different ways of logging in, all these different sort of presentation styles. So I've tried to cover some of these. I've tried to cover some of these things in the security kit without tying you down.

But anyway, when to log in. This is one of the questions that gets asked. Maybe you want a WebObject session. You don't even allow the session unless they're logged in, which can be kind of tricky since WebObjects creates a session by default when you access it. So you could allow surfing, like creating a session. You're going to mind your own business through the web app and then try to do something sensitive and then doing an on-demand type of login.

Or maybe you do the on-demand login and then the user re-navigates. You do an on-demand login and you go straight to the page where they wanted to access, which is actually usually the most desirable. And then there's the session timeout. Session time's out and then you want to maybe instead of showing, "Hey, your session timed out.

Great." How about just the login page so you can get right back into where you were leaving off. Okay, and then there's this notion I call access posture. Basically, I've tried to encode a way or you probably have to do this by hand yourself. Where you want to default to deny access. Okay.

Default to deny everything or default to allow everything. Default to allow or deny direct actions. Default to deny or allow privacy. Maybe a page can only be viewed under SSL or maybe you don't want to allow viewing any pages unless they're over SSL, but with certain exceptions for each of those three cases.

Okay. And then these are like the three kinds of -- actually, there's four kinds of ways of gathering credentials. I've listed four there: HTML page, HTTP login panel. By that, I mean that little challenge thing that comes up, and you type. It's actual physical panel instead of a page that your browser raises up. A digital certificate or a cookie.

And there's many different ways to verify credentials. And the top stuff is very presentation-specific. In fact, it's entirely presentation-specific. The ones in the middle are very your company specific. And the WoE off policy framework provides all -- it's not -- it doesn't provide the cookie authentication technique, but it provides the other three.

And it provides some delegation hooks for your custom verification business logic. Now going to the sessionless login, this gets to the one area where it's sort of like availability related. A session can be a kind of a heavyweight thing. So you might not want to create one if you can help it.

Maybe you only want to allow them if the person is allowed to -- has successfully logged in. You also might want to be able to -- with the sessionless login, you can bookmark the login page. It also lets you have -- be able to attempt to log in and not get a session expired. I've had some customers who were kind of complaining to me once. Okay, I created this login page. My customer was there.

They left it up there. They went and got some coffee, came back, logged in, the thing said session expired. I didn't do a damn thing. Why did the session expire? So it'd be kind of nice to have a sessionless login that -- where you could not run into that irritation. And in order to use this, if you're using an HTML page, you should use a wolf form and some direct action. So these are sort of the basic logical things you need to do.

This first sentence is hard to say. I think default and action show up about three or four times in it. Use a direct action action handler as a default action handler. That's -- I've got the code for that in the next slide, but I think that's actually clearer than that.

Anyway, forceweb.js, go to your login page. And you can see that it's a little bit more complicated than the page instead of main. By default we go to main and main may have things which directly or indirectly kick off a session that you don't want. And then when you create your login page, you have to be very careful you don't call session anywhere. So you do that.

You create your login page and it doesn't. And yet sessions are getting created and you're wondering why. And it turns out you've got a component on your page and that component happened to refer to a session which meant the session got created. And then you got rid of all those and go, okay, everything's hunky dory.

And you go, session's still getting created. And that could in fact happen because maybe there's a component action. If there's a woe hyperlink and you bound that action to it and that shows up on the page, well, component actions imply a session. So one will be created for you to put that session ID in and when the page returns. So you have to be really, really careful.

It might not be WebObjects. It might be your code actually. So be really careful about that. Now this is the sort of the code that you can use to sort of implement all this. And this is the code that you can use to sort of implement all this.

And this is the code that you can use to sort of implement all this. And this is the code that you can use to sort of implement all this. And this is the code that you can use to sort of implement all this. And this is the code that you can use to sort of implement all this.

And there's other code involved. But this is sort of what I call the secret handshake type of code. So in your direct action subclass, you'd want to override default action and return login page instead of main. That will take you to the login page instead of the, whatever the main page is. The second point there forces the system, instead of like defaulting to the component action handler when you initially access your app, it will use the direct action action handler which does not create a session.

And that's what we're going to do. And then we're going to do a separate action handler which does not create a session unless you explicitly tell it to. So the combination of those two things will let you have a sessionless login. So let's do a demo of that. Alright, this is HTML, so let's go to the policy editor here. Okay, it's already HTML.

Good. Alright, so I'll go to this. I've got various links here that do various things. This is the private one, so this one needs to be over SSL. This is going to require a login, so I'll just do a login here and fail. I'm going to successfully log in. And there I am. So, I just got a flag that says when I'm logged in and I'm also over secure mode. So, anyway, that was that exciting demo. So, let's move on.

Ok, HTTP challenge panel, now this sounds like it should be really easy to do and unfortunately it's tricky as hell. There's a tech note in the info center that shows you how to do it. And in order to make it work, your well-response object must emit certain statuses and it has to also set a certain header and then you have to look for a certain kind of header when it comes in, oh and then you get all that working and it doesn't work because the web server you're using has an interface that doesn't actually pass the authorization header. And then once you've got all that and you think you're out of the woods, you get this blob of base 64 encoded muck that you have to like walk through.

So it can be a little tricky. The first to get you started, those are the, that's the status you need to set and the header you need to set on the outgoing response to at least force the panel to come up. Then you need to look for a header named authorization on the incoming will request and look at the content of that. And CGI with Netscape at least does not pass that header. Other web servers with CGI may, I'm not sure. NSAPI definitely does and this demo is all happening on NSAPI.

They should be, yes. Yeah. In fact, I actually made them kind of wordy so, you know, you'd be able to maybe treat them as sort of like a mini outline. This is something that could be useful if you're decoding Base64 data. This is just part of the standard JDK, the Base64 decoder object. And once you have a normal character string that you get from that, you can parse the string and get the username and password out of it.

Okay, so I'll show that. Go to HTTP Panel, Submit, and I'll start a new session, one I'm not logged in with. And I'll go to the login required, pops up this little panel. Now, one of the things that's kind of neat there is that this login technique, it's using the exact same business logic to actually do the login, but, you know, it was able to kind of on the fly change the whole way in which credentials were gathered there using that little policy framework thing. So, anyway, more on that later.

Do you need to move on? I don't have one of those little things to throw at that. Okay, logging in without a login panel cookies. I've kind of done this once and regretted it. Because you do this, you stick the username and password in the browser and then this guy who has administration capability decides, "Oh, I'll access this from someone else's computer," and you just left your password in their computer. So, probably not a good idea. Plus, I guess it was recently it came out that if you're an enterprising website, you can pretty much get everyone's cookies if they're using IE. So, maybe that's a feature. . . .

Now, if you're going to log in without a login panel, you could use digital certificates. This is really the ultimate in user security, although it does have a bit of baggage that comes with it. It reverses the role of username and password. By that I mean, basically the SSL protocol proves that you are who you say you are, and then you decide whether you have access, as opposed to the other way around. And obviously it requires SSL to make that work.

Now if you're in a WebObjects application, if you get a digital certificate, it's going to come in on a header called client cert. And once you've got that client cert, it's encoded in this asyn1.blob in Base64 format. Now you could go and walk that and parse it yourself or you could use sun.security.x509 and just use that collection of classes and just create yourself an x509 cert right out of that blob for you. It saves you a bit of time.

And then you might want to validate its status in your code to actually see if the certificate hasn't been revoked. And the security kit includes a wrapper for a framework from ValCert that wraps such a type of status checker. Now there's one little sort of hang up in all this when you use it with WebObjects.

Well, there's two ways you can grant access to digital certificates. You can just leave it all at the web server and configure the web server to trust certain CAs and certain digital certificates issued by those CAs and just be done with it. You know, they pass that test, they're in. If not, they don't get in.

But odds are you might just want to configure it with the CAs you wish to trust. Let the certificate come into your application and then look at the contents of the certificate, who the person is, where they're from, et cetera, et cetera, and then decide whether or not they get access.

And that sounds great except like the slide says, the WebObjects adapter don't actually pass the cert along intact or they don't even pass it at all. So the WoW security kit includes some source code for CGI and NSAPI adapter in binary form. The binaries and the source that pass the certificate correctly and don't even leak.

So, this brings me to that second loophole. Just because you have an unexpired digital ID issued by a trusted CA, does not mean that it's good. It could be revoked. It'd be-- If you-- If your application just trusted a certificate like that, it'd be very analogous to you going to, like, Target or whatever, whipping out your credit card, saying, "Hey look, credit card, it's a visa. Okay, give me $1,000 worth of stuff," and they just did it. Like what? You know, it's a visa card, it's got a hologram, it's good.

Right? Now, they're going to take it, they're going to swipe it through some little device and check whether or not it's actually been stolen and it's hot as hell. So, you probably ought to check the ID and there's two ways of doing that. You can download a certificate revocation list from the certificate authority or you can contact a VA to check the status of the certificate.

Okay, now I'm going to kind of get off into a little bit of la-la land here. I'm going to try and go through these kind of fast. In fact, I should probably skip them, but I think it's important that some of this information is known. It wasn't really known to me six months ago, so let me just kind of run through it.

The way this works with the user is that, you know, that user has, if they have a certificate, they've got a private key, and they unlock that private key with a passphrase. And at first, this struck me as kind of bogus. I mean, we go to all this trouble to have this certificate with this unbelievably encoded long 10,000-bit key, and then I unlock it with FUBAR. You know, just something not right there.

So, but unlike username and password scenario, this passphrase is something you created. It's not shared with anyone. It's just, and it never leaves your computer in theory. It's something just between you and the computer, and only you know it. So it's not quite as bad, but it's still a little weak. And there's this other sort of downside, too. You've got this private key in a file.

So you pretty, a username and password, if you can remember it, you can pretty much take it with you anywhere. But now you have to sort of carry this document with you, and you have to put it on a floppy if you want it to be portable. So typically, these things aren't portable. They just sit on one machine.

And having things in files is a pretty extraordinarily lame way of establishing security. So there's been some things that have been called smart cards. That try to address this, where you put all this information on a smart card. The smart card has a CPU that does all the crypto on it. The private key never leaves the card. So the hacker would have to steal your card in order to impersonate you. And there can be some smart cards that can be attached to devices to accept your passphrase directly.

And for the truly paranoid, that device can be a biometric. So, you know, you could basically log into a website by sticking your smart card into a computer. And then you can put your smart card into a reader, putting your thumb on it, and then you're logged in. So that's pretty good security. Unless someone cut your thumb off. So. Okay, another demo.

Okay, I'm going to close IE here and come back into it because I want to show you the thing prompting for a digital certificate. I'm just going to do a digital certificate login, so I'll go to the Policy Editor here and pick certificate. And I'll go to something that requires a login.

And in this case, my computer is not hooked up to the internet, so I couldn't actually go out to check the status of the certificate. Actually, that was a-- that was actually-- that page is private. Let me change the policy on that page so it isn't private anymore. Let's see, page two, remove.

I think I would have had this set up before I came in here, wouldn't you? So a panel pops up. It asks for your certificate. You pick the one you want. I happen to have three. I'm just going to pick this one and go to it. So I'm in secure mode now. Now I'll go to the Login Required page. It says okay, your certificate was not granted access.

And the user info that you can't read unfortunately says, could not get status response, validation results, response status equals no. So you might have your own policy for this. You might just grant them all or you might do something else. The point is I have a delegate hook that you call. It passes in the certificate and you can do anything you want in that hook to determine what you're going to do. So okay, going back to this.

that append response check will handle that, but if it's a direct action, I mean someone can just type that in there, they don't need a page for that, they can just type that right in their browser and go straight there, so this is the choke point for handling that.

For generating pages, it's append response, for handling direct actions, it's this method, perform action name. It passes in the name of the action you're about to fire, then, you know, the full path to it, like foobar slash action name, and if you put some guardian code in these two places, you can pretty much protect things pretty well.

So this is sort of an example of what code like that might look like. I've got append response, I've got some hypothetical method called should deny page generation, and if you shouldn't, and then you just call super and process as normal, but if you should not, if it's illegal for you to go there because you're not allowed, maybe because you're not logged in, I create a login page and set the content on it, and I get the content by generating a response on the login page there. So there's a lot going on there. I'm going to go ahead and put a link on that line right there in the middle, but that's one way of dynamically popping up a login panel if you're not allowed.

Now, to do on-demand login, this is that thing I talked about where you aren't allowed access to something. Login panel pops up and then you just successfully pass the test and you just immediately go to the place that you want to go instead of having to re-navigate into all this other nonsense.

And the way I recommend doing that is when you create that login page, set the name on the page. Don't create an instance of a component or a page and set the page on that. Because I've actually seen some people doing that and I guess that's fine in most cases, but there can be side effects when you generate a page.

If you're not allowed to go there or even see it, why should you even construct the thing? You might be doing something in Awake or in the constructor that you don't want to do. So if you just pass the page name, in most cases that's going to be lighter weight and more secure anyway. So let's do that.

I'm going to have to change the policy here. I'll go to Panel and let's see, login is required for this. So I'm going to page three. That's the page I want to go to and I'm in. So now if I try to go back and access that again, you know, the panel doesn't come up because the session knows that I'm logged in. So that's that.

Now the Security Kit. What I've got in this thing is a modified WOA adapter as I talked about. I included a security white paper in there, which kind of goes into more detail than the presentation does. It's got this WXAuth Policy Framework, which incorporates all the stuff you've been seeing me play around with here. I've also got a framework that wraps some stuff from a company called, I think it's Silo. They're Swedish.

Maybe it's Silu or whatever, but it's... I made a plug-in. It's a plug-in that'll do a digital signature in your browser. It's got a framework for that. Then there's the Valcert framework that I've wrapped there and created a Java wrapper for it as well. And then the demo app itself, which uses all of the above.

So the things that are in the auth policy thing. I've got the credential gathering that you've seen, hooks for Custom Business Logic. I've got this notion of access posture for pages, actions, and privacy. There's the SSL access toggling support in there, just one method you have to call to do that little toggle between secure and insecure pages. Then there's the sessionless login support and some other stuff.

The easiest way to find out how to use it is just to take a look at the cfn.app that I've created. Now, unfortunately, the only way I was able to really guarantee lockdown of the application was to force you to subclass your component session direct action and application from my abstract superclasses. Sorry about that, but you know.

That's security for you. It's constraining. Policy can be set in code or be a GUI component. That component you saw there is part of the kit. You can drop that on a page and control your policy interactively with that thing. You can get it at this link: Enterprise.apple.com/wwdc2000.

In there, I think you'll find a directory with the name of my session, like 409, I believe. In that, I've got two files. One is the source code stuff with all the frameworks, and the other one is just this big honking blob that has the freebies from CeeLo and Valsert. Let's do a demo of this thing. Actually, you've sort of seen part of it.

But anyway, you kind of see I've got different resources here. I've got a page which--let me just sort of get a new session here. Okay, I got page one which you can access in any case. It's always okay to access page one. Page two used to be private. I'll go and make it private again. Actually, I'll show you how this works.

Page two. Okay, I'll actually go in secure. I'm on a secure link. So if I go--if I come in over a secure link, the thing detects that I did not access this page over SSL and goes, "Whoa, you're not supposed to see this unless this thing got encrypted.

So I'm not even going to send it. I'm going to send you this instead." Okay, and you saw how I was able to like flip that on and off by just adding a page name to a list. That's what I meant by an access posture. So sort of go back to that policy editor.

So I've got these three access postures. One is for page generation. So I'm defaulting to denying all page generation with those exceptions. Page 1, page 2, policy editor, page and main are okay. You can see those without logging in. I've got only one direct action that I'm allowing, the default action.

That's the action that gets called when the page is initially created on session creation. And then there's a should deny all pages not secured. Right now I'm allowing all pages to show up under non-SSL except for those three pages right there. And, you know, there's some other things going on here as well. But, I mean, that's sort of the main part of it. So move on to the next thing.

This guy with the demo thing is having to flip back and forth. He's probably getting pissed. Okay. Access Control. Now this is the notion of, okay, they've gotten into your application. Now what? Did they just get like to walk all over everything and see everything they want? But I think in my experience it's come down to answering two questions.

And it comes down to answering your EOs answering these questions. Given an instance of entity A, can user B see it or, and if so, edit it? And this access depends on the state of both of these things. What kind of EO is being edited and what kind of user is attempting to edit it? If it's administrator, maybe they get to. If it's some other Joe Schmo, maybe they can't.

And this is sort of what I would call the basic access control protocol that your EOs might implement. Can show and can edit, getting passed in a user. I assume everyone who has an EO model who has a commercial application is going to have a user entity. So that's the thing that would get passed in here.

And this might be a sample hierarchy that you'd have that's security oriented. You'd have generic EO which would implement the default access policy. You'd have secured EO which would dictate certain schema because these are EOs that need to be secured as opposed to not shown. So that might have to have certain relationships to other objects to work.

And then I've got product in that little diagram which is an example of a concrete EO. So you'd never have an instance of a generic EO or security EO. You'd only have instances of a concrete subclass. So this is a sample implementation of what generic EO might look like. Both returning true, therefore your default access policies allow everyone to see and edit. And then you have exceptions.

Now for secured EO, this is just again a sample implementation and I assume that anything that inherits from secured EO, that those entities have a 2-1 relationship to a user table called creator and it's got a 2-many relationship to a, also to the user table called owners. So if the user is equal to creator, then it's equal to user table.

So if the user is equal to creator, return true. If the user passed in happens to be one of the people that owns the thing, return true. Else, return false. And you can see my can edit policy says, well if you can see it, you can edit it.

Now you can make this more elaborate but the beauty of about putting this in this abstract superclass called secured EO is that if, you can have a pretty sophisticated policy that all of your enterprise objects implement in one place. And the logic is in the EOs. It's not in the top of the pages asking these questions, deciding what you can see and what you can't see. It's down below. All your pages have to do is know how to ask the question. They don't have to implement the policy.

Now if the policy gets more interesting, you might use this thing called Discretionary Access Control. And if you did, you'd want to add more relationships than the ones I had, like creator, owners, groups, permission. And basically this would mimic how the UNIX file system works. And if you're really anal, like the Department of Defense, you might have Mandatory Access Control. So you've got, instead of permissions, you have these things called security levels. And instead of groups, you have this thing called compartments.

And in addition to just adjusting what you can see and edit, it actually affects more than that. It affects what you can do in terms of inserting information into, in this case, a database. So my example here is to actually implement Mac in WebObjects, you'd have to take advantage of some delegates on the editing context. So if certain compartments--if you're a user, if you're a secret user and you're editing things in the marketing department, you cannot physically edit the web.

So you can't physically edit the web. You can't physically save or insert information into the accounting table that's unclassified, for example, which is totally opposite of what you think on UNIX. I mean, if you're the root user, goddammit, you can write anywhere you want. You know, that's the whole thing about being root.

But in this case, you know, if you are Mr. Super Top Secret, you can't write anything except top secret. So your editing context-- Delegate would make sure that before it actually allowed an insert to happen that certain relationships were set. And if they weren't set, it would basically reject or raise an exception. Getting to integrity, this is the fourth section. Aspects of integrity are data corruption testing, making sure something hasn't been tampered, verifying the origin, and it's implemented using digital signatures and public key cryptography.

And the key thing here is a digital signature. And a digital signature is created by doing something called hashing a message. That's this little thing that takes your message, puts it into something fixed size, and then you use this private key to encrypt that. And that encrypted thing is a test to your message, and that's a digital signature in 100 words or less.

Nonrepudiation. This is this thing that is really great to have in the e-commerce space where you can prove that that jackass actually bought the $10,000 rocking chair. Okay? So... In the physical world, you use ink signatures. In the digital world, you use digital signatures. So business-to-consumer digital signatures. This requires, unfortunately, some client-side stuff. I think this is one reason this hasn't really taken off in the consumer space, because you need all this stuff.

But the clients require a browser plug-in, and example applications would be employee form processing, a brokerage enrollment account, paperless workflow, and authorization. Now, there is one development that's happened here that American Express did. I don't know if everyone realizes it, but you know these blue cards? This is a smart card, right? Now, you've seen the commercial of them twisting it and turning it and pulling it and all the other bullshit. Well, they don't tell anybody.

This is actually a digital certificate on here. It's issued by a company called CyberTrust, which used to be a division of GE and was bought by a CA company called Baltimore out of Ireland. And you really could do cryptography on your system if they ever get around to it. So it's sort of interesting. People don't even realize it. But there is something getting out there. So slowly, I guess, it's getting into the consumer space. Remind me not to leave that there.

So I'm going to do a demo here of a... See, I was going to originally make this whole like elaborate thing. I was going to have all this graphics on here and end up with this ugly thing. But I'm going to log into this guy. And actually this needs to be over SSL, so let's go secure and go back to it.

Okay, so this is like the sort of business plan I had over talking to a friend of mine at lunch. I said, "You know, why don't we have this like website that you access over SSL, these digital signatures, and you digitally sign a confession. And then someone in the Vatican responds to you." Okay? You did something really bad, like, "I like sheep," say, you know? And this is going to load a plugin which has the information I'm about to sign. So I'm going to pick the certificate I'm going to use, enter my passphrase, and sign and send this.

This is basically what the server got. It got the certificate I used to sign it, and this thing at the bottom is just the Base64 encoded signed blob. I have proof that I agreed, I wrote the statement, and that I did what I did. They know, and they can maybe send me an email saying, "You're forgiven." I bring this up because it does get to the point of, "Who do you trust?" I sent this to this website, confession.com website, and I think, "I trust these guys. They have the certificate. It's issued." What I didn't know was that their private key was compromised the other day by another company operated out of the Cayman Islands called extortion.com.

and they have this business of selling information to you for a profit. So you have to check credentials or something like that could happen to you. So anyway, going back to the slides here. Okay, business-to-business digital signatures. Now this is instead of the consumer talking to your WebObjects application, this is two WebObjects applications talking to each other directly or just two non-WebObjects applications or you talking to a non-WebObjects application or them talking to you. And an example of this is basically any kind of EDI message and the classic one among many is the purchase order.

So in WebObjects, there's some infrastructure for this that was added in 4.0. Direct actions are a great way of exposing API to your application on the web over port 80, over HTTP and so forth. And in 4.5, I added a couple of things which makes it even easier. It was very difficult in 4.0 to open--to basically encode talk to remote WebObjects application.

Now if you knew all about socket programming, all the other stuff and hey, you know, real programmers know about sockets but not everybody knows about sockets, okay? And it is a bit cumbersome and stuff sometimes. Now it's very easy in 4.5. I mean you can create a request, encode, send it to a remote website, get a well-response back, encode and do all that. Now the next question is what's the content you put into those things? And the standard that's coming out is XML. So you'll see some, you know, there's XML support in 4.5 for--it's already easy to generate XML.

WebObjects is very good. It's very good at generating any kind of content but what--if you got some from some other source like another WebObjects application or some other random entity, you didn't really have anything to parse it. And the IBM parser that's included, you know, you can use to parse it into meaningful data.

So just a simple quick B2B scenario here. PEO is issued to WidgetCo by Acme Corporation. It creates an XML document. It signs it using Java's sun.security package which includes digital signature stuff. You encrypt this information using WidgetCo's public key so it's nice and private. And you sent--and you send it using the WillMessage API. And then on the other end, WidgetCo receives this PEO from Acme. They decrypt it with their private key. They verify the digital signature is valid. Basically, they'll be doing the simple digital signature test.

They make sure the ID is valid. I mean, someone could issue a purchase order for $10 million with the video equipment and we're just going to take that? You know, you want some credentials or in the physical world, you have a lot of credentials. You have a fax that's signed. But in the digital world, you need to do this mathematically. So, you know, you'd want to check the digital ID on that.

Well, I'll go to that anecdote later. Create a digital receipt. This is what you'd want WidgetCo to do. They could basically take all this information, just tie it up in a bow, right? They've got your signed request. They know that they agree to do it. They get something called a digital timestamp. And they wrap it all up in their digital signature. And then they return this and maybe even store it. And so now they have mathematical proof that you asked for this. And that you agreed to it at this time. So it's a pretty neat thing.

So in summary, we covered some cryptography, a little primer on how it works. And mainly some stuff on SSL and how to do that in a WebObjects application. A bunch of stuff on authentication techniques. Some stuff on access control in enterprise objects. And then integrity of transactions using digital signatures and so forth. So... More information, you've seen this about a billion times. Who to contact: Tony, Ernest, and Q&A. Okay?