Highlighted
Absent Member.
Absent Member.
133 views

XPATH for digital signatures using Service Test

I'm trying to figure out how to create a signature in the SOAP header where the one and only signature covers the following items:
[1] Timestamp
[2] Binary Security Token
[3] Message Body

I think the problem is that the wsse:Security/wsu:Timestamp and wsse:Security/wsse:BinarySecurityToken aren't in the message yet (see below)

I get an "unknown namespace" error if I use something like "TARGET_PATH=/soap:Envelope/soap:Header/wsse:Security/wsu:Timestamp"

If I use "TARGET_PATH=//*[namespace-uri()='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' and local-name()='Security']" it doesn't return any nodes (i.e. wsse:Security doesn't appear to be in the message)

Any help would be greatly appreciated.
0 Likes
4 Replies
Highlighted
Absent Member.
Absent Member.

Re: XPATH for digital signatures using Service Test

Hi Jason

A one and only signature can either sign the whole message (as you see by default) or a list of xpath. You correctly identified that the timestamp and token are yet to exist when the signature is processed so you cannot reference them with an xpath.

Why is it required to have only these elements signed? The server should generally not care if message integrity is stronger then required.

Also, which client framework are actual clients for this service useing?

Thanks,
Yaron
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: XPATH for digital signatures using Service Test

The server we are hitting requires these elements and yells whenever there are more elements in signature than required.

The server is currently using Metro/Xwss v2.0 for ws-security stack but may use Apache/Axis in near future.

The Metro v2 configuration allows for an "optional" target but we haven't tried that yet. Maybe an open-ended XPATH to permit (optionally) any element in the signature but still require things like Timestamp, Body, and BST. I'll try that this afternoon.

(IMHO) I should be able to tell ServiceTest to sign certain elements in the message. For arguments sake, let's say I wanted to sign ONLY the timestamp. I'm thinking I'd have to 'manually' add the timestamp into the header and then sign the message.

I guess I was hoping for something like:

SECHDR = MESSAGE_ADD_SECURITY(...);
TIMESTAMP = CREATE_TIMESTAMP(...);
SECHDR.ADD(TIMESTAMP);
BST = CREATE_BST(X509info...);
SECHDR.ADD(BST);
BODY = MESSAGE_GET_BY_XPATH("//soap:Body");
SIGNATURE = CREATE_SIGNATURE(...);
SIGNATURE.ADDREF(TIMESTAMP);
SIGNATURE.ADDREF(BST);
SIGNATURE.ADDREF(BODY);
SECHDR.ADD(SIGNATURE);
SIGNATURE.SIGN(PRIVATEKEYINFO);
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: XPATH for digital signatures using Service Test

The version of service test you are using actually has two security models: One which is fine-grained (the one you used) and another one that allows to configure security in a higher level similarly to Microsoft's WCF.

The Metro project aims to reach interoperability with .Net but I'm not sure if that's the case with xwss v2 also. I suggest that you will first try to change the strict signature validation and continue with the path you have started. A second option could be to try to use our WCF-like configuration which is guaranteed to work providing that your service is interoperable with WCF.

BTW why do you sign the binary token? It is already internally signed by the issuer so it can't be altered. It can be totally replaced but in that case the main signature would be invalid. Actually when I checked with WCF it signs just the timestamp and the body but not the binary token.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: XPATH for digital signatures using Service Test

I'm guessing that you are referring to ServiceTest security scenarios ? I tried to ham-fist my way through one but kept getting errors (appeared as if two 'modulues' were speaking different SOAP versions .. or different ws-security versions). I'll try to revisit that potential solution.

We are actually using the Metro 3.x distribution but with Xwss v2 security configuration.

Why do we sign the BST ? That decision was made very early in the game ... so now we're working within those 'guidelines' (requirements) until we have good reason to say "this should be changed".

The server actually requires SAML-HOK as key-bearing token and DSIG that covers the SAML Assertion, timestamp, and message body. I'm trying to get ServiceTest to work with an X509 instead of the SAML Assertion with the thought that it would be easier to reach success (then figure out how to switch to SAML-HOK). Again, we're signing the SAML-HOK when it's already signed by a 'trusted' issuing authority.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.