Error #6454: when trying to setup/connect to ensemble SOAP Service with SSL/Username Policy

Primary tabs

Hello Community, 

I want to secure a SOAP Webservice (an EnsLib.SOAP.Service one, if that matters) adding a SSL/Username Policy to it. As im not sure how detailed my request here should get, ill try giving a detailed as-is description of my setup, what I've tried, how I tried to test the connection and what problems including some logs I ran into. 

As a small foreword: I'm pretty new to the whole security aspect of intersystems and soap itself. 

System:

I've tried it on 2 different systems with pretty much the same result: 

  1. IIS Server with a 2 System-Mirror Healthshare 2018.1.2 Installation
  2. local development environment with an Apache 2.4 (not the limited one delivered with the standard installation of healthshare) and the Healthshare installation on the same machine
    1. (i must admit, im not a server administration guy so I am not sure, if that is set up 100% correctly there - but anyway the outcome was the same on both systems)

Initial Setup:

I've got a soap service, the ensemble production with the soap service active, the webapplication for it, made some changes to the ^SYS(Security...) global to make it available, created a role and a user and set them up. Without policy and allowing unauthenticated access and the unknown it worked as I had expected. 

I had sent my test requests with SoapUI at this stage and got the correct response back from healthshare and the ensemble messages were created as expected, too.

What I have done / tried

  1. Generated WS-Policy for SSL/Username for my service - I unselected everything there in the policy-wizard (like ws-addressing, strict layout and require client certificate) to make it as easy as possible and minimize other error sources that i didn't want to deal with at this stage. I didn't change anything of the generated policy as I couldn't find hints that it would be nessessary.
  2. changed the webapplication to enforce the use of keyword instead of unauthenticated login, set up my created user with the appropriate role
  3. on both systems the default communication to the webserver is over https, on the local apache system i tried it with http only too, though
  4. In SoapUI the only configuration change was to create a outgoing ws-configuration with the username + password and apply it to my requests - the resulting request included the needed usernameToken then
  5. I sent my requests to this address: https://server-domain/webapplicationname/OBG.EnsWSP.EnsBS.TestSoapServic...

After that failed (see below) I wanted to check that the username/login is not the problem, so I edited the policy at this stage, removing the whole "<sp:transportBinding>" block - so that no SSL is required and only the usernameToken is still nessessary.

I also tried various changes to the policy at this stage, as im not sure what I had to do, but that was more like blind guessing.

Questions that I had but couldnt answer myself at this point

If I want to secure the communication with SSL, I expected to have to provide a certificate for it somewhere either in the policy, the webservice class, webapplication or something , but I still don't know how or where to do so, if it is needed. Currently only the webserver itself has a certificate set up for its https communication. for the IIS-Server setup there is also a %superserver %telnet and some mirror ssl-configs configured in healthshare

What were the results?

After the above steps up to 4. the request fails with a soap-fault:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:s="http://www.w3.org/2001/XMLSchema">
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode>SOAP-ENV:Server</faultcode>
         <faultstring>Serverapplikationsfehler</faultstring>
         <detail>
            <error xmlns="http://soap.test.com/2005/09/outbound">
               <text>FEHLER #6454: Keine unterstützte Richtlinienalternative in Konfiguration OBG.EnsWSP.EnsBS.TestSoapServiceConfig:service.</text>
            </error>
         </detail>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The ISCSOAP-Log:

05/12/2020 16:11:10 *********************
Input to Web service with SOAP action = ""
<soapenv:Envelope xmlns:out="http://soap.sforce.com/2005/09/outbound" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:sobject.enterprise.soap.sforce.com">
   <soapenv:Header>
      <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-A7D77B4D3793977976158929267071110">
            <wsse:Username>someuser</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">somepassword</wsse:Password>
            <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">somenonce</wsse:Nonce>
            <wsu:Created>2020-05-12T14:11:10.711Z</wsu:Created>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <out:notifications>
            <out:OrganizationId>1234567890ABCDEFGH</out:OrganizationId>
            <out:ActionId>1234567890ABCDEFGH</out:ActionId>
            <out:SessionId>123</out:SessionId>
            <out:EnterpriseUrl>www.test.de</out:EnterpriseUrl>
            <out:PartnerUrl>www.partnertest.de</out:PartnerUrl>
            <out:Notification>
                <out:Id>1234567890ABCDEFGH</out:Id>
                <out:sObject>
                    <urn:Id>1234567890ABCDEFGH</urn:Id>
                    <urn:Name__c>Testington</urn:Name__c>
                </out:sObject>
            </out:Notification>
        </out:notifications>
   </soapenv:Body>
</soapenv:Envelope>
---------------
Validate Security header: action=""
Validating security element 1: %SOAP.Security.UsernameToken
Security UsernameToken validated
Security SSL message 05/12/2020 16:11:10 *********************
Validation Policy 2 in OBG.EnsWSP.EnsBS.TestSoapServiceConfig:service for OBG.EnsWSP.EnsBS.TestSoapService
Headers: Tokens: Signatures: SignatureConfirmations: EncryptedData: Timestamp Id=, pos= *********************
Alternatives Alternative 1
    sp:TransportBinding
        sp:IncludeTimestamp
        sp:AlgorithmSuite=Basic128
    Supporting Tokens
        UsernameToken
            :type=sp:SignedSupportingTokens
            Include=AlwaysToRecipient
            wss=1.1 Supporting Token 1, type=sp:SignedSupportingTokens, tokenType=UsernameToken
     Token not found
    Validate of TransportBinding failed.
    No Alternative matches
05/12/2020 16:11:10 *********************
Output from Web service with SOAP action = ""
<?xml version='1.0' encoding='UTF-8' standalone='no' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:s='http://www.w3.org/2001/XMLSchema' >
  <SOAP-ENV:Body>
    <SOAP-ENV:Fault>
      <faultcode>SOAP-ENV:Server</faultcode>
      <faultstring>Serverapplikationsfehler</faultstring>
      <detail>
    <error xmlns='http://soap.test.com/2005/09/outbound'>
     <text>FEHLER #6454: Keine unterstützte Richtlinienalternative in Konfiguration OBG.EnsWSP.EnsBS.TestSoapServiceConfig:service.</text>
    </error>
</detail>
    </SOAP-ENV:Fault>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

After that - as mentioned above -, I removed the whole transportBinding-part from the policy and tested it again with exactly the same request - then it worked again, as I expected. 

I've sent all requests over https so they were basically encrypted, but as it seems, not like the policy wants me to. 
 

Thanks for any help!

Replies

Hi Ralf,
unfortunately you did not provide the policy.

It should look like this: (in Wizard, pick "Username Authentication over SSL/TLS" - leave everything else on the defaults!)

<cfg:configuration xmlns:cfg="http://www.intersystems.com/configuration" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl" xmlns:wsp="http://www.w3.org/ns/ws-policy" name="service">
  <cfg:service classname="[your webservice-class]">
    <wsp:Policy>
      <sp:TransportBinding>
        <wsp:Policy>
          <sp:TransportToken>
            <wsp:Policy>
              <sp:HttpsToken>
                <wsp:Policy/>
              </sp:HttpsToken>
            </wsp:Policy>
          </sp:TransportToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic128/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
          <sp:Layout>
            <wsp:Policy>
              <sp:Strict/>
            </wsp:Policy>
          </sp:Layout>
          <sp:IncludeTimestamp/>
        </wsp:Policy>
      </sp:TransportBinding>
      <sp:SignedSupportingTokens>
        <wsp:Policy>
          <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
            <wsp:Policy>
              <sp:WssUsernameToken11/>
            </wsp:Policy>
          </sp:UsernameToken>
        </wsp:Policy>
      </sp:SignedSupportingTokens>
      <wsap:UsingAddressing/>
    </wsp:Policy>
  </cfg:service>
</cfg:configuration>

In SOAPUI, enable WS-Addressing. Below the request-message there is a small button-line starting with [Auth] ... here you also find [WS-A] where you can find a checkbox to enable it.
Add the WS-A to the request. Right click on the request-message -> "WS-A headers"-> "Add WS-A headers".
Right click on request-message you can Add "WSS UsernameToken" and "WS-Timestamp" if you do not have configured that otherwise in general.

