|
It is possible to use either a symmetric or an asymmetric key to sign
the message content. Select the appropriate radio button and configure
the fields on the corresponding tab.
Asymmetric Key
With an asymmetric signature, the signatory's private key (from a
public-private key pair) is used to sign the message. The corresponding
public key is then used to verify the signature. The following fields
are available for configuration on this tab:
Key in Store:
To use a signing key from the Certificate Store, check the
Key in Store radio button and then click the
Signing Key button. Select a certificate that has the
required signing key associated with it. The signing key can also be
stored on a HSM (Hardware Security Module). Please refer to the
Certificate Store help
page for more information on storing signing keys.
The Distinguished Name of the selected certificate
will appear in the X509SubjectName element of the
XML Signature as follows:
|
| | |
|
<dsig:X509SubjectName>
CN=Sample,OU=R&D,O=Company Ltd.,L=Dublin 4,ST=Dublin,C=IE
</dsig:X509SubjectName>
| |
| | |
|
Key in Message Attribute:
Alternatively, the signing key may have already have been used by another
filter and stored in a message attribute. In order to reuse this key,
you can select the Key in Message Attribute radio
button and enter the name of the attribute in the field provided.
Symmetric Key
With a symmetric signature, the same key is used to sign and verify the
message. Typically the client generates the symmetric key and uses it
to sign the message. The key must then be transmitted to the recipient
so that they can verify the signature. It would be unsafe to transmit
an unprotected key along with the message so it is usually encrypted
(or wrapped) with the recipient's public key. The key can then be
decrypted with the recipient's private key and can then be used to
verify the signature. The following configuration options are available
on this screen:
Generate Symmetric Key:
Select this option if you want this filter to generate a symmetric key.
Symmetric Key in Message Attribute:
Alternatively, if you have already generated a symmetric key using a
different filter (e.g. an Encryption filter) and stored it in a message
attribute, you can select this radio button and enter the name of the
message attribute in the field provided.
Include Encrypted Symmetric Key in Message:
As described earlier, the symmetric key is typically encrypted for the
recipient and included in the message. However, it is possible that the
initiator and recipient of the transaction have agreed on a symmetric key
using some out-of-bounds mechanism. In this case, it is not necessary
to include the key in the message. However, the default option is to
include the encrypted symmetric key in the message. The <KeyInfo>
section of the Signature will point to the <EncryptedKey>.
Encrypt with Key in Store:
Select this option to encrypt the symmetric key with a public key from
the Certificate Store. Click the Signing Key button
and then select the certificate that contains the public key of the
recipient. By encrypting the symmetric key with this public key, you are
ensuring that only the recipient that has access to the corresponding
private key will be able to decrypt the encrypted symmetric key.
Encrypt with Key in Message Attribute:
You can also use a key stored in a message attribute to encrypt (or wrap)
the symmetric key. Select this radio button and enter the name of the
message attribute that contains the public key you want to use to
encrypt the symmetric key with.
Use Derived Key:
A <wssc:DerivedKeyToken> token can be used to
derive a symmetric key from the original symmetric key held
in and <enc:EncryptedKey>. The derived
symmetric key is then used to actually sign the message, as opposed to the
original symmetric key. It must be derived again
during the verification process using the parameters in the
<wssc:DerivedKeyToken>. One of these
parameters is the symmetric key held in
<enc:EncryptedKey>. The following example
shows the use of a derived key:
|
| | |
|
<enc:EncryptedKey Id="Id-0000010b8b0415dc-0000000000000000">
<enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<dsig:KeyInfo>
...
</dsig:KeyInfo>
<enc:CipherData>
</enc:EncryptedKey>
<wssc:DerivedKeyToken wsu:Id="Id-0000010bd2b8eca1-0000000000000017"
Algorithm="http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1">
<wsse:SecurityTokenReference wsu:Id="Id-0000010bd2b8ed5d-0000000000000018">
<wsse:Reference URI="#Id Id-0000010b8b0415dc-0000000000000000"
ValueType="..../oasis-wss-soap-message-security-1.1#EncryptedKey"/>
</wsse:SecurityTokenReference>
<wssc:Generation>0</wssc:Generation>
<wssc:Length>32</wssc:Length>
<wssc:Label>WS-SecureConverstaionWS-SecureConverstaion</wssc:Label>
<wssc:Nonce>h9TTWKRylCOz87+mc1/7Pg==</wssc:Nonce>
</wssc:DerivedKeyToken>
<dsig:Signature Id="Id-0000010b8b0415dc-0000000000000004">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<dsig:Reference>...</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>...dsig:SignatureValue>
<dsig:KeyInfo>
<wsse:SecurityTokenReference wsu:Id="Id-0000010b8b0415dc-0000000000000006">
<wsse:Reference
URI="# Id-0000010bd2b8eca1-0000000000000017"
ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"/>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
| |
| | |
|
Symmetric Key Length:
This option allows the user to specify the length of the key to use when
performing symmetric key signatures. It is important to realize that
the longer the key, the stronger the encryption.
Key Info
This tab configures how the <KeyInfo> block of the generated
XML Signature will appear. Configure the following fields on this tab:
Do Not Include KeyInfo Section:
This option allows you to omit all information about the signatory's
certificate from the signature. In other words, the
KeyInfo element is omitted from the signature. This
is useful where a downstream Web Service uses an alternative method of
authenticating the signatory, and wishes to use the signature for the
sole purpose of verifying the integrity of the message. In such cases,
adding certificate information to the message may be regarded as an
unnecessary overhead.
Include Certificate:
This is the default option which places the signatory's certificate
inside the XML Signature itself. The following example, shows an example
of an XML Signature which has been created using this option:
|
| | |
|
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
...
<dsig:KeyInfo>
<dsig:X509Data>
<dsig:X509SubjectName>CN=Sample...</dsig:X509SubjectName>
<dsig:X509Certificate>
MIIEZDCCA0yg
....
RNp9aKD1fEQgJ
</dsig:X509Certificate>
</dsig:X509Data>
</dsig:KeyInfo>
</dsig:Signature>
| |
| | |
|
Expand Public Key:
The details of the signatory's public key are inserted into a
KeyValue block. The KeyValue
block is only inserted when this option is checked.
|
| | |
|
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
...
<dsig:KeyInfo>
<dsig:X509Data>
<dsig:X509SubjectName>CN=Sample...</dsig:X509SubjectName>
<dsig:X509Certificate>
MIIE ....... EQgJ
</dsig:X509Certificate>
</dsig:X509Data>
<dsig:KeyValue>
<dsig:RSAKeyValue>
<dsig:Modulus>
AMfb2tT53GmMiD
...
NmrNht7iy18=
</dsig:Modulus>
<dsig:Exponent>AQAB</dsig:Exponent>
</dsig:RSAKeyValue>
</dsig:KeyValue>
</dsig:KeyInfo>
</dsig:Signature>
| |
| | |
|
Include Distinguished Name:
If this checkbox is checked, the Distinguished Name of the signatory's
X.509 certificate will be inserted in an
<X509SubjectName> element as shown in the
following example:
|
| | |
|
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
...
<dsig:KeyInfo>
<dsig:X509Data>
<dsig:X509SubjectName>CN=Sample,C=IE...</dsig:X509SubjectName>
<dsig:X509Certificate>
MIIEZDCCA0yg
....
RNp9aKD1fEQgJ
</dsig:X509Certificate>
</dsig:X509Data>
</dsig:KeyInfo>
</dsig:Signature>
| |
| | |
|
Include Key Name:
This option allows you insert a key identifier, or
KeyName, to allow the recipient to identify the
signatory. Enter an appropriate value for the
KeyName in the Value field.
Typical values include Distinguished Names (DName) from X.509
certificates, key IDs, or email addresses. Specify whether the
specified value is a Text value of a
Distinguished name attribute by checking the appropriate
radio button.
|
| | |
|
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
...
<dsig:KeyInfo>
<dsig:KeyName>test@oracle.com</dsig:KeyName>
</dsig:KeyInfo>
</dsig:Signature>
| |
| | |
|
Put Certificate in an Attachment:
The Enterprise Gateway supports SOAP messages with attachments.
By selecting this option, you can save the signatory's certificate to the
file specified in the input field. This file can then be sent along with
the SOAP message as a SOAP attachment.
From previous examples, it is clear that the user's certificate is
usually placed inside a KeyInfo element. However,
in this example, the certificate is actually contained within an
attachment, and not within the XML Signature itself. Clearly, we need a
way to reference the certificate from the XML Signature, so that
validating applications can process the signature correctly. This is the
role of the SecuriyTokenReference block.
The SecurityTokenReference block provides a generic
way for applications to retrieve security tokens in cases where these
tokens are not contained within the SOAP message. The name of the
security token is specified in the URI attribute of
the Reference element.
|
| | |
|
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
...
<dsig:KeyInfo>
<wsse:SecurityTokenReference xmlns:wsse="http://schemas.xmlsoap.org/ws/...">
<wsse:Reference URI="c:\myCertificate.txt"/>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
| |
| | |
|
When the message is actually sent, the certificate attachment will be
given a "Content-Id" corresponding to the URI
attribute of the Reference element. The following
example shows what the complete multipart MIME SOAP message looks like as
it is sent over the wire. It should help illustrate how the
Reference element actually refers to the
"Content-ID" of the attachment:
|
| | |
|
POST /adoWebSvc.asmx HTTP/1.0
Content-Length: 3790
User-Agent: Enterprise Gateway
Accept-Language: en
Content-Type: multipart/related; type="text/xml";
boundary="----=Multipart-SOAP-boundary"
------=Multipart-SOAP-boundary
Content-Id: soap-envelope
Content-Type: text/xml; charset="utf-8";
SOAPAction=getQuote
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
...
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
...
<dsig:KeyInfo>
<ws:SecurityTokenReference xmlns:ws="http://schemas.xmlsoap.org/ws/...">
<ws:Reference URI="c:\myCertificate.txt"/>
</ws:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
...
</s:Envelope>
------=Multipart-SOAP-boundary
Content-Id: c:\myCertificate.txt
Content-Type: text/plain; charset="US-ASCII"
MIIEZDCCA0ygAwIBAgIBAzANBgkqhki
....
7uFveG0eL0zBwZ5qwLRNp9aKD1fEQgJ
------=Multipart-SOAP-boundary-
| |
| | |
|
Security Token Reference:
A <wsse:SecurityTokenReference> element can be
used to point to the security token used in the generation of the
signature. Select this option if you wish to use this element. The
type of the reference must be selected from the
Reference Type dropdown.
The <wsse:SecurityTokenReference>, (within the
<dsig:KeyInfo>), may contain a
<wsse:Embedded> security token. Alternatively,
the <wsse:SecurityTokenReference>, (within the
<dsig:KeyInfo>), may refer to a certificate
via a <dsig:X509Data>. Select the appropriate
button, Embed or Refer, depending on
whether you want to use an embedded security token or a referred one.
You can make sure to include a <BinarySecurityToken> (BST) that
contains the certificate used to wrap the symmetric key in the
message by selecting the Include BinarySecurityToken
option. The BST will be inserted into the WS-Security header regardless
of the type of Security Token Reference selected from the dropdown.
It is important to note that when using the "Kerberos Token Profile"
standard and the Enterprise Gateway is acting as the initiator of a secure
transaction, it can use Kerberos session keys to sign
a message. The KeyInfo must be configured to use a Security Token
Reference with a ValueType of "GSS_Kerberosv5_AP_REQ". In this case,
the Kerberos token is contained within a <BinarySecurityToken>
within the message.
If the Enterprise Gateway is acting as the recipient of a secure transaction,
it can also use the Kerberos session keys to sign the message returned
to the client. However, in this case, the KeyInfo must be configured to
use a Security Token Reference with ValueType of "Kerberosv5_APREQSHA1".
When this ValueType is selected, the Kerberos token is not contained
within the message. The Security Token Reference contains a
SHA1 digest of the original Kerberos token received from the client,
which identifies the session keys to the client.
Note that when using the "WS-Trust for SPENGO" standard, the Kerberos
session keys are not used directly to sign messages since a security
context with an associated symmetric key is negotiated. This symmetric
key is shared by both client and service and can be used to sign
messages on both sides.
|