|
As Web Services developed, people who actually needed to implement Web Services quickly noticed the lack of security present in the standard and released software. At first, many believed that security was already in place because the SOAP standard utilized a port that was already available through the firewall. However, if you consider the information that you move around on the Internet such as banking or credit card information, you realize security is necessary for the transmitted data in case of interception.
There is also a need for security in XML beyond SOAP. As XML becomes a standard way to represent data, there is a need to protect the data in the documents and ensure the documents come from the expected source. XML Encryption and XML Signature solve this problem by providing a means to accomplish these goals.
As of this writing, it seems that the Web Services community is still scrambling to create standards for software developers to follow in their implementations. The Apache Group developed an XML encryption library, but they admit that it doesn’t really follow any standard. Microsoft, in the Fall of 2002, released their “Web Service Development Kit,” which adheres to the current standards for XML encryption and signatures put out by the World Wide Web Consortium (W3C).
XML encryption involves taking the contents of elements within the XML document and encrypting them so the contents are unusable to someone who doesn’t have the decryption key. Consider the following XML document from Chapter 2.
<?xml version="1.0" ?> <BOOK> <TITLE>Cross Platform Web Services</TITLE> <PAGECOUNT>4000</PAGECOUNT> <AUTHOR>Brian Hochgurtel</AUTHOR> <PUBLISHER>Charles River Media</PUBLISHER> </BOOK>
There really isn’t anything critical in the document, but if you add some more personal information, such as Social Security Number, that definitely needs to be encrypted. XML encryption involves adding elements that have encoding information that is generated by software running in the application that creates the XML. The encrypted information then looks like the following.
<?xml version="1.0" ?> <BOOK> <TITLE>Cross Platform Web Services</TITLE> <PAGECOUNT>4000</PAGECOUNT> <AUTHOR>Brian Hochgurtel</AUTHOR> <PUBLISHER>Charles River Media</PUBLISHER> <SSN Owner="Author"> <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Content"> <CipherData> <CipherValue>B11695C22</CipherValue> </CipherData> </EncryptedData> </SSN> </BOOK>
Now the part of the XML document containing the more sensitive information is encrypted, and thus protects that information from prying eyes. A SOAP message is an XML document and could contain encrypted information. This solves some of the security weaknesses mentioned earlier in this chapter. It also provides a means of encrypting only the data that requires protection. When using SSL, the entire transaction occurs under encryption—which uses a lot of overhead on the server. With XML encryption, only the sensitive data uses encryption.
XML signatures provide a means of determining who sent a particular document. This way you confirm that you know where the document comes from and you prevent a user from denying that they sent a particular document.
An XML signature involves signing a resource available on the Web with a unique key.
If you wish to sign an XML document, it would need to reside at a URL such as http://www.advocatemedia.com/documents/test.xml. The following snippet identifies the document to be signed.
<Reference URI="http://www.advocatemedia.com/documents/test.xml"> </Reference>
Software then generates a unique digest based on the content of the resource and the results become part of the Reference element.
<Reference URI="http://www.advocatemedia.com/documents/test.xml"> <Digest method="http://www.w3.org/2000/09/xmldsig#shal"/> <DigestValue> ff573499e920e34acc38659bd991ce54 </DigestValue> </Reference>
To verify the signature, the key for the certificate used to sign the resource needs to be part of the document as well. This belongs within the KeyInfo element after the reference information. This example used the X509 certificate used in the SSL examples earlier in the chapter.
<Reference URI="http://www.advocatemedia.com/documents/test.xml"> <Digest method="http://www.w3.org/2000/09/xmldsig#shal"/> <DigestValue> ff573499e920e34acc38659bd991ce54 </DigestValue> </Reference> <KeyInfo> <X509Data> <X509SubjectName> Brian Hochgurtel </X509SubjectName> <X509Certificate> -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQC14RIJZ6cdZSbEZXKMJvXlG2rgRJOSEQRUsOMzSTmrt0v9n52U t/adQtgayhTHlWczGUweJ3QUzn3G+QduZq414tbqXqiZtkhA3EcUSGxUSR9W 5K7O NR3MMRzyOsMIi0S4+e3Hdt7ErsaO14TgvUPfsN4MwXvltGJmshZ+ldBV8QID AQAB AoGAbfIVlivbgNCBw91ThleS86FEVTf/QSAaTxvy7DDKtPwD6thPSPSAFwau Xltk flXZYbFcKypMaLt+mwY1MM7PZezNZdLb022nZZaFIqDEKaJDRKiOiXBGmffJ 3J/X 1h5yXYZHmom6EbwKaWTjIeLKPT8G6OjGnXjd9aDaL0PlVvUCQQDYd6/+1f3 RM/Er gw9UJ09lN8Mbtb0c8aeP6eEaecBcr1KM2wE/HQm/AW583oye3m19GyChk2c SOdk/ B4upgil7AkEA1xhOD92hjWY6FSB36VmzctKNBUYa8YsIuzQB9kZPS27HFcXJ 6W9Y Rqlw36G0DwQmQrNEAhVQBvyW1vrC4o6UgwJBAMEvT6omYDbsHDew52U7D+hN M5rv Pq8uG1ScbYCrV7lf3lRGv34L9D66kFhwZR8DcsNMCnsoibwCVJejrEjDGTEC QQCV yEoLyFVIhuhpb9uwtpM8oRwskP4QN7ZTzkqTebCcIb8nDT2mfa/mPPXp9MvT LRuL lRQFs1uwEdLkT2jIpWsLAkA0loRPPjMjS1RoXR0UdsoDSqvTObVPjgJZl/h7 6WW4 kVDB4JwmMAplr2tiC8Uj1izLoxnMfZRoBE04fibc6SQu -----END RSA PRIVATE KEY----- </X509Certificate> </X509Data> </KeyInfo>
Now that you have the information for the resource, you need introduce the SignedInfo parent element and some information regarding the methods used to sign the information.
<SignedInfo > <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/ Rec-xml-cln4n-20010315/> <Digest method="http://www.w3.org/2000/09/xmldsig#shal"/> <Reference URI="http://www.advocatemedia.com/documents/test.xml"> <Digest method="http://www.w3.org/2000/09/xmldsig#shal"/> <DigestValue> ff573499e920e34acc38659bd991ce54 </DigestValue> </Reference> <KeyInfo> <X509Data> <X509SubjectName> Brian Hochgurtel </X509SubjectName> <X509Certificate> -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQC14RIJZ6cdZSbEZXKMJvXlG2rgRJOSEQRUsOMzSTmrt0v9n52U t/adQtgayhTHlWczGUweJ3QUzn3G+QduZq414tbqXqiZtkhA3EcUSGxUSR9 W5K7O NR3MMRzyOsMIi0S4+e3Hdt7ErsaO14TgvUPfsN4MwXvltGJmshZ+ldBV8QID AQAB AoGAbfIVlivbgNCBw91ThleS86FEVTf/QSAaTxvy7DDKtPwD6thPSPSAFwauX ltk flXZYbFcKypMaLt+mwY1MM7PZezNZdLb022nZZaFIqDEKaJDRKiOiXBGmffJ 3J/X 1h5yXYZHmom6EbwKaWTjIeLKPT8G6OjGnXjd9aDaL0PlVvUCQQDYd6/+1f3R M/Er gw9UJ09lN8Mbtb0c8aeP6eEaecBcr1KM2wE/HQm/AW583oye3m19GyChk2c SOdk/ B4upgil7AkEA1xhOD92hjWY6FSB36VmzctKNBUYa8YsIuzQB9kZPS27HFcXJ 6W9Y Rqlw36G0DwQmQrNEAhVQBvyW1vrC4o6UgwJBAMEvT6omYDbsHDew52U7D+hN M5rv Pq8uG1ScbYCrV7lf3lRGv34L9D66kFhwZR8DcsNMCnsoibwCVJejrEjDGTEC QQCV yEoLyFVIhuhpb9uwtpM8oRwskP4QN7ZTzkqTebCcIb8nDT2mfa/mPPXp9MvT LRuL lRQFs1uwEdLkT2jIpWsLAkA0loRPPjMjS1RoXR0UdsoDSqvTObVPjgJZl/h7 6WW4 kVDB4JwmMAplr2tiC8Uj1izLoxnMfZRoBE04fibc 6SQu -----END RSA PRIVATE KEY----- </X509Certificate> </X509Data> </KeyInfo> </SignedInfo>
Note that the CanonicalizationMethod indicates the method used to create this signature.
Utilizing this signature may involve signing a Web Service or a consumer. The provider of the Web Service is saying that the service is truly provided by his organization. The consumer states that this is really his organization accessing the service.
The Web Services Development Kit (WSDK), which is an early software release from Microsoft, provides you with a means to sign a SOAP request within .NET. The methods provided allow you to prove identity or time. See Appendix B for download instructions.
To use these methods, you need to register the certificate using the “Management Console” shown earlier in the chapter. The methods used are similar to using Authentication methods used in previous examples.
The following snippet creates a token object by loading the certificate registered with the “Management Console,” and if there is the certificate is added to the request of the Web Service.
X509SecurityToken token = GetSecurityToken(); if (token == null) { throw new ApplicationException ("No key provided for signature."); } // Add the signature element to a security section on // the request to sign the request requestContext.Security.Tokens.Add(token); requestContext.Security.Elements.Add (new Signature(token)); //Call Web Service Here
Now the request to the Web Service will be signed with the certificate.
In the Web Service, the code needs to be written to ensure that the certificate information is handled and valid. The following snippet demonstrates C# code examining the certificate contents. If no certificate loads, the request is returned immediately. The statement that creates the mySignature object looks at the SOAP request for signatures. If the token then looks like the one you’re searching for, authorization can occur.
//If no security information we can reject the request. if ( context.Security.Tokens.Count == 0 ) return false; Signature mySignature = context.Security.Elements[i] as Signature X509SecurityToken myCertToken = mySignature.SecurityToken as X509SecurityToken; if (myCertToken = "SomeCertificateValue") { //perform the authorization }
This is just one more way to provide security for Web Services.
|