Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No support for WSSE authorization type #2762

Open
vaishnavidesai opened this issue Feb 27, 2017 · 11 comments
Open

No support for WSSE authorization type #2762

vaishnavidesai opened this issue Feb 27, 2017 · 11 comments

Comments

@vaishnavidesai
Copy link

  1. Postman Version: 4.10.2
  2. App (Chrome app or Mac app): Chrome App
  3. OS details: x86-64
  4. Is the Interceptor on and enabled in the app: Yes
  5. Did you encounter this recently, or has this bug always been there: Feature not present in postman at all.
  6. Expected behaviour:
  7. Console logs (http://blog.getpostman.com/2014/01/27/enabling-chrome-developer-tools-inside-postman/ for the Chrome App, View->Toggle Dev Tools for the Mac app):
  8. Screenshots (if applicable)

My automated API testing involves working with APIs which use an authorization method called WSSE.
The authentication happens using below parameters:

X-WSSE: UsernameToken Username="", PasswordDigest=" ", Nonce=" ", Created=" "

I didnt find a way in Postman that can help me do this.
Any help is greatly appreciated.
Thanks.

@MichalFoksa
Copy link

Please add it also into stand alone Postman apps (Win, Mac, ...).

@whiteatom
Copy link

Same issue.. new to Postman and was disappointed not to find WWSE as an option. I'm going to try emulating with manual headers and I'll let you know how it goes.

@safaiyeh
Copy link

Has this been addressed?

@vaishnavidesai
Copy link
Author

vaishnavidesai commented Apr 10, 2018 via email

@whiteatom
Copy link

sooooooo you're just going to close the issue? Does this mean that it's not going to be addressed?

@a85 a85 self-assigned this Jun 29, 2018
@Briones
Copy link

Briones commented Jul 17, 2018

For the moment you can copy this full script:
https://github.com/vrruiz/wsse-js/blob/master/wsse.js
And add it to the Pre-request script section, then at the end you can do something like this:

var wsseHeader = wsseHeader(pm.environment.get("wsse-user"), pm.environment.get("wsse-secret")); pm.environment.set("wsse-header", wsseHeader);

Assuming that you already created the variables wsse-user and wsse-secret and you already set {{wsse-header}} as value in the X-WSSE header.

That works for me as workaround after trying without success to make a Pre Request script with the CryptoJS that is embedded in Postman.

@tparikka
Copy link

This may be useful to someone. I'm connecting to a WCF SOAP service and was running into this error when trying to cut out the headers:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
    <s:Header>
        <a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:Action>
        <a:RelatesTo>{{guid}}</a:RelatesTo>
    </s:Header>
    <s:Body>
        <s:Fault>
            <s:Code>
                <s:Value>s:Sender</s:Value>
                <s:Subcode>
                    <s:Value xmlns:a="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">a:InvalidSecurity</s:Value>
                </s:Subcode>
            </s:Code>
            <s:Reason>
                <s:Text xml:lang="en-US">An error occurred when verifying security for the message.</s:Text>
            </s:Reason>
        </s:Fault>
    </s:Body>
</s:Envelope>

In my case, I got around the issue by setting the following in the soap:Header section of my request body:

<soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
	<wsse:Security soap:mustUnderstand="true" 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:Created>{{currentTime}}</wsu:Created>
			<wsu:Expires>{{newTime}}</wsu:Expires>
		</wsu:Timestamp>
		<wsse:UsernameToken>
			<wsse:Username>{{UserUsername}}</wsse:Username>
			<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">{{UserPassword}}</wsse:Password>
		</wsse:UsernameToken>
	</wsse:Security>
	<wsa:Action soap:mustUnderstand="1">http://mydomain.com/IMyService/MySoapAction</wsa:Action>
	<wsa:ReplyTo soap:mustUnderstand="1">
		<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
	</wsa:ReplyTo>
	<wsa:MessageID soap:mustUnderstand="1">{{guid}}</wsa:MessageID>
	<wsa:To soap:mustUnderstand="1">https://mydomain.com/myservice.svc/myservice.svc</wsa:To>
</soap:Header>

My prerequest contains:

var moment = require('moment');

var now = moment().toISOString()
var exp = moment().add(5, 'minutes').toISOString();

pm.environment.set('currentTime', now);
pm.environment.set('newTime', exp);

@munkiepus
Copy link

munkiepus commented Apr 17, 2019

ive also created a wsse-header generating pre-request script which uses sha512 with multiple iterations for postman
https://github.com/munkiepus/wsse-sha512-js/blob/master/wsse-sha512.js

@everm1nd
Copy link

@munkiepus thanks for the script and idea with pre-request hook. it solved my issue. unfortunately original code wasn't working for me, so I wrote my own version: https://gist.github.com/everm1nd/1f0eee4df9d6369da9e0fad3d7529044

@YashPethe
Copy link

Hey. I found a solution, just put this on request body

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">
wsse:UsernameToken
wsse:UsernameXXXXX</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">XXXXX</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>

@tparikka
Copy link

@YashPethe That is only a partial solution and does not encompass all the security features that a service might require, such as timestamps, nonces, and more. Also that XML is malformed and wouldn't be accepted, as some of the tags are missing brackets or are mismatched.

@vvs11 vvs11 added this to Pending triage in Runtime Triage and Development Mar 12, 2020
@saswatds saswatds moved this from Pending triage to Later in Runtime Triage and Development Mar 12, 2020
@giridharvc7 giridharvc7 added the New Auth Type New type of authorization label Apr 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests