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 Hardware Security Module (HSM). For more information on
storing signing keys, see the the
Certificates and Keys topic.
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. 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, and Save in Message Attribute:
If you select this option, the Enterprise Gateway generates a symmetric key,
which is included in the message before it is sent to the client.
By default, the key is saved in the symmetric.key message
attribute.
Symmetric Key in Message Attribute:
If a previous filter (for example, a Sign Message
filter) has already used a symmetric key, you can to reuse this key
as proof that the Enterprise Gateway is the holder-of-key entity. You must
enter the name of the message attribute in the field provided, which
defaults to symmetric.key .
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 points 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 enables 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 is displayed. Configure the following fields
on this tab:
Do Not Include KeyInfo Section:
This option enables 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 selected, the Distinguished Name of the signatory's
X.509 certificate is 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 is inserted into the WS-Security header regardless
of the type of Security Token Reference selected from the dropdown.
Important Note:
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 in a <BinarySecurityToken> in 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 in 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.
|