Overview of XML EncryptionWritten by Pawan Bangar
XML encryption classifies a course of action for encrypting plain text data, generating ciphertext, and decrypting ciphertext to retrieve plaintext data.Both and are optional i.e. sender and receiver may agree on encryption method and key in advance. Several elements use definitions from DSIG.If recipient does not know decryption key in advance, then sender generates and sends it. The key can be protected in transit by encrypting method or key agreement. If plaintext data to encrypt is an XML element or content, you encode it using UTF-8 and perform any necessary transforms to it, otherwise, if it is an external resource, you simply consider it as an octet sequence. You then encrypt data, creating CipherValue, which you place in EncryptedData. Care must be taken when signing content that may later be encrypted; clearly; content must be restored to exactly original plaintext form for signature to validate properly. To restore plaintext in signed content, use decryption transform method for XML signature defined by XML encrypt joint W3C and IETF working group. This transform also allows specifications of XML fragments that were encrypted and then signed with rest of document and, therefore, are not decrypted to validate signature. Often, encrypted fragments are removed from signed information by using XPATH transform in reference element, since meaningful information is plaintext. We can sign plaintext version of an encrypted element by including appropriate reference element pointing to it. When signed document is confidential and encrypted after being signed, you should also protect against surreptitious forwarding in which recipient forwards signed confidential document to a competitor, encrypted by competitor public key, trying to make it look as if sender sent confidential information. To prevent surreptitious forwarding, signer should append recipient identities to document being signed.
| | XML integration with ADO+Written by Pawan Bangar
One of most important design goals for ADO+ was powerful XML support. Microsoft designed ADO+ hand in hand with .NET XML framework. Both are components of a single architecture. The unification of ADO+ with XML framework happens in dataset. For beginners datasets has methods that can read and write XML. For reading XML, XML framework parser is used, either explicitly or implicitly. For writing XML out, XML framework XmlWriter is utilized. In spite of where data originated, dataset can save out its contents, both schema and data as XML. The schema is encoded as an internal W3C schema section, generally known as XSD, and data is encoded as XML that be conventional to that schema. Because dataset's native serialization format is XML, it is an tremendous medium for moving data between tiers in a disconnected fashion just like disconnected recordset. Indeed, .NET Web services make intense use of datasets to transport data in context of a schema between tiers of an application. Just like populating dataset via its object model or through managed providers, loading dataset with XML is a two stage process. 1) The schema is created, and then data is loaded. If XML document comes with a schema, that schema is used to create relational structure of dataset. If not, dataset can infer schema from containment relationships within document. In general speaking, elements that are not scalar valued are mapped to tables, whereas attributes and scalar valued elements are mapped to columns. 2) The process of inferring schema is useful when constructing an application that has to consume XML that comes with no schema. But for production applications, it is highly desirable to take inferred schema, modify it as appropriate, and load that schema in before actual data is loaded. That way, process of loading document is deterministic, so you don't have to worry about what a slight change in incoming document will do to inference heuristics.
|
