function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Rene HernandezRene Hernandez 

Apex Soap call authentication problem

Has anyone encountered an issue with wsse authentication for soap calls in apex?   We have made sure that the password digest and credentials are correct.

authentication works in SoapUi, but fails from our apex class. 

Ideas would be great as we are pulling our hair trying.
Andy BoettcherAndy Boettcher
Do you have the endpoint URL added in Remote Sites?
Rene HernandezRene Hernandez
Yes, we added endpoint URL to Remote Sites.
Andy BoettcherAndy Boettcher
What error message are you getting when you do the callout in APEX?
Rene HernandezRene Hernandez
500 internal server error..not able to authenticate toKen
Andy BoettcherAndy Boettcher
Can you system.debug out the XML request w/ header out of your code in Salesforce before it's send and compare it to what you're sending through SoapUI and look for differences?
Rene HernandezRene Hernandez
I am creating the SOAP request through String concatenation so there is no
problem on Syntax or format of the SOAP request
 
Rene HernandezRene Hernandez
<soapenv:Envelope xmlns:opt="http://www.opterus.com" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header>
      <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-5FC79CA1C1AD86A37D1446828793286134">
            <wsu:Created>2015-11-06T16:53:13.286Z</wsu:Created>
            <wsu:Expires>2015-11-06T16:54:13.286Z</wsu:Expires>
         </wsu:Timestamp>
         <wsse:UsernameToken wsu:Id="UsernameToken-5FC79CA1C1AD86A37D1446828790507133">
            <wsse:Username>aritziaso:rhernandez</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">brdMvC/v5AYKOCw9UPxtlD+JzPg=</wsse:Password>
            <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">3O+y2ndmH878pCfjSAOccg==</wsse:Nonce>
            <wsu:Created>2015-11-06T16:53:10.507Z</wsu:Created>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>

==================================

See the above request..the problem is in Security header for password digest. We calculate the password digest... through  below  methods in apex code:

String x=nonce+datetimestamp+'pwd';
Blob hash = Crypto.generateDigest('SHA1', Blob.valueOf(x));
 String digest= EncodingUtil.base64Encode(hash);


This password digest is not matching with password digest calculated in SOAP. it this gets matched..issue will get solved.

You can have an idea of this security protocal oat below link:

http://www.herongyang.com/Web-Services/WS-Security-Username-Token-Profile.html

 
James LoghryJames Loghry
Looks like it might boil down to the Created element.  Have you verified that's the correct format to use?  I don't see the milliseconds in the example of the link you mentioned.  Additionally, the created date that you're passing in to the generateDigest method along with the created element in your request have to match up exactly.  This means you can't call Datetime.now() more than once, you'll have to use a variable with the same date time for the Blob generation and in your Created element in your xml.

I would take a close look at your crypto and base64 encoding with a fine tooth comb and you'll likely find the culprit (eventually :)).  Along the way, I would compare that what you have in Salesforce matches verbatim with what you're using in SoapUI (you can fake the dates if you need to)​
Rene HernandezRene Hernandez
Correct, the nonce and createddate should be same in the xml request where the
password digest is caculated.

I also agree that createddate could be the culprit so I tried both with and without milliseconds.

What I finally figured out was that Salesforce was not generating correct password digest.  I took nonce and created date from soap ui request and tried calculating password digest in anonymous apex with those 3 lines of code I posted in last reply. But the password digest calculated in apex did not match the Soap ui passwore digest.

This only seems to be the issue. If we can somehow calculate the same password digest as in Soap ui..this issue will be solved!   
Prakhar Tripathi 8Prakhar Tripathi 8
Hey Rene were you able to fix this? I am running into a similar issue. Any help would be appreciated.

Thanks in Advance
 
Raja Kar 5Raja Kar 5
Any update on above issue. I am also facing same issue.