The title of this slide was Web Objects 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 at the same time, so. 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, I want to know about, you know, 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 got to get a secure channel to get a secure channel and that's a bit of a problem. So, but 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 like 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, you know, 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 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, Entrust.net, CyberTrust, et cetera, et cetera, 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 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 WebObjects 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 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 WebObjects, in some instances, if you're the developer and not the system administrator, you're done, man, you know, that's not your problem. You know, if it's-- 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 WebObjects generates partial URLs. It does not generate absolute.

That way your application code doesn't have to know about some detail about the deployment, that detail being your web server. In code, it'd 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 WebObjects, 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 hyperlinkable form in order to make it work. But the one downside to 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 a declaration very much like this. For a Wojnare 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 whole hyperlink. It's action equals some method in your page.

But here you 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 and 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 hard codes 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 wx, instead of wo hyperlink. Okay, so this is, this is security so it's gonna 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 Woe 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. uh... you see i steve has that action with the window you know i got this 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 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 another question is how. This is kind of a sticky issue because, you know, there's all these export restrictions. National Security Agency is such a big tightwad about this and the export thing. So, you know, you just can't ship something that has strong cryptography usually. You have to, you know, 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 B-Safe here and J-Safe. 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 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 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 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 password, 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 to 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, how could it 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 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, but 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. 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. Or 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 know, you want to maybe instead of showing, hey, your session timed out, great. How about just the login page? You know, 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 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 an 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 of what is 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 and not get a session expired. I've had some customers who are 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 things that session expired. I didn't do a damn thing. Why did the session expire?" So, it'd be kind of nice to have a session with login that-- or you could not run into that irritation. And in order to use this, if using an HTML page, it's used 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, force web objects go to your login page instead of main. By default we go to main and main may have things which indirectly or-- 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. 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 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.

All right, this is HTML, so let's go to the policy editor here. Okay, it's already HTML, good. All right, 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.

successfully log in and there we go. So, 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. Ah. Okay, 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 woe 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 then 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 base64 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 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. 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 when 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 is-- 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.

Okay, now if you're in a WebObjects application, if you get a digital certificate, it's going to come in on a header called the client cert. And once you've got that client cert, it's encoded in this ASIN1.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, just create yourself an X.509 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 this cert along intact or they don't even pass it at all. So the Woe 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.

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 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? No, 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 the VA to check the status of the certificate.

Okay, now I'm going to kind of get off into a little bit of a 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. So 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 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 gonna close IE here and come back into it because I want to, I'm gonna show you like the thing prompting for a digital certificate. I'm just gonna 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. Well, 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.

Okay, now blocking access to your app. This can be a little tricky because someone might add a direct action. It's actually possible to override page with name and like maybe have something that says, "Well, if this form value is there, we'll just go to this page." I mean there's lots of different ways of coding things that maybe you wrote something and after the fact someone added a direct action or added this sort of hack in there that was meant to do something but sort of defeated your security policy. But if you override append response and that page is a component, you can basically catch this sort of stuff to make sure that a certain test is always okay before you allow that page to be generated. Now that's for a--well, that's for generating a component. That does not cover invoking a direct action. It's very hard to invoke the component action unless you have a session. So if it's okay to see the hyperlink, it's probably okay to execute it. But it might not be okay to go to where that thing takes you. Maybe three of the four different pages it might take you to would be okay, but the fourth one might require you to log in.

That append to 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 to response. For handling direct actions, it's this method, perform action named. It passes in the name of the action you're about to fire.

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 a pender response. I've got some hypothetical method called should deny page generation. And if you shouldn't, 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 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 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. Log in 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, the panel doesn't come up because the session knows that I'm logged in. So that's that. Okay.

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 WX auth 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. I made a plug-in. It's a plug-in that will 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 off 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. And 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 guarantee lockdown of the application was to force you to subclass your component session direct action and application from my abstract superclasses. So, 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. And you can get it at this link, enterprise.apple.com/wwdc2000. And in there I think you'll find a directory with the name of my session, like 409 I believe. And then in that I've got two files. One is just the source code stuff with all the frameworks. And the other one is just this big honking blob that has the freebies from CLO and Valsert. So 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. So page two.

and I'll go, 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 gonna send it, I'm gonna 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 one, page two, 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. Okay.

This guy with the demo thing is having to flip back and forth. He's probably getting pissed. OK. Access control. Now this is the notion of, OK, they've gotten into your application. Now what? Did they just get 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 your EOs answering these questions. Given an instance of entity A, can user B see it? 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, you know, 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, you know, 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 a secured 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, 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 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 a set 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 the-- 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 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, God damn it, 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, you know, delegate would make sure that before it actually allowed an insert to happen that, you know, certain relationships were set. And if they weren't set it would, you know, basically reject or raise an exception. So 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 just a 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. Okay. Non-repudiation.

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 -- So, yeah. So, yeah. 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 yeah, 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 or the 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, like, 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, 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-- see, I was going to originally make this whole elaborate thing. I was going to have all this graphics on here, ended 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. OK, so this was 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 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? So, You did something really bad, like, I like sheep, say.

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. And 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 assigned blob. So, you know, I have proof that I agreed, I wrote the statement, and that I did what I did. And so, you know, they know, and they can maybe send me an email saying, well, you know, you're forgiven if you, whatever. Now, I bring this up because it does get to the point of who do you trust. Now, I sent this to this website, you know, confession.com website, And I think, you know, I trust these guys. They have the certificate, it's issued. What I didn't know was that their private queue was compromised the other day by another company operated out of the Cayman Islands called extortion.com. Okay?

And they have this business of selling information to you for a profit. So, you know, 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. It was added in 4.0. Direct actions can-- 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, 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, know about 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. It's generating any kind of content, but 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 send it using the WoMessage API. And then on the other end, WidgetCo receives this PO from Acme. They decrypt it with their private key. They verify the digital signature is valid, basically 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 dollars for 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 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 and authentication techniques. Some stuff on access control and 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.