I have IFRAME application defined for SSO over OAuth within NetSuite - SuiteSignOn.
OAuth process finished successfully. I got oauth token.
When call first methods in NetSuite (such as get opportunity) with bearer in authorizaiton header I got really strange error :
USER_ERROR
You have a web browser version that we do not support.To use the system, you will first need to http://www.microsoft.com/windows/ie/default.htm>upgrade your web browser software.partners-java10002.bos.netledger.com
I am using Chrome Version 36.0.1985.125 m for this test case
On NetSuite supported web browsers page is written that Google Chrome 35.x is supported.
(https://system.netsuite.com/core/media/media.nl?id=7375407&c=NLCORP&h=a66f026635e85ddaf43a&_xt=.pdf)
Value that I provided for authorization header :
OAuth oauth_token="token", oauth_consumer_key="key", oauth_signature_method="PLAINTEXT", oauth_signature="secret", oauth_timestamp="1406638355", oauth_nonce="1406638355"
What I am doing wrong ?
The most important is that all of this was working before NetSuite 2014 release.
I am using also support for getting NetSuite's data center awareness web service url.
Solution for this is to set webRequest.Headers["User-Agent"] to null when calling NetSuite SOAP API.
Related
I am developing a performance test script for hybrid mobile application using Rational Performance Tester V9.0 & V8.7.
The mobile application sends the request to IBM Mobile First Server v8.0 which authenticates its user using OAuth with JWT (JSON Web Token).
I tried enhancing the script and replayed but it fails at login step in an API which requests for token /mfp/api/az/v1/token
Below mentioned is the request & response for the API call,
URI: POST /mfp/api/az/v1/token
Request:
client_assertion=eyJhbGciOiJSUzI1NiIsImp3ayI6eyJhbGciOiJSUzI1NiIsImUiOiJBUUFCIiwiZXh0Ijp0cnVlLCJrZXlfb3BzIjpbXSwia3R5IjoiUlNBIiwibiI6IjAtX19nSjFLWnZsVlU5M1JGRlFuZk80TGdLeUhTN3hIMVg3RUw2ZGhKa1B6SGQ0cUhEaHdFQzFIT0k0cHhmeEMzZWh6M1I3cXQtU3A5WnpOb3o4Z1lDTVRmSmh3T21OZWh5dkNkMDU3V09PVjB1b0ZPQmFpS21pMG9qdHJoMFMzMlNuS1VWTElwekxhQUZJSkhsOGtCSm9sZ21JQW9hZHNRdFpTUWg0MVJZN2c3aWNCUzlJRkRCdGdDbUtjRHlRY29VSnpTWkIxZk1ZY2VYNGFBNDZ3elkwRkdaY3hxcG11U1kwV0xCTEhDUjdLSm9oa2wwZDk4OFlSVGtuQkE3dFBLTEF4RnQxT2daQ1BYR1owWW41ZHFKN3ZwWXZtd21hc09vSFNacWp3cktMOW51MDR0QUZ1OENHZ3ZrTnZPUmJjRFRQaElvcy1iQ0J0ZFhXZjBWek1uUSIsImtpZCI6IjYxZWNkMjY2LTNjYTItNDhlYy04M2M2LTY3MTk5MGVjNzdlOCJ9fQ%3D%3D.eyJpc3MiOiJlQmFua2luZyR3ZWIiLCJzdWIiOiI2MWVjZDI2Ni0zY2EyLTQ4ZWMtODNjNi02NzE5OTBlYzc3ZTgiLCJleHAiOjE1Mzk3Nzc3NjMxNzQsImlhdCI6MTUzOTc3NzcwMzE3NCwianRpIjoiLTQ0NjkwNTY3Njc4NzAzMTYyNzEiLCJhdWQiOiJhei92MS90b2tlbiJ9.nMcfmOPDcLjONOXhF%2B3mArM87AiPfqEPp5Bk815f9Dg7VaaIgY41jeSmlWASCdmjf9Cno3%2BwHGom%2BzAEGQDdFkmBjLpCY7TnCAv9j8HzIPDubYdSQW2pq7WKVz%2FvEQ8Z5Pa8jh8aAMTlrsBnjlPoiVfcqHBh%2F2vpHZnKvkSoCOcA2TAeJnioSlp4vpWOc26IsMwKYMqZlVs9K2Z8JwHQvESKlzDu9etxYnnQfxyqunwhG%2B5T9GKgMmCAo1%2BBGqqsEtTwOG5UmhoyYIYbMnNHzHFdl8fWwMMOtpf%2F3RqjBYNeAsZ%2BTuGkskLlA5hrLiHmfOhzPYstr8tCO2IMLbTpjQ%3D%3D&code=5059335353176972418&grant_type=authorization_code&redirect_uri=https%3A%2F%2Fuatirmob.qcdib.com%2Fmfp%2Fapi%2Faz%2Fv1%2Fauthorization%2Fredirect%2F17553a31-f583-44f9-9b7a-d8fab31b3bff&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
Response:
{"errorCode":"invalid_client","errorMsg":"Incorrect JWT format"}
I noticed that the client_assertion value carries dynamic data in JSON form when I decrypted with https://jwt.io/#debugger
Also, developed encryption logic mentioned in IBM mobile first site to generate the client_assertion value referring this link: https://mobilefirstplatform.ibmcloud.com/blog/2016/08/09/performance-testing-for-mobilefirst-foundation-8-0/
It was not successful after following the above steps.
Please provide solution to handle the /mfp/api/az/v1/token request and generate access token which will passed in the subsequent requests.
Thanks in advance.
We have documented performance testing instruction for JMeter.
Please refer to link here for more details - https://mobilefirstplatform.ibmcloud.com/blog/2016/08/09/performance-testing-for-mobilefirst-foundation-8-0/
Please refer to section "Sign grant code" and ensure you are following steps properly [ https://mobilefirstplatform.ibmcloud.com/blog/2016/08/09/performance-testing-for-mobilefirst-foundation-8-0/#sign-grant-code ]
Try the latest Mobilefirst v8 build (late Oct 2018) which will fix this.
I am trying to create an application using the WooCommerce RESTful APIs. I have embedded the AFOAuth1Client for the OAuth authentication but, every time I make a service call for a path, say "products, I get an invalid signature error from WooCommerce. I hit this error only when the WooCommerce RESTful APIs version is v3(EX: http://localhost/wordpress/wc-api/v3). But, if I use v2, I get the response and can see the list of products available. How can I go about making this to work?
Thanks
Keycloak, WSO2 and some other SSO IDP servers offer a possibility of "Single Logout" without forcing browser to redirect to every SP where current user is logged in by sending the <LogoutRequest> over HTTP-POST via back channel.
Unfortunately this does not work if SSO integration in the service is implemented using spring-security-saml2-core library (we are using Keycloack).
All I could figure out from the log file on the SP side was:
[2016-01-13 12:50:56.867] [DEBUG] [org.springframework.security.saml.SAMLLogoutProcessingFilter] - Received logout request is invalid, responding with error
org.springframework.security.saml.SAMLStatusException: No user is logged in
at org.springframework.security.saml.websso.SingleLogoutProfileImpl.processLogoutRequest(SingleLogoutProfileImpl.java:168)
at org.springframework.security.saml.SAMLLogoutProcessingFilter.processLogout(SAMLLogoutProcessingFilter.java:176)
at org.springframework.security.saml.SAMLLogoutProcessingFilter.doFilter(SAMLLogoutProcessingFilter.java:102)
...
The application that uses Spring SAML extension is deployed on the Tomcat 7. It seems that <LogoutRequest> when sent via back-end channel does not have a browser session cookie, and user application session cannot be identified, so user cannot be logged out and the application session of the user will not be invalidated.
However the <LogoutRequest> contains the global SSO session identifier which can uniquely identify the application session. But this does not happen.
Is this behavior of the Spring SAML library intended by desing: do not support back-end communication during Single Logout? or am I missing something and the desired behavior can be configured?
Note: I understand that according to SAML specification HTTP-POST and HTTP-Redirect bindings are intended to be carried via User Agent (web browser), however broad support from SSO IDP servers made me ask this question :)
Thank you in advance!
UPDATE: According to Vladimir Schäfer's comment in the SES-162 ticket it seems to be an intended library behavior.
In Spring-SAML, Single Logout is currently supported with HTTP-Redirect and HTTP-POST bindings. SOAP binding is not available. Refer : Spring SAML Global Logout
Back channel is not supported in spring-saml
No, it is not possible to carry out <LogoutRequest> over HTTP-POST via back channel using Spring-SAML library.
This behavior is against SAML specification and according to Vladimir Schäfer's comment in the SES-162 ticket it will not be supported by Spring-SAML.
SOAP binding is meant for backend channel, but as it is noted by #meetarun it is not implemented in Spring-SAML library at the moment.
We are trying to incorporate the Google+ SignIn button for authentication to our IOS client and python tornado REST Server.
On the IOS client, we followed the "Enable server-side API access for your app" in https://developers.google.com/+/mobile/ios/sign-in. We set the clientID to the Google+ IOS Client and the homeServerClientID to our web server Google+ Web client id.
Then on our tornado werver, we used the python google+ client and did:
oauth_flow = flow_from_clientsecrets(GOOGLE_CLIENT_SECRET, scope='email')
oauth_flow.redirect_uri = 'postmessage'
credentials = oauth_flow.step2_exchange(code)
So the IOS client works fine, it authenticates, gets the one time token in homeServerAuthorizationCode. It sends this to the REST API and it produces an exception:
File "/usr/lib/python2.6/site-packages/oauth2client/client.py", line 1964, in step2_exchange
raise FlowExchangeError(error_msg)
FlowExchangeError: redirect_uri_mismatch
We have tried to use difference codes, double and triple checked the client ids in the clientsecrets, IOS and tornado code and they are all correct.
Any ideas?
It is likely that it's not happy with the redirect URI on the server side. 'postmessage' is absolutely right for the web flow, but for iOS try either not specifying redirect_uri at all, or using 'urn:ietf:wg:oauth:2.0:oob' (oob being "out of browser") for the redirect_uri.
I have a working OAuth process for authorizing with Google. My app can get data from the Google Sites API from areas that only the account used to authorize it has access, so I know that much is working. The trouble is creating new data via the API. I consistently get "Unknown authorization header" when trying to POST to the endpoint. The real frustration appears when I try to use the Google Oauth Playground. I put in the credentials I have, put in the same endpoint and same request body, and try it there -- and everything works perfectly.
I'm using Ruby 1.9.3 on the API side, and I've tried with both oauth-ruby and the Google-written signet client. Both do the same thing. I've verified and re-verified that the credentials are as I expect them to be (both just checking, and using the same ones in the Oauth Playground and seeing them work).
I have no idea why this is happening, because there's precious little information coming from Google's API about what's actually wrong with my request.
For the record, I'm using;
Ruby 1.9.3
oauth-ruby and signet for clients
OAuth 1.0
HMAC-SHA1 hashing
3-legged authorization
As it turns out, the problem was because I was failing to include the Content-Type header in the request. Yes, this didn't make any sense to me, either, considering the error message, but that's what it was.