Professional InfoPath 2003 [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Professional InfoPath 2003 [Electronic resources] - نسخه متنی

Ian Williams, Pierre Greborio

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
توضیحات
افزودن یادداشت جدید











Digital Signatures

InfoPath allows users to sign entire forms using the method specified in the W3C XML Digital Signature recommendation. More generally, XML Signatures can be applied to any digital content, including XML, and may be applied to all or part of an object. Signatures may be the parent of the signed object or a child, or they may stand outside to object entirely. A signature provides an integrity check on a document. If any signed part is modified subsequent to signing, the signature will fail to verify.

In InfoPath, the signatures are children of the document. A form can be signed using one or more XML signatures at the level of the entire document. Because the signature is over the entire form, and any change by the user will invalidate the original signature, InfoPath makes signed forms read-only.

Users can sign and verify forms by choosing Tools→Digital Signatures or by using the Standard toolbar.

If a user opens a form with a signature, InfoPath checks for the existence of a signature. If the form is not signed, it is opened immediately. If a signature is present, InfoPath validates the signature. If the signature is valid, the form opens. If the signature is invalid, a warning dialog box is displayed.


Digital Certificates


Users must have a digital certificate installed on their computer before they can add a digital signature to a form. XML Signature depends on the use of pairs of public and private keys to transform the encrypted data. A signature encrypted with the private key can be decrypted with the public key. So the person verifying a signature with the public key must be sure that it belongs to the sender. A digital certificate validates the relationship between the subject of a certificate and their public key.

InfoPath will use only certificates that have a private key and that have a key usage value of “Digital Signature,” and a purpose of “Client Authentication.” Certificates that are valid in other Office applications, such as self-signed certificates used to sign VBA macros, may not be valid for digital signing in InfoPath.


XML Signature


The W3C recommendation specifies XML syntax and processing rules for creating and representing digital signatures. Unlike other digital signature standards, XML Signature has been designed specifically for the XML environment. XML Signature is quite flexible in that it can sign more than one kind of object, for example, some character-encoded XML in a form, or an embedded, binary encoded object like an image.

The entire process of applying signatures is complex, and we won’t attempt to explain it here in any detail. But it is well worth understanding the process in outline and gaining a sense of the signature syntax.

Signatures are applied by reference to the URI of a signed object with a Reference element. In the example, the reference is to a complete document on the Web, but it could just as well be to an XML fragment in a containing document, such as #publicationTime. However, as you’ve seen, InfoPath allows signatures on entire forms only.


<Reference URI="http://newsline.net/20031010_ln1234_xml">
.
.
</Reference>

The Algorithm attribute of the DigestMethod element references the hash algorithm applied to extract a digest from the form. In this case, the reference is to SHA1, the Secure Hash Algorithm. The DigestValue element, which is base 64 encoded, contains the digest itself.

<Reference URI="http://newsline.net.ny7453_20031122.xml">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>zM14ixa61vpUccMup4Ngai85nsdA=</DigestValue>
</Reference>

The references are wrapped in the SignedInfo element with two other elements. A canonization algorithm is defined in the CanonicalizationMethod element. Canonization tightens up the relatively lax approach of XML to such things as white space and the order of attributes, and ensures that signature validation doesn’t fail owing to nonessential differences that can arise in XML processing. It chooses one path from all the possible XML output options, so that both sender and receiver can generate identical byte values.

The RSA public key algorithm is defined in the Signature Method element.


<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/
REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

   <Reference URI="http://newsline.net.ny7453_20031122.xml">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>zM14ixa61vpUccMup4Ngai85nsdA=</DigestValue>
</Reference>
</SignedInfo>

The entire signature is contained in the Signature element. The Id attribute enables the identification of multiple signatures in business contexts, for example, where two signatures are needed on an expense claim.

The SignatureValue element contains the signed digest of the SignedInfo element, and the optional KeyInfo element can contain a number of key types and structures that identify the signer or their certificate. For example, the KeyName element might give the signer’s e-mail address.


<Signature Id="j_fox">

   <SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/
REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="http://newsline.net.ny7453_20031122.xml">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>zM14ixa61vpUccMup4Ngai85nsdA=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>a22tmXdsOzi90jkbdfMOP==</SignatureValue>
<KeyInfo>
<KeyName>j_fox@ln.newsline.com</KeyName>
</Signature>

As XML forms generated by InfoPath become commonplace, XML Signature will help create secure data as the basis of business transactions.

You can read more about the XML Signature recommendation at [www.w3.org/TR/xmldsig-core/].


Signatures in Form Schema Design


Because the digital signature is located in a node in an XML form instance, you’ll need to specify which node the signature is stored in when you design the form template. You do this by adding a group control bound to an element and incorporating the namespace.


<xs:element name="my:signatures1">
<xs:complexType>
<xs:sequence>
<xs:any namespace="http://www.w3.org/2000/09/xmldsig#"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>


Enabling Signatures


In design mode, you enable digital signatures by choosing Tools→Form Options, and selecting the Allow users to digitally sign this form check box on the Security tab. You can also select the group you have defined to contain the signatures. If you want users to sign the form before they submit it, select the If users submit this form . . . check box. See Figure 10-5.


Figure 10-5: Enabling digital signatures.

You can’t enable signatures if a form is created from a schema, database, or Web service without the digital signature namespace declaration, xmlns:ds=”Chapter 4 you learned about the XSF structure for signatures. If you enable signatures, InfoPath inserts the optional top-level documentSignatures element. The required signatureLocation attribute is an XPath expression pointing to the node containing the signature data.


<documentSignatures signatureLocation="/my:signatures1"/>

/ 166