Need help debugging SAML token signatures

[Former Member]

Hello experts,

I am trying to set up a scenario, where my Web Service client (non-SAP) requests a SAML 1.1 assertion from its STS with confirmation method = sender-vouches.

The client inserts the received token into its SOAP request and signs

- the body and timestamp and

- the security token reference

The produce message looks very similar to the one I found in the wiki at: http://wiki.sdn.sap.com/wiki/display/Security/SingleSignonusingSAMLSenderVouches+example

My Web Service provider (AS ABAP 7.0 EHP 2 - the current trial server) rejects the message with the following error message:

CX_WS_SECURITY_FAULT : An exception occurred: XML Signature digest error for reference wssecurity_signature_id_21 | program: CL_ST_CRYPTO==================CP include: CL_ST_CRYPTO==================CM00C line: 234

Somewhere later in the trace, I find: ... with internal error id 1001

wssecurity_signature_id_21 is the id of the body part in my SOAP request.

I imported the sender's signer cert in every truststore in STRUST (System PSE an all WS-Security and SAML ones). I have also executed report WSS_SETUP for initial configuration. My provider is set up to require no transport level security and SAML for authentication.

How do I debug this type of issue?

Is there documentation how to interpret the error message?

- Didn't I sign the correct elements?

- Was the certificate or its signer untrusted? [I even tried with self-signed certs.]

- Did I chose an inconvenient transform or canonicalization algorithm?

- ...

I tried reviewing the code of CL_ST_CRYPTO in SE80 - however, not being an ABAP expert, I didn't even find CM00C line 234 and I don't think I should try or need to do this.

What am I doing wrong and more importantly - how would I figure this out myself?

Tried to post the SOAP message, but this messed up the entire formatting...

Edited by: Jens Wanske on Feb 7, 2011 3:02 PM

[Former Member]

I tried removing the sender's certificate from all truststores and the error remained the same!

Thus I assume the error is somehow related to the certificate / truststore / fact that I selected no transport guarantee...

... Still didn't figure out how to post a SOAP message here ... It seems as if all XML surroundings are lost even with the code tag around it ...

Edited by: Jens Wanske on Feb 7, 2011 3:14 PM

[martin_voros]

Hi,

How do you sign that message? I am not sure if there is any suitable method but if you look at class CL_ST_CRYPTO then you can see what is checked. You could try to put external debugger into first method which is called (my guess is method CHECK_SIGNATURE). The reason why you can't find line 234 is that during activation all methods are concatenated into one include.

Cheers

[Former Member]

Hi,

I was able to set an external breakpoint at various places in SE80 (even the constructor of CL_ST_CRYPTO and in IF_SOAP_TRANSPORT_BINDING~PROCESS_BODY where I found the last successful trace string). But when sending a message from my external client, the response gets back immediately - with no chance of debugging on the server side.

Do I need somehow enable a debug mode?

I managed to post my SOAP request and SOAP response to the wiki page as a comment: http://wiki.sdn.sap.com/wiki/display/Security/SingleSignonusingSAMLSenderVouches+example?focusedCommentId=224003774&#comment-224003774

Sorry for hijacking... I can try to remove the post if it is inconvenient to be there, however, I think hints on troubleshooting can be of general interest.

Regards,

Jens

[Former Member]

Hi,

what do you think about the fact that the error didn't change when removing the sender's certificate from all trust stores?

Isn't STRUST > System PSE or WS Security Standard or the other WS Security truststores the right place to add my cert?

Regards,

Jens

[martin_voros]

Hi,

i just realized that debugger won't work because you are not logged yet. Honestly, I don't know how to debug it. It's funny that it failed on #wssecurity_signature_id_21 but not on #wssecurity_signature_id_20 (I assume here that it's processed according to order in XML).

If you enter class CL_ST_CRYPTO into search on service.sap.com/notes then you get some notes related to problems for specific clients such Oracle. I am not saying those notes will help you but it might be a similar problem.

I guess you've already read Note 1254821 which describes what you need to set up for this scenario.It also mentions which PSE needs to have the key.

Cheers

[martijndeboer]

SAML Sender-Vouches are assertions that are locally issued. SAML Sender-Vouches is suited to server to server communication, which does not involve an STS. For desktop to server authentication, SAML holder-of-key must be used.

When using an STS, you should use SAML with the holder-of-key confirmation method.

I have described a set of solutions for EE5, Axis2, wss4j, .Net WCF described in http://sap-press.de/2409