 Okay, so we come to know how do we use all of these things in web services? So a very, very, very huge subject that has grown exponentially in the last five or six years. So around 2001, some of these standards started getting introduced. Different entities that introduced them worldwide web consortium W3C, IETF, and an organization called OASIS which stands for I don't recall what. Anybody knows of this? OASIS, organization for the advancement of structured information standards. That is to say basically XML. When you say structured information, I mean XML. So what are the problems between, why can't we use the same old techniques that were used for web applications? Okay, web services introduced some new features. Introduces some new features. Example, interaction with partners with no previously established relationship. So we're talking about, for example, a supply chain. You've got multiple suppliers who will supply you a certain product, for example. Because of the web, you can find suppliers across the world. There is no loyalty that I will always buy. I will always source, for example, I'm buying this thing and I'm selling it in my retail store. Nobody tells me I should always buy it from this guy. If somebody's offering me a better discount, for example, better terms, terms of shipment and so on and so forth, I might just shift loyalties and buy it from somebody else, okay? So a large, the last item, large number of service providers and users in the first place. So my loyalties keep shifting all the time. I don't have a standard buyer like in the old days. I was always buying from this guy for the last 10 years. No. So interaction with partners. Suddenly somebody in Taiwan is willing to sell me this for half the price. Well, I'll just rush there and get it from him so that I can make a greater profit. So interaction with partners with no previously established relationship. I don't know this guy at all in Taiwan. Am I sure I should transact with him? What if he doesn't pay me? What if his goods are not up to the mark, et cetera, et cetera? Program-to-program interaction as opposed to human-to-program interaction. When you were doing an application such as internet banking, it was you on one side and the bank a program on the other side. It was not a human being there. It was a program over there. Now over here you can have several intermediaries and you can actually have programs asserting there and doing the job of human beings. Think of workflow applications, for example. So it could be just programs-to-programs that are talking as opposed to just human-to-program interaction. More dynamic short-term interaction as opposed to static interaction. So some of these interactions can be very dynamic. For example, let us see where that picture is. Something over here. You have, you're interacting. There's a person over there interacting with his TA's travel agent and trying to book tickets to Rio. He's never been to this place before. So it's entirely possible that besides flight tickets, you also need hotel accommodation and you need transportation, ground transportation in the form of a car rental or something. So I would really like if all this was done very, very quickly on the web. Professor Mesh Belor always does this on the web, by the way. I don't know how many of you do it. He always books his tickets and everything. I've got to still learn it from him. He books everything on the web. So that's wonderful in terms of convenience. You don't trouble anybody else. And only that you might be able to also get besides the flight to your tickets hotel accommodation and car rentals, everything in one transaction, one composite transaction. So how do we do this and what's the problem? The problem is I only interact with this travel agent that I know very well. Again, it might be a program over there. It's not a human being. It's a program. But I am a loyal customer to this guy. I've been, you know, this transaction, this travel agent is just in Pabai. So I know him very, very well. I've been interacting with him before, manual interactions. And now he's got a nice website. So I go to the website and I click and I say, I want to go to Rio. So and so date, so and so time of the day, et cetera, et cetera. He buys me the tickets, but then he also offers me these complimentary features out there. I can also book, for example, a hotel because I've never been to the city before. So I don't know what I'm into. But since he knows me and he's got a business relationship with all these chains of hotels, like the Hyatt and the Sheraton and whatnot, he can also give me very good prices on those because if I go and start searching, I'm going to spend half my day trying to find out which is a good hotel and so on. So he sort of, because I'm this platinum customer, he's willing to offer me certain discounts because he knows the hotel chain is his business partner. So he tells me, which of these hotel chains do you want? They're close to this conference that you're going to be attending, et cetera, et cetera. And then also, he can take me to the site for car rentals. Now the thing, the problem over here, so this is a composite kind of web service. I go to the travel agent, but in the process, I've also booked a car rental and hotel, booked my flight ticket plus the car rental plus the hotel. Now the fact of the matter is that this is a momentary kind of transaction, that hotel chain in Rio doesn't know a thing about me, that car rental in Rio doesn't know anything about me. So who am I to them? What am I trusting is the recommendation letter kind of thing from this travel agent. So he's got a business relationship with the airlines, with the hotel, with the car and so on, car rental agency. And he tells them, look, this is my good customer. Please give him decent prices. So there is some kind of a record letter sort of thing that is sent. That thing is done through a standard called SAML. How many of you have heard of SAML? So this is one of the, yes, you've heard of SAML? Okay, great. So this is one of the standards for web services security. SAML stands for security assertion markup language. So basically we've got to figure out some artifact so that when I log into the travel agent, I get my tickets but also there is some information that is sent as part of that transaction. You have to figure out how this is done, through what HTTP kind of artifacts, for example, is it through some hidden field in a form, et cetera, et cetera, through some way, and there are many ways of doing this if you look at the SAML standard, through some way that travel agent is able to send some information to the hotel and that information has to be, of course, integrity protected and so on and so forth, signed by him, saying that don't worry, this guy Bernard, who's trying to reserve tickets and hotels and so on, is a good guy. I know him very well. More importantly, I have already authenticated him using this particular authentication method at this time and this authentication should hold at least for the next 10 minutes, for example. So trust him at least for 10 minutes. After that, I don't know what may happen after 10 days. He may not be a very good customer, et cetera, but at least for the next 10 minutes, please trust him because he's now buying his flight tickets. Please give him good fares for this. Now if he comes to your hotel, he messes around over there, then you can blacklist him the next time. But at least for this particular transaction, give him good fares or good hotel, a good deal on the hotel reservation. So this is one application of web services where you need security. Of course, there are so many examples. In fact, almost anything you think about needs security. Now you might wonder why not use a regular SSL. So we've got wonderful protocols that we've designed so long for so many years. SSL secure socket layer and TLS, its equivalent version. And then IPsec, which is security at the network layer. SSL is at the transport layer. Why not use some of these things? So here are some of the reasons why you can't just do with SSL. SSL is operating at the transport layer. It provides point-to-point security. Now as you have seen over there, there are many intermediaries. There are many points in between yourself and the people you're talking to. So what would happen if you use SSL is that every single message might have to be encrypted, decrypted at each point, and this gives you only point-to-point security. You want end-to-end security. So give me a solution for end-to-end security. More importantly, in a particular document or in a particular message, there may be only parts of the document that need to be encrypted or signed. And as they pass from intermediary to intermediary, different participants might have to sign different pieces of the document. Think of workflow and things like that. So somebody has to sign only this particular piece of the body of the soap message. Somebody else has to sign another XML element over there. Somebody has to sign this and somebody else has to sign the same thing. How can all of this complicated stuff be enabled by SSL? So there are many requirements over here that simply cannot be handled by the very well-known SSL protocol that is used for web applications. So we need something completely different. And SSL doesn't deal really with messages. It doesn't understand what is a message. It operates at the transport layer. So what is the solution to all this? There is a whole suite of standards over here, starting with the XML digital signature. You know now what's a digital signature. XML encryption. There is a standard called WS security. Let us see what this thing does. And the same thing that I just mentioned, security or secure assertion markup language. There is a complementary standard for access control called XACML. And all of these can actually fit together. All of this is pretty new. Like for example, the SAML version 2 has just come out, I think, a year or so ago. And the first version came out in, I think, 2002. So many of these things are still in the process of being developed and so on. Lots of industry input into all of this. Microsoft and IBM bitter rivals have actually teamed up to come up with some of these standards in particular WS sec. So we will take some very quick examples of these. In addition, the suite continues. There is WS policy, actually WS security policy. There's also WS policy which Professor Balloon must have talked about. There's something called WS security policy in addition. Then to handle these keys, some sort of a glorified PKI, which is made possible through some of these things that we see below. XKMS, key management, WS trust, and WS federation. So federation is where you've got multiple business partners and each person is known by a different name within that particular organization. So there are different identities. Each one is full of very rich identities. You might be called something at home and something else in your office, for example, to take a very simple example. So what is your identity? Is it your name? But your name is only understood within your organization. You might have an email address that's understood by somebody else. You might have a pan number or social security number that is understood by some government agency and so on and so forth. So how do we somehow unify all of these identities? So that's where federation comes into the picture. So your federation is a nation and you've got different federal units inside over there which are sort of, in a sense, autonomous but still under some sort of federal or central authority. So that's the idea of WS federation. Okay, we start with the XML digital signature. What this thing provides, as usual, is authentication, integrity and non-repudiation. So you can repudiate your signature. As I said, your signature may only be on a small part of the entire SOAP message. So that's the beauty of all of these standards. You don't have to sign the entire thing. It is very flexible. It can sign one or more items, read elements. So you can sign an entire element. You can sign only the content of an element or a sub-element within the element and so on. So it's very rich in what it supports. So it can sign one or more items within an XML document. It can support multiple signers. So your business partners or your intermediaries along the way can sign. You might need a double signature, sort of you sign and somebody else also signs. You might need two signatures. So two people can sign an element or he can sign another part of the document, et cetera, et cetera. So lots of different combinations over here. You can not only sign part of the document, you can sign a remote object also through a URI. So and sign XML content as well as non-XML content and very rich support for different kinds of digest algorithms, different kinds of signing algorithms and different kinds of canonicalization algorithms. So to start with a signing algorithm could be for example your, how many different signatures you are aware of? How many different signature algorithms exist? SHA is a digest algorithm. So the digest algorithms are your cryptographic hash which could be MD5, SHA1, et cetera, et cetera. Now in terms of signature algorithm somebody asks you how many different signatures, how many different ways do people sign different algorithms for signing? The one that we just talked about is typically, yes. Yeah but what is that signature called? That's called what signature? No, true. So use the private key, et cetera, et cetera. That is a generic statement but that particular signature is called an RSA signature because it uses RSA encryption. Likewise you can have L-Gamma signatures, you can have DSA signatures, Schnorr signatures and a variety of them. So you can specify any of those signing algorithms. SHA signatures, I mean sorry, RSA signatures or for example DSA signatures. DSA stands for digital signature algorithm. It's another standard that has been adopted in some places including the US government. Digest algorithms are already mentioned, SHA1, SHA256, MD5, et cetera. And canonicalization is basically taking the, as I said, it's a fingerprint of the message. Now as you very well know, XML is very liberal. You can put extra spaces and the XML parser is not going to complain. Everybody agrees? So this element tag and so on, if I put an extra space between that tag and the next thing, nothing is going to happen. It's not going to complain and fail. The parser is still going to validate your message. But if I sign that document with an extra space, I'm going to get a completely different digital signature. So I want to convert the document to some sort of a canonical form. So there are algorithms to do that as well and you can specify which one of them you choose. Besides signatures you can do XML encryption as usual for data privacy or confidentiality. So you have, so this standard specifies the different XML elements for example. The different XML elements for encrypted data. So there's a nice XML tree. You can look at the standard. I didn't bring it all up over here because we don't have time. What are the different elements and sub elements in this thing? There's like, for example, cipher data, et cetera, et cetera. You must of course specify the key. So there is provision to actually specify the key. There is a certain element called encrypted key element just like you have encrypted data. How is the data encrypted using some key? So I specify what is that key inside the document itself. So an encrypted key, so encrypted data is one element and encrypted key is another element. There I specify the key. Now what are the different things I can specify? I can say that we've been communicating for the last two years. Let's use this key called X1 which stands for this particular secret that we share. We know what that secret is. I call it X1. You call it X1. X1 is the name of that secret. It's a big key. Another thing is I can encrypt the key using my, using his public key. Correct? So we come up with a so-called session key which is encrypted with that guy's public key. So he and only he can decrypt it. So I can specify whether I want to use this method or that method and so on and so forth in this encrypted key element. There are many, many sub elements and so on, many, many optional elements, optional sub elements, et cetera. And once again, you can encrypt the entire document or just a part of the document. It's a very interesting standard. Please go through it and see. My textbook actually has a full section on XML encryption, has another section on XML signatures. Now what is this WSSEC? So that's the third thing on that list. I'm not going to cover all of them, just three or four. So WSSEC, it defines XML elements that are used to communicate security tokens. So what is this security token? And where do they get placed? How do they get placed? What are the elements for them? Quite confusing, quite complicated. This basically, there is something called a security element in the SOAP header. Okay, so if you want to do things like encryption and sign signing, you have to include certain elements inside this secure. So first you have to introduce the security header and under this header, things like encrypted key and so on will appear. Likewise, the signature element, you specify all of those things. I want to use this method for signing and not that method, say RSA method. I want to use MD5 and not SHA1. All of those things have to be specified, which canonicalization algorithm to be used. All of those are specified inside the security header under different elements and sub elements. A security claim is a statement made about a subject's identity, signing key, etc. And one or more claims are represented by a security token. So basically the standard WSSEC specifies what are the different tokens that can be included in the SOAP header and what is the format for these tokens and so on. And an example of these tokens, one of them is the X509 certificate. So you can include the entire certificate inside. You can include a pointer or a URI saying my certificate is in that particular location. Go and check that. You can include a Kerberos ticket. How many of you are familiar with Kerberos? So it's another protocol for distributed security in a distributed environment. So a Kerberos ticket or a SAML assertion. I told you what is a SAML assertion before, that travel agent of mine tells the other guy, I know this fellow very well. He's a good guy. I authenticated him using a password mechanism. I authenticated him at 5.15 today. And please consider this thing valid for the next 15 minutes. So all of those things can be included inside the security element within the SOAP header. That thing, how to include it, what to include, what are the options, et cetera, are all part of the WSSEC standard. Here is a very, very simple example. User token, user name token. I'm trying to authenticate myself to this other guy. So inside my SOAP message, I include that security header. And one of the sub elements inside security is this user name token. I'm giving an example of a token element. So I'm saying that my name is Shivani and that my password type is password digest. That means it's the digest hash of the password. And the value of that password is all that funny stuff there. And then it's been created at so and so time. I forgot to put a backslash or the slash for the created. So one slash created and the other created. And then this nonce. What is this nonce business? Any guesses? Yeah, I used only once, but why do I want this? Tell me the purpose of it. Convince me that I need this thing. Related to session sort of yes. So every time I choose a different random number, why? Convince me that I should do this. Why I don't dump that nonce away? Very good. To guard against a replay attack. If I'm just sending the hash of my password, what prevents somebody from intercepting that SOAP message and replaying it back two days later? So what do I do? Something clever that nobody else can do. I take my password, concatenate it with this random number, which is a fresh number, and then take the hash of it, just like a Mac. And I send this across. Now nobody can. Well, people can replay it. Okay, but at least there's an element of randomness in it. Very simple. Take the he knows my name. Correct. I put the name over there. He knows my password corresponding to that. He just plugs out the password, concatenates it with the random number, and performs a hash on it. Because I'm sending my random number. Don't forget the nonce is sent. Now ideally speaking, this should have been done slightly differently. And this is what is done in most authentication protocols. What should have been done? Tell me. Because he asked me the question, why did I put the nonce that he said to prevent a replay attack? Then I just thought about it and I said the replay attack is not prevented. Somebody else can take the same nonce and put it over there. So in a real protocol, you might do something slightly different. I'm trying to avoid sending too many messages. That's why I'm doing it this way. In the real protocol, you have a challenge response. That guy will send me a nonce and challenge me to compute the hash of my password concatenated with his nonce. I don't choose a nonce now because an attacker could choose the same nonce that I chose and just send this thing. But at least this is better than doing just the hash of the password. You confuse the attacker at least a little bit, but not completely confusing because he can still replay unfortunately. So this is one example of a security token that is defined in WSSEC. Another security token is to include your certificate. These are called binary security tokens because all of that stuff is actually binary stuff, right? Especially the signature and all that. It makes no sense. It's not really text. So to convert from binary stuff to text you something called base 64. So the encoding type over here is base 64 and all that stuff that you can see is LP9 and so on is actually the content of my certificate. So this is a special kind of token called a binary security token because much of it is actually binary and nontext. But to be able to print it, I converted to using the base 64 coding scheme. So I'll give you two examples of security tokens. One is the simple password, the username token, and now this one is the binary security token which encapsulates your digital certificate. That X509 version 3 is the name of this token, which is the X509 certificate. Yes, yes, yes. Why should I send my digital certificate? Exactly the same reason I told you before. Why should I send my digital certificate to that guy? Is it proof of my identity? Anybody can snatch it and send it and say, what is my digital certificate? How is my digital certificate going to help in any way by sending it? I have signed this certificate. So that's the point. The point is in this SOAP message, I took a part of it. It's very nice how they do it actually. You can take an element inside the body. You can take an element inside the header. You can take a whole bunch of different elements all over the place. Take the digest. It all computes. There are Java APIs. Some of my students are doing this. There are APIs to do this. And it will sign all these different, it will actually take the digest of all of these things, concatenate the whole thing together and sign that entire signature element. So I've signed parts of this document and that guy needs to verify my signature. How does he know it's coming from me? He needs to verify. He needs to know that I've actually signed it. I am a party to this thing, this transaction. And he should verify it. He needs my public key to verify. Where does he get the public key from, the certificate? So that is why I'm also enclosing my certificate inside this message. So that's where I use that binary security token. Okay, so let's conclude with this standard, which is SAML. So a lot of work has been done on this and it's already in its second version. I don't know. The third version might also be out soon. Very, very interesting to see how this whole thing works. So I've been looking at this in some detail. So a basic summary is the following. There are three types of assertions. So it's a basic grammar for writing these assertions. Again, using all XML elements. And it could be inside the SOAP body. Usually they are in the SOAP body, but you can also include them as tokens. So I mentioned in one of the previous slides that these tokens, security tokens include certificates. They include this username, password kind of thing. Kerberos tickets and they also include SAML assertions. And this assertion can be one of three types. It can be authentication information. So an authentication statement or an attribute statement. So let's see some examples and then it could also include authorization statements. So let's look at one simple example of an authentication assertion, authentication statement. So what does it say? It says that this is an assertion which happens to be an authentication statement, not an attribute statement, not an authorization statement. There are three types of statements. It says that I have authenticated this guy. So you need to have the identity of two different parties. The asserting party, the guy who is actually asserting this on your behalf and the so-called subject or principal. I have not included all of those things here. So the asserting party says that it has authenticated the principal using a password mechanism at so and so time, 2008 this month, this time, etc. And some information about the subject in particular, the subject's name is Rajesh and the security domain is IATB, etc., etc. So these are some of the basic elements and sub-elements inside the assertion. So this assertion is inserted into the SOAP body. And there are many, many more elements over here. I'm not showing all of them. So how this whole thing fits together, you can think of WSSEC as being sort of the basis and as we had said before in the previous slide, you want authentication. So let's get that through SAML. You want it integrity. So let's use XML signatures. You want to privacy confidentiality. Let's use XML encryption and you also want authorization and so on. Let's use the SAML profile for that. So one of the things that SAML is most concerned with is something called single sign-on. As I showed you in that example, you authenticate yourself only once to your travel agent who knows you very well and can verify your identity. Thereafter, you don't need to sign-on because the other people anyway don't even know you. So that's an example of single sign-on. And the most compelling example for SAML is single sign-on. Then there are some other things that are used in conjunction with this, like XACML and XKMS. So I won't be touching upon these standards, but XKMS is basically for key management. So that, as you know, is a serious problem. We use PKI for it, but you want something that is more general than PKI. So XKMS is one of those standards. They all fit in very nicely over here. The base is WS Security, which of course is normally supported on SOAP. It can be supported on just HTTP without SOAP also. There are some options for that. And this is the final slide, which shows you how you can use a couple of these together. So this guy has a purchase order, which he signs and he encrypts part of it. He signs another part of it and so on. So you're using XML encryption and XML digital signatures. And this thing all sits inside the both, the SOAP header, which includes the security thing. You use WS Security to figure out what are the different elements to be used, what are the different options and so on, and you send it across. So there are these elements both inside the body and inside the header. You can include the ciphertext and so on inside the body. And all the meta information, the security meta information is in the header. And then you send it across and then this guy looks at XKMS probably to verify your public key and so on. So that's another standard. XKMS, that is key management, XML key management or extended key management service or standard to get your public key and verify your public key. And then he also uses XACML, he uses SAML to look at the assertion and having found out your identity through the SAML assertion, he goes and sees using XACML, what are the different access control, this is the policy basically. So given that your name is so and so thing and you're an MTEK student at IITB, etc., which printers can use for example. So all that is encapsulated in these XACML documents, AC stands for access control. So here's an example where you can use about four or five of these things. And we have students over here who have actually done this and we have a nice example with several intermediaries and so on and so forth. You can actually look at the SOAP headers and see what has been going on along the way. Okay, so with that I conclude my presentation and any questions. Okay, in multiple ways, number one is you can use a SAML assertion as one of the tokens. So you can use it, yeah, you can use it on there. So both need the other. So inside the header, you might have a SAML assertion. In addition, as this SOAP message is going from intermediary, you might want one of those guys to assert, I know this guy and so on and so forth. So please treat him, you know, don't think he's a complete stranger. So you might have a SAML assertion inside the body. You might have a SAML header, you might have a SAML token inside the header. Okay, then the SAML assertion is typically signed by the guy who's asserting. How do you know it's valid in the first place? So you can see how they interact with each other. In the assertion itself, there might be a signature. Correct? I mean, I can assert that your name is so and so, so and so. But who's going to trust me unless I sign it and they know who I am. Correct? So I must enclose the signature as well. Sir, suppose my son and daughter, sir, have a digital signature. Yes. We then wait to build a family tree of digital signatures. These are in SOAP or Genetic Algebra. What do you mean by a family tree of signatures? I have a digital signature. Yeah. My son and daughter also have a digital signature. So similarly, a family tree can be built based on the relation. Either way, we can build a family tree similar to a digital signature. Yeah. When you say tree, you mean something is related to something else. Now, your private key has nothing to do with anybody else's private key, including your family members and so on. This whole thing could be jeopardized. Okay? So when you sign a document, nobody else can sign it on your behalf. Your private key has nothing to do with your spouse's private key or child's private key or anything like that. They're completely different things. Can I use my own algorithm with my own question? Can I use my own algorithm? What algorithm for what? Other than using a digital signature. Okay. Now, one of these algorithms, it turns out that these standards specify a suite of algorithms that can be used for everything, for canonicalization, for signing, for digest, et cetera, et cetera. There's a bunch of different algorithms and you can only choose those at this time. But there is scope for expansion. So they have schema where you can extend, but they don't actually support it. And all of these algorithms are specified by URIs. Show some light on security in IP11, IP4 and IP6. Okay. IPsec is basically intended to work also with IP4. IP6 is the successor to IP4, and there have been a lot of people who are hoping that the world moves to IP6, but so far it hasn't happened. So you can have IPsec just working with IP4, but you can also have it working with IP6. So at this time, there is no imminent change. It doesn't appear at least. I used to think five years ago, even told my students that we are moving very soon to IP version 6 because there was a lot of hype, and then I found that we could just relax for some more time. So as far as IPsec is concerned, this is another protocol which is a highly complicated protocol. It operates at the network layer as opposed to SSL, which operates at the transport layer. It's made up of many sub-protocols. It's a highly complicated protocol to talk about. Basically, you establish some kind of a security association. So there's a protocol to establish a security association analogous to a session in SSL. This session or the security association defines the algorithms that both sides have negotiated to use. For example, I've decided to use triple desks. I've decided to use 128-bit triple desks. I've decided to use, you know, Diffie-Hellman for key exchange, et cetera, et cetera. All of these were negotiated beforehand. So in SSL, this is an SSL handshake protocol. It comes under that. In the case of IPsec, it's called ISA-CAMP and IKE and so on and so forth. It stands for Internet Key Exchange. So it's a highly complicated protocol. SSL is much simpler to understand. And then once you've negotiated these parameters, this entire cryptographic suite, you go ahead and actually encrypt, compute the max and so on at the sender side, verify them at the receiver side. So you could use this also, but as I said before, SSL and IPsec even more so, these things, the abstraction is packets. Their abstraction is transport layer entities, segments and so on and so forth. They don't think in terms of messages. When you give them a message, they don't make any sense of what those things mean. You need something that understands what those elements are. That is the reason you go to these WS6 standards. These things can be more fine-grained. They can understand and say, the user wants only this part of your message to be encrypted using this algorithm. He wants this part plus that part to be signed. He wants the intermediary to sign this part and so on. How do you convey that using SSL and IPsec? There's just no way you can do it.