SAM configuration on webservices

[TomVanDoo]

Hi Gurus (couldn't resist),

We're setting up webservices on our system, which identify themselves on the system via SAML.

Our security token provider is a datapower ESB.

We use "Sender-vouches" mechanism in a SAML1.1 context.

Our setup in transaction SAML2 is ok. (provider and policy)

We use X509 certificate and SAML message Authentication in our configuration of the webservice binding (SAOMANAGER)

In our SOAPUI, we have the certificates setup right. Our Datapower ESB is configured correctly, but still, we always get following error in SAP: (SRT_UTIL)

---MODULE	CL_ST_CRYPTO_SAML:CHECK_AUTHENTICATION
---INFO1	Unexpected SAML subject confirmation type urn:oasis:names:tc:SAML:1.0:cm:sender-vouches

It looks like SAP does not identify the fact that we need "Sender-Vouches" principle. From the call stack, I derived that in this code, the SV flag is empty.

Earlier in the call stack, the SV flag should be marked based on two other parameters:

These should be on:

value	should equal to
MessageSignatureToken.Type	X509Token
SupportingToken.Type	SamlToken

but one of them (or both) does not match the expected result. Hence, the SV flag remains off.

Our system is a CRM 7 with a netweaver 7.2 stack

Anyone ever encountered such a problem, or knows which setting we have forgotten?

Much appreciated.

[TomVanDoo · Accepted solution]

With the help of Mathias and the previous input from Martijn, we managed to get the SAML working.

First of all, since we are in a SAML1.1 context and our previous Trust configuration was on 1.1 (as well as our configuration on the DataPower ESB), we did not have to use SAML2 trust in the WSS_SETUP report. The use of "SAP Logon ticket trust" was in line with our previous configuration, so that was the one we needed to select.

Secondly, the user mapping must not be done directly into table USREXTID via SM30, but rather via a program Z_SAML_TRUST, which you can find in note 1254821

Alternatively, if your SAML subject is the userid of your SAP system, you can use the report RSUSREXTID to mass upload the mapping entries in the table.

Thanks all

[Former Member · Accepted solution]

Hello,

We are trying to set up SSO between non-SAP server (JBoss) and SAP ABAP AS, which is on 7.01 SP8. As our ABAP back end is not a version where SAML 2.0 is supported, we decided to use SAML 1.1

To establish proof of concept, we are using SOAP UI. However, we are getting "XML Invalid Signature" when the SOAP UI is making calls to ABAP back end. We tried removing the certificate that we are using for SOAP UI but we still get the same error.

Do you have any clues for us? I have also created a new thread (http://scn.sap.com/thread/3483030).

Your help is very much appreciated! Thank you.

Regards,

Pranith.

[martijndeboer · Accepted solution]

Hello Pranith,

SAML 1.1 Sender-Vouches requires the SecurityTokenReference transform, which is not supported by SOAP UI. Therefore SOAP UI is not suited for testing SAML.

But you can e.g. test SAML by configuring a ABAP web service proxy to talk to the same system (->localhost connection).

Regards,

Martijn

[Former Member · Accepted solution]

Thank you Martjin for your reply.

We are using SoapUI 4.5.1-NB-SNAPSHOT and we see the SecurityTokenReference transform in the request. Not sure if that makes sense but I thought I will let you know. Please find attached XML file from the SOAP UI and the error logs from the ABAP back end. Regardless of a certificate present or not in SAP ABAP, we get the exact same error. And, the trace logs show that SAP is using same DSIG_INFO values to compare against Signature(SOAP UI digest) values.

Can you share with us a document or a link, if any, we can use as a reference to set up SAML using ABAP as web service proxy?

Regards,

Pranith.

[Former Member · Accepted solution]

Hello Martjin,

We developed a custom program in python and that did the trick for us. The digest values generated by SAP and SOAP UI XML calls were different and we had to remove lot of spaces and carriage returns from the message. We have also noticed that DSA algorithms were giving issues when compared to RSA based algorithms.

I just wanted to give you this update and thank you for your support on this.

Regards,

Pranith.

[TomVanDoo]

Extra info

I've done some code interpretation and there's something quirky going on

at a certain point, we get the entities from the DB. Earlier n, the code specifically gave a parameter to look for local entities (constant)

notice in below code how we check in the if test that the entity type must be local and then there is a switch on entity type with local and external branch

the external branch is dead. the code will never get there.

but our certificate for the ESB, is in the external part. in table SAML_ENTITY_E

[mathias_essenpreis]

Your code interpretation leads me to the following question:

How did you register your ESB in transaction SAML2? Did you add it as as a trusted provider of type "Security Token Service"? This is prerequisite...

Then in the db there will be a link to from the local entity which is your ABAP system to the external identity of type Security Token Service.

[TomVanDoo]

The DataPower ESB has been setup as a security token service provider, with the signing certificate loaded (self signed certificates)

The certificates in tables SAML2_ENTITY_L, SAML2_ENTITY and SAML2_ENTITY_E

Where could I find the link between the local and the external?

Thanks already for the help btw 🙂

[mathias_essenpreis]

Okay, let's go to the bits and bytes :-).

If everything is setup right there should be a link from the local entity ID (SAML2_ENTITY_L) which is your SAML Provider in ABAP to the external identity (SAML2_ENTITY_E), your ESB you added as trusted provider.

This link you see in table SAML2_TRUST.

But to be honest, I don't think there are problems looking up the external entity since you get a complaint about the certificate of the ESB which seems to be not trusted.

Let's focus on the certificate.

- What is the max validity time of this certificate? How long will it be valid?

- I assume you are sure that the ESB really uses the same private key pair of the certificate you configured in the trusted provider?

Can you please attach in the decrypted SOAP request SAML assertion? Alternatively you can provide the certificate you used so that I can analyze it.

[TomVanDoo]

Hi Mathias,

I added the payload in attachment.

This is the payload I downloaded from SRT_util error log, which shows that the message is in any case decrypted. (so the SSL decryption works)

The signing certificate is included inline. If you copy the content into a file and name it blabla.cer, you can open it (or was it in BASE64?)

It should be checked against the ESB certificate (also attached)

esb.owner_renameTo.cer.txt.zip

[mathias_essenpreis]

Hi Tom,

I just compared the certificate of your payload with the certificate in the zip. And guess what. They are 90% equal...

But...

The thumbprint of the public key differs and this is the most important part when it comes to signature validation.

So I suggest to delete all the certificates with the name CN = IRIS_ESB_SAML inside the AS ABAP (just to be sure). Then you upload the certificate again to SAML2.

Regards,

Mathias

[martijndeboer]

You need to add it as trusted provider, but not create a policy for it (or at least not assign the policy in the ws-configuration).

Just leave the policy field empty.

[TomVanDoo]

No luck yet

Configuration seems alright, but he has a problem trusting the certificate.

All certificate chains have been uploaded in the stores though...

[mathias_essenpreis]

Hi Tom,

did you configure the the runtime to evaluate the trust you configured with transaction SAML2?

In order to do that you need to

1. run report WSS_SETUP

2. set SAML 1.1 Trust to "Use SAML Trust"

3. Uncheck "Test Run"

4. Press F8.

Inside the SRT_UTIL error log you should also see against which PSE was checked. This should be the S2SVPS PSE if "SAML Trust" was successfully activated. Using "Login Ticket Trust" we would have SAPSSYS PSE.

Regards,

Mathias

[TomVanDoo]

Hi Matthias,

We did run the WSS_SETUP program, so that should be ok.

Interestingly though, is that the error messages do not specify against which keystore the certificate was checked.

(I attached both error messages in full)

Any idea what could cause this behaviour?

Cheers!

[mathias_essenpreis]

Go to transaction STRUST and double click in the tree on PSE SSF SAML2 Service Provider. Do you see the signer certificate in the list?

Can you post the whole SOAP message please?

[martijndeboer]

Hi Tom,

good news: you are not the first customer with DataPower. I know at least three other customers using DP using SAML Sender-Vouches.

Problem is your configuration. You have configured SAML with a policy specified. Policies are only required for SAML Holder-of-key scenarios. The configuration is failing, as the wrong SAML token has been received.

Best is to delete the ws-configuration, create a new configuration and specify "Message Authentication" with SAML and do not specify an Security Token Service setting.

Regards,

Martijn

[TomVanDoo]

If I don't enter a security Token Service, then I have the problem that my signing certificate is not trusted. My signing certificate is specified in my "trusted providers" under SAML2.

The security token service links to this provider configuration, via the Policy object.

Is there another way to specify the signing certificate, without using a policy?