This works for me.

Please note: SOAP-logging (with "iosv" flags) is always a good help.

HTH,
Bernd

Hello and thank you for your help, 

sadly this still does not work. I checked my policy which I sadly didnt include in my first post and it is identical to the one you provided. 

After doing the steps you asked in soap ui the result in the ^iscsoap log looks kind of the same: 

05/18/2020 10:26:51 *********************
Input to Web service with SOAP action = "Test"
<soapenv:Envelope xmlns:out="http://soap.sforce.com/2005/09/outbound" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:sobject.enterprise.soap.sforce.com">
   <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
         <wsu:Timestamp wsu:Id="TS-2667979931FBF3824915897900793112">
            <wsu:Created>2020-05-18T08:21:19.311Z</wsu:Created>
            <wsu:Expires>2020-05-19T12:07:59.311Z</wsu:Expires>
         </wsu:Timestamp>
         <wsse:UsernameToken wsu:Id="UsernameToken-2667979931FBF3824915897900699691">
            <wsse:Username>someuser</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">somepassword</wsse:Password>
            <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">BvWIisN0trJYs54oV8TRpQ==</wsse:Nonce>
            <wsu:Created>2020-05-18T08:21:09.967Z</wsu:Created>
         </wsse:UsernameToken>
      </wsse:Security>
      
   <wsa:Action>Test</wsa:Action></soapenv:Header>
   <soapenv:Body>
      <out:notifications>
         <out:OrganizationId>1234567890ABCDEFGH</out:OrganizationId>
         <out:ActionId>1234567890ABCDEFGH</out:ActionId>
         <out:SessionId>123</out:SessionId>
         <out:EnterpriseUrl>www.test.de</out:EnterpriseUrl>
         <out:PartnerUrl>www.partnertest.de</out:PartnerUrl>
         <out:Notification>
            <out:Id>1234567890ABCDEFGH</out:Id>
            <out:sObject>
               <urn:Id>1234567890ABCDEFGH</urn:Id>
               <urn:Name__c>Testington</urn:Name__c>
            </out:sObject>
         </out:Notification>
      </out:notifications>
   </soapenv:Body>
</soapenv:Envelope>
---------------
Validate Security header: action="Test"
Validating security element 1: %SOAP.Security.Timestamp
Security TimeStamp validated
Validating security element 2: %SOAP.Security.UsernameToken
Security UsernameToken validated
Security SSL message 05/18/2020 10:26:52 *********************
Validation Policy 2 in OBG.EnsWSP.EnsBS.SFSoapServiceConfig:service for OBG.EnsWSP.EnsBS.SFSoapService
Headers:
  Header Namespace=http://www.w3.org/2005/08/addressing, Name=Action, Id= Tokens: Signatures: SignatureConfirmations: EncryptedData: Timestamp Id=, pos= *********************
Alternatives Alternative 1
    sp:TransportBinding
        sp:IncludeTimestamp
        sp:AlgorithmSuite=Basic128
    Supporting Tokens
        UsernameToken
            :type=sp:SignedSupportingTokens
            Include=AlwaysToRecipient
            wss=1.1
    wsap:UsingAddressing Supporting Token 1, type=sp:SignedSupportingTokens, tokenType=UsernameToken
     Token not found
    Validate of TransportBinding failed.
    No Alternative matches
05/18/2020 10:26:52 *********************
Output from Web service with SOAP action = "Test"
<?xml version='1.0' encoding='UTF-8' standalone='no' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:s='http://www.w3.org/2001/XMLSchema' >
  <SOAP-ENV:Body>
    <SOAP-ENV:Fault>
      <faultcode>SOAP-ENV:Server</faultcode>
      <faultstring>Serverapplikationsfehler</faultstring>
      <detail>
    <error xmlns='http://soap.sforce.com/2005/09/outbound'>
     <text>FEHLER #6454: Keine unterstützte Richtlinienalternative in Konfiguration OBG.EnsWSP.EnsBS.SFSoapServiceConfig:service.</text>
    </error>
</detail>
    </SOAP-ENV:Fault>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

After some Help, we found the issue to be in a misconfiguration of the webapplication, which somehow broke the policy validation