I am using WSO2 Identity Server 4.1.0. I have successfully followed the steps described here (thank you) to get a local SAML2 consumer to work with a local WSO2 Identity Server.
The steps mentioned above describe using a Tomcat webapp to 'call' the login page of the WSO2 Identity server, using a SAML request. The webapp will also receive a SAML response. The webapp has to generate this SAML request, so that it contains a valid issuer, timestamp, etc. Without this request, the Identity Server will not provide a login page. So actually, the request is a sort of preperation. The SAML request is encoded.
My aim is to get a better understand of the way in which this webapp is composing the initial SAML request. I was only able to see the request, after using SAML debugger. How can I view this SAML request manually, using decoders?
What I have learned so far:
I have learned here that we can use SAML 2.0 Debugger to decode or encode the saml requests and responses. But I would like to how and what is getting encoded / decoded.
I have learned here that a URL decoder and Base64 decode might be needed. So I was able to URL decode the /samlsso?SAMLRequest. It contained an encoded assertionString. I was not able to Base64 decode this string.
Request HTTP Header:
This request is send to the WSO2 Identity Server.
https://localhost:9443/samlsso
POST /samlsso HTTP/1.1
Host: localhost:9443
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: https://localhost:9443/samlsso?SAMLRequest=jZPBbtswDIZfRdA9seO0WyzEKbIUxQx0m5u4O%2BymyswiQJY8kU6zt5%2Fs2GsORdCrSP7k%2F5Fa3p1qw47gUTub8dk05gyscpW2vzP%2BXD5MFvxutURZm0asWzrYLfxpAYmFOouiD2S89VY4iRqFlTWgICV262%2BPIpnGovGOnHKGszUieAqNNs5iW4PfgT9qBc%2Fbx4wfiBoRRcYpaQ4OSSziRRx1%2Bsm0gtpFaigKOkRev7QEZ50w6iCU2wpOwUUyT5Ob2%2FQm5ezBeQX94BnfS4PAWX6f8WAzx0Ii6iO8BRDboIEkLWU8iWfzSfx5EidlnIp5Ima300%2Bz9BdnxeDoi7ZnTtfsv5yTUHwty2JS%2FNiVnP0ceYcEPtLtu%2FuPc5UjTb56o7SMLsVG6e%2BhOL8vnNHqL1sb4143HiQF5%2BRb6CHVkq636150Ndn3qaLpHCCBJc52Raf%2F1Eqj9xp8xvNuMh6N3YeLgapfQ9gZwYnYxtWN9Bo7DHCSigYQ4jJrY4LLLewvqHwYytU0JVQnHZ67I3h1vuqWCipMWXppsXGezizfnWc1cn7X2%2F%2Fo5YdZ%2FQM%3D&RelayState=null
Cookie: MSG13721655096400.5456646701125957=true; MSG13721655827030.13073174051588388=true; MSG13721677790000.949325276640498=true; menuPanel=visible; menuPanelType=main; current-breadcrumb=manage_menu%2Cmanage_saml_sso%23; requestedURI=../../carbon/admin/index.jsp; Modernizr=; JSESSIONID=E4B3DB007762167497588E63D2C396F6; MSG13727573306230.10612530425878663=true; region1_manage_menu=visible; ssoTokenId=E4B3DB007762167497588E63D2C396F6
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 806
username=admin&assertnConsumerURL=http%3A%2F%2Flocalhost%3A8080%2Fsaml2.demo%2Fconsumer&issuer=saml2.demo&id=0&subject=null&relyingPartySessionId=null&assertionString=jZPBbtswDIZfRdA9seO0WyzEKbIUxQx0m5u4O%2BymyswiQJY8kU6zt5%2Fs2GsORdCrSP7k%2F5Fa3p1qw47gUTub8dk05gyscpW2vzP%2BXD5MFvxutURZm0asWzrYLfxpAYmFOouiD2S89VY4iRqFlTWgICV262%2BPIpnGovGOnHKGszUieAqNNs5iW4PfgT9qBc%2Fbx4wfiBoRRcYpaQ4OSSziRRx1%2Bsm0gtpFaigKOkRev7QEZ50w6iCU2wpOwUUyT5Ob2%2FQm5ezBeQX94BnfS4PAWX6f8WAzx0Ii6iO8BRDboIEkLWU8iWfzSfx5EidlnIp5Ima300%2Bz9BdnxeDoi7ZnTtfsv5yTUHwty2JS%2FNiVnP0ceYcEPtLtu%2FuPc5UjTb56o7SMLsVG6e%2BhOL8vnNHqL1sb4143HiQF5%2BRb6CHVkq636150Ndn3qaLpHCCBJc52Raf%2F1Eqj9xp8xvNuMh6N3YeLgapfQ9gZwYnYxtWN9Bo7DHCSigYQ4jJrY4LLLewvqHwYytU0JVQnHZ67I3h1vuqWCipMWXppsXGezizfnWc1cn7X2%2F%2Fo5YdZ%2FQM%3D&RelayState=null&password=admin
HTTP/1.1 200 OK
Set-Cookie: ssoTokenId=E4B3DB007762167497588E63D2C396F6; Expires=Tue, 02-Jul-2013 19:32:45 GMT
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Tue, 02 Jul 2013 09:32:45 GMT
Server: WSO2 Carbon Server
The 'referer' in the request above contains a SAML request, that was made visible by the SAML Debugger.
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="http://localhost:8080/saml2.demo/consumer" AttributeConsumingServiceIndex="1239245949" ForceAuthn="false" ID="0" IsPassive="false" IssueInstant="2013-07-02T09:32:15.619Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
<samlp:Issuer xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">saml2.demo</samlp:Issuer>
<samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" SPNameQualifier="Isser"/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
(It seems it is not the full SAML request yet, and that the WSO2 IS is composing the complete SAML Request internally.)
Response HTTP Header:
This is the response received from the WSO2 Identity Server.
http://localhost:8080/saml2.demo/consumer
POST /saml2.demo/consumer HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: JSESSIONID=E078F376C8ED303D28A200DD7AC28324; MSG13721655096400.5456646701125957=true; MSG13721655827030.13073174051588388=true; MSG13721677790000.949325276640498=true; menuPanel=visible; menuPanelType=main; current-breadcrumb=manage_menu%2Cmanage_saml_sso%23; requestedURI=../../carbon/admin/index.jsp; Modernizr=; MSG13727573306230.10612530425878663=true; region1_manage_menu=visible; ssoTokenId=E4B3DB007762167497588E63D2C396F6
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 1870
SAMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A%3Csaml2p%3AResponse+ID%3D%22dnfomflkhhdjjgfoggoagcdopgnjmpajenlehbka%22+IssueInstant%3D%222013-07-02T09%3A32%3A45.635Z%22+Version%3D%222.0%22+xmlns%3Asaml2p%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aprotocol%22%3E%3Csaml2p%3AStatus%3E%3Csaml2p%3AStatusCode+Value%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Astatus%3ASuccess%22%2F%3E%3C%2Fsaml2p%3AStatus%3E%3Csaml2%3AAssertion+ID%3D%22dgamkdkadflnniggkelmjfakjljedhfdhnbpomdk%22+IssueInstant%3D%222013-07-02T09%3A32%3A45.635Z%22+Version%3D%222.0%22+xmlns%3Asaml2%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion%22%3E%3Csaml2%3AIssuer+Format%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Anameid-format%3Aentity%22%3Ehttps%3A%2F%2Flocalhost%3A9443%2Fsamlsso%3C%2Fsaml2%3AIssuer%3E%3Csaml2%3ASubject%3E%3Csaml2%3ANameID%3Eadmin%3C%2Fsaml2%3ANameID%3E%3Csaml2%3ASubjectConfirmation+Method%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Acm%3Abearer%22%3E%3Csaml2%3ASubjectConfirmationData+InResponseTo%3D%220%22+NotOnOrAfter%3D%222013-07-02T09%3A37%3A45.635Z%22+Recipient%3D%22http%3A%2F%2Flocalhost%3A8080%2Fsaml2.demo%2Fconsumer%22%2F%3E%3C%2Fsaml2%3ASubjectConfirmation%3E%3C%2Fsaml2%3ASubject%3E%3Csaml2%3AConditions+NotBefore%3D%222013-07-02T09%3A32%3A45.635Z%22+NotOnOrAfter%3D%222013-07-02T09%3A37%3A45.635Z%22%3E%3Csaml2%3AAudienceRestriction%3E%3Csaml2%3AAudience%3Esaml2.demo%3C%2Fsaml2%3AAudience%3E%3C%2Fsaml2%3AAudienceRestriction%3E%3C%2Fsaml2%3AConditions%3E%3Csaml2%3AAuthnStatement+AuthnInstant%3D%222013-07-02T09%3A32%3A45.635Z%22%3E%3Csaml2%3AAuthnContext%3E%3Csaml2%3AAuthnContextClassRef%3Eurn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aac%3Aclasses%3APassword%3C%2Fsaml2%3AAuthnContextClassRef%3E%3C%2Fsaml2%3AAuthnContext%3E%3C%2Fsaml2%3AAuthnStatement%3E%3C%2Fsaml2%3AAssertion%3E%3C%2Fsaml2p%3AResponse%3E&RelayState=null
HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost:8080/saml2.demo/home.jsp?subject=admin
Content-Length: 0
Date: Tue, 02 Jul 2013 09:32:47 GMT
Here the SAMLResponse can be made visible by using a URL Decoder, for example this one.
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response ID="dnfomflkhhdjjgfoggoagcdopgnjmpajenlehbka" IssueInstant="2013-07-02T09:32:45.635Z" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion ID="dgamkdkadflnniggkelmjfakjljedhfdhnbpomdk" IssueInstant="2013-07-02T09:32:45.635Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://localhost:9443/samlsso</saml2:Issuer>
<saml2:Subject>
<saml2:NameID>admin</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="0" NotOnOrAfter="2013-07-02T09:37:45.635Z" Recipient="http://localhost:8080/saml2.demo/consumer"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2013-07-02T09:32:45.635Z" NotOnOrAfter="2013-07-02T09:37:45.635Z">
<saml2:AudienceRestriction>
<saml2:Audience>saml2.demo</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2013-07-02T09:32:45.635Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
</saml2p:Response>
Even if this thread is old, I run into a similar Issue with the newer 5.1.0 Identity Server.
The SAMLRequest Url Parameter is decodable by first URL decode it and then Base64 inflate it e. g. on https://www.samltool.com/decode.php
There are other parameters in the Url, normally separated by "&" which must be excluded to get a successful decoding. In your example especially the "&relayState=null" at the end has to be excluded for decoding.
A redirect Binding would additionally have the deflated signature and the used digest algorithm as parameter.
This is the decoded and inflated result of the SAMLRequest param taken from question Code Snippet 1, it should cover the result from your SAML Debugger.
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://localhost:8080/saml2.demo/consumer"
AttributeConsumingServiceIndex="1239245949" ForceAuthn="false" ID="0"
IsPassive="false" IssueInstant="2013-07-02T09:32:15.619Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0">
<samlp:Issuer xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">saml2.demo</samlp:Issuer>
<samlp:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
SPNameQualifier="Isser" />
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
Related
I'm trying to authenticate a user with JWT using GraphQL. Once I login the user I receive the token as a JSON response and a httponly cookie storing the refresh token. (Server-side is using Saleor-core)
From the documentation of Saleor and some other blog-posts I assume that this response cookie should now be stored in the browser and whenever I need to refresh a token the cookie-refreshToken is used to authenticate my request. However, when I switch tabs to "Application" in my dev tools it's just empty.
What is the normal behaviour of the browser after receiving a cookie response? Do I need some extra code to somehow "save" that response cookie?
Did not really find anyone else having this problem so I think the mistake must be somewhere else.
UPDATE
I read somewhere the issue might be that there is no "secure" flag, which resulted from the server debug mode. I turned it off, but the cookie is still not being set.
Response Headers:
HTTP/1.1 200 OK
Connection: keep-alive
Date: Thu, 23 Sep 2021 13:32:33 GMT
Server: uvicorn
Content-Type: application/json
Access-Control-Allow-Origin: https://rewhite-86006--beta-duoa0dwg.web.app
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: Origin, Content-Type, Accept, Authorization, Authorization-Bearer
Access-Control-Allow-Credentials: true
Content-Length: 912
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
Set-Cookie: refreshToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE2MzI0MDM5NTQsIm93bmVyIjoic2FsZW9yIiwiZXhwIjoxNjM0OTk1OTU0LCJ0b2tlbiI6Ijd2b0VmMm1DNlZZSyIsImVtYWlsIjoiSnVsaWFuLkZpbmtlQGdtYWlsLmNvbSIsInR5cGUiOiJyZWZyZXNoIiwidXNlcl9pZCI6IlZYTmxjam8zTmc9PSIsImlzX3N0YWZmIjpmYWxzZSwiY3NyZlRva2VuIjoiWm55ek9xVG9rOU9GYXlDZXY0cjFxMUxnaktnTXRRR0VNUVJEalR1eTJDZ1IyOW1GSVBxQ1B1T1hZcTFQNk92cyJ9.Cl6PmoLkO9Hlh36tDOuyNLQCib4FVBwn32hhnmd7Q4E; expires=Sat, 23 Oct 2021 13:32:34 GMT; HttpOnly; Max-Age=2592000; Path=/; Secure
Via: 1.1 vegur
Request Headers:
POST /graphql/ HTTP/1.1
Host: rewhite-saleor-engine.herokuapp.com
Connection: keep-alive
Content-Length: 318
Pragma: no-cache
Cache-Control: no-cache
sec-ch-ua: "Google Chrome";v="93", " Not;A Brand";v="99", "Chromium";v="93"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36
sec-ch-ua-platform: "macOS"
content-type: application/json
Accept: */*
Origin: https://rewhite-86006--beta-duoa0dwg.web.app
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://rewhite-86006--beta-duoa0dwg.web.app/
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Thanks for your help!
The Domain attribute on you cookie seems to be different from the origin of your request. You're making a cross-site request and receiving a Set Cookie response from the server (of a different domain).
Normally we run into this issue when running backend and frontend on different domains (for e.g. localhost:3000 and localhost:8080).
Solution:
Recent Chrome browser versions (from 2020) will only set cookies received from cross-site requests if cookie has SameSite=None and Secure attributes set. With Secure set, a cookie will only be sent to server over HTTPS protocol (you need to implement SSL).
As of now, you don't have set either. SameSite defaults to Lax not None. You need to explicitly set it.
OR
You need implement a proxy such that you will request your webapp on https://rewhite-86006--beta-duoa0dwg.web.app and your webapp will proxy this to your Saleor engine domain rewhite-saleor-engine.herokuapp.com. How you do that depends on what frameworks you're using for serving your webapp. You haven't mentioned your it in your question, but I notice you've tagged it under vue.js, so I'll assume that you're using Vue CLI for serving a Vue app.
Its very simple to set up a proxy with Vue CLI. Just look for vue.config.js file in your root directory. If its not there, create it and paste the code below:
module.exports = {
devServer: {
proxy: {
'^/graphql': {
target: 'https://rewhite-saleor-engine.herokuapp.com',
changeOrigin: true,
logLevel: 'debug',
},
},
},
}
Now instead of fetching the refreshToken from rewhite-saleor-engine.herokuapp.com/graphql, you should send the request to your webapp at https://rewhite-86006--beta-duoa0dwg.web.app/graphql, and your web app local server will forward the request to your Saleor backend on Heroku. To your browser it will appear as though the request's response came form the webapp itself, so it won't be a cross-site request anymore.
I'm having a problem with a web add-in for Outlook.
The Outlook client is 2016 (MSI) which I believe means that it supports no higher than JavaScript API 1.4, opposed to Outlook 2016 (C2R) which, as I recall it, supports JavaScript API 1.6 or maybe even higher.
Anyway, I'm trying to use the method Office.context.mailbox.getCallbackTokenAsync(asyncResult) which has previously worked just fine on the server where it is used, but now it has stopped working for some odd reason.
The asyncResult is now empty or rather the token is empty.
{"value":"","status":"succeeded"}
How can the token be empty all of the sudden when this add-in used to work perfectly?
According to the admin of the server, it has received Windows updates on the date that this stopped working for both Office and Outlook specifically.
The Outlook clients connect to an Exchange 2013 (CU7 December 9, 2014 : 15.0.1044.25) which has also received some updates.
Both servers have been rebooted since then, but nothing has changed. The token remains empty.
Can anyone shed some light on what could be the cause of this if anyone knows that is, because all I can really do myself at this point is guess?
UPDATE 1
I have now been given permission to install Fiddler and I have found the request and respond regarding the attempt to retrieve the token.
Can any of you who know the Exchange server inside out see what is going on here, because I don't see any reasoning as to what is failing, except that the response message indicates that the request is faulty somehow (which hasn't been changed for more then a year at least).
Here is the request (some names have been replaced with something generic).
REQUEST
POST https://<domain>/ews/Exchange.asmx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: text/xml; charset=utf-8
User-Agent: Microsoft Office/16.0 (Windows NT 6.3; Microsoft Outlook 16.0.4849; Pro)
X-User-Identity: <account>#<domain>.com
Depth: 0
Content-Length: 801
Host: <host>
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAJ4AAABCAUIBtgAAAAAAAABYAAAANAA0AFgAAAASABIAjAAAABAAEAD4AQAAFYKI4gYDgCUAAAAPGSbYTqZVeCx7cnQxM336pnMAeQBzAHQAZQBtAGMAbwBuAG4AZQBjAHQAQABlAHMAdABpAGMAaABlAG0ALgBjAG8AbQBFAFMAVABJAC0AQwBUAFgAMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT6dTWGCCv/rRor0Srrxd9AQEAAAAAAADJcWWYQo7VATtznMo8smALAAAAAAIACABFAFMAVABJAAEAFABFAFMAVABJAC0ARQBYAEMASAAxAAQAFABFAFMAVABJAC4AbABvAGMAYQBsAAMAKgBFAFMAVABJAC0ARQBYAEMASAAxAC4ARQBTAFQASQAuAGwAbwBjAGEAbAAFABQARQBTAFQASQAuAGwAbwBjAGEAbAAHAAgAyXFlmEKO1QEGAAQAAgAAAAgAMAAwAAAAAAAAAAAAAAAAIAAA77CK35CNnSd54Hy6NnToh6W3Oxa6tsihxlCrQ8jwDWMKABAARs+Rq8MKQZq+cmQJ8nL9/gkALABIAFQAVABQAC8AbQBhAGkAbAAuAGUAcwB0AGkAYwBoAGUAbQAuAGMAbwBtAAAAAAAAAAAAeHckPR2HOLOW0y2ri7TR1A==
Cookie: OutlookSession="{994C5944-A93C-4830-9E6F-605881790815}"; ClientId=PRHSVIWKYUDISQLQPQ
<?xml version="1.0"?>
<q:Envelope
xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:q="http://schemas.xmlsoap.org/soap/envelope/">
<q:Header>
<ex12t:RequestServerVersion Version="Exchange2012"></ex12t:RequestServerVersion>
</q:Header>
<q:Body>
<ex12m:GetClientAccessToken>
<ex12m:TokenRequests>
<ex12t:TokenRequest>
<ex12t:Id>214c1212-e3ff-45eb-9218-2deb35d6b8b9</ex12t:Id>
<ex12t:TokenType>ScopedToken</ex12t:TokenType>
<ex12t:Scope>ParentItemId:AAMkADRiMzkyMjhmLWQ1NGItNDY0Mi04Nzk0LWYyNzMzZWQ2ZGE5MABGAAAAAAApHj7qoKF1QY4+pcwfu7uCBwCHPrayw2+bT5ByF4j5Y8QZAAAAAAEMAACHPrayw2+bT5ByF4j5Y8QZAAAAAAFxAAA=</ex12t:Scope>
</ex12t:TokenRequest>
</ex12m:TokenRequests>
</ex12m:GetClientAccessToken>
</q:Body>
</q:Envelope>
RESPONSE (some names have been replaced with something generic).
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/8.5
request-id: 1a7cbf79-8ba3-4a73-bfa2-1733d841b2b1
X-CalculatedBETarget: <server>.local
X-DiagInfo: <server>
X-BEServer: <server>
X-AspNet-Version: 4.0.30319
Set-Cookie: exchangecookie=2cd797c5290345a7861dfe60e16ecc12; expires=Thu, 29-Oct-2020 10:21:15 GMT; path=/; HttpOnly
Set-Cookie: X-BackEndCookie=S-1-5-21-2060358956-2462126529-2132206371-1263=u56Lnp2ejJqBmpzHns+cypzSncaZzdLLmprH0p3HxsvSm5yaycuazMieys/MgYHNz87G0s7O0s3Hq87Pxc3Oxc7K; expires=Thu, 28-Nov-2019 09:21:15 GMT; path=/ews; secure; HttpOnly
Persistent-Auth: true
X-Powered-By: ASP.NET
X-FEServer: <server>
Date: Tue, 29 Oct 2019 10:21:15 GMT
Content-Length: 1148
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<h:ServerVersionInfo MajorVersion="15" MinorVersion="0" MajorBuildNumber="1044" MinorBuildNumber="21" Version="V2_22"
xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</s:Header>
<s:Body
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<m:GetClientAccessTokenResponse
xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<m:ResponseMessages>
<m:GetClientAccessTokenResponseMessage ResponseClass="Error">
<m:MessageText>The token for this extension could not be retrieved.</m:MessageText>
<m:ResponseCode>ErrorInvalidClientAccessTokenRequest</m:ResponseCode>
<m:DescriptiveLinkKey>0</m:DescriptiveLinkKey>
</m:GetClientAccessTokenResponseMessage>
</m:ResponseMessages>
</m:GetClientAccessTokenResponse>
</s:Body>
</s:Envelope>
I'm trying to create a user using the SaonarQube API (version 6.2 or up).
I have setup a SoapUI project that contains a few test scripts. One of them is login in and creating a user. this one returns a 401 whe the user creation call is done.
The login is used for other calls as well and proves to work. Except for the create user call. The account used to login to SoarQube is member of the System Administror groups.
Below is the raw request.
POST http://localhost:9000/api/users/create HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 47
Host: localhost:9000
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Cookie: JWT-SESSION=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJBV0ExaGFtX2hnNWdHUWtNNVRHSiIsInN1YiI6ImFkbWluIiwiaWF0IjoxNTEyNzI2NDQwLCJleHAiOjE1MTI5ODU2NDAsImxhc3RSZWZyZXNoVGltZSI6MTUxMjcyNjQ0MDM4MywieHNyZlRva2VuIjoicHRwcXRlYmtzYTR2MTlhaTk3anV0bnVlZW8ifQ.waHqOsMJ9P6FyIOUWuVODl5QcW-IJp10G6oUAvy1DWk; XSRF-TOKEN=ptpqtebksa4v19ai97jutnueeo
Cookie2: $Version=1
login=user01&name=name01&password=%21P%40ssw0rd
Below is the raw resoonse
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Length: 0
Date: Fri, 08 Dec 2017 09:47:20 GMT
Any suggestions are welcome.
BTW: I can create the user using the same values using the UI so there is no issue with he user information, at least it seams so.
Update 1:
Added raw request with querystring parameters
POST http://localhost:9000/api/users/create?login=user01&name=name01&password=%21P%40ssw0rd HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Host: localhost:9000
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Cookie: JWT-SESSION=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJBV0JHZkVGY0h3bW5UZ0V5QklJNyIsInN1YiI6ImFkbWluIiwiaWF0IjoxNTEzMDExMDM2LCJleHAiOjE1MTMyNzAyMzYsImxhc3RSZWZyZXNoVGltZSI6MTUxMzAxMTAzNjQyNCwieHNyZlRva2VuIjoibmIzdmlpcjAyZmZ1ODJnMzNtdW1hYWdkN3QifQ.ur8eZkW1CwNinx4tInFsbkGLQTHQ6yFjheRfup8Z4fQ; XSRF-TOKEN=nb3viir02ffu82g33mumaagd7t
Cookie2: $Version=1
It's not possible to use the generated cookie by a web request in a console request (it could be considered as an attack).
You need either to :
Specify a user token (recommended way)
Specify a login/password
I need to configure Burp Suite to intercept data between web browser and proxy server. The proxy server requires a basic authentication (Username & Password) while connecting for the first time in each session. I have tried the 'Redirect to host' option in Burp Suite(Entered the proxy server address and port in the fields):
Proxy >> Options >> Proxy Listeners >> Request Handling
But I can't see an option to use the authentication that is required while connecting to this proxy server.
While accessing google.com, the request headers are:
GET / HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0 (X11; Linux i686) KHTML/4.13.3 (like Gecko) Konqueror/4.13
Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8
Accept-Encoding: gzip, deflate, x-gzip, x-deflate
Accept-Charset: utf-8,*;q=0.5
Accept-Language: en-US,en;q=0.9
Connection: close
And the response is:
HTTP/1.1 400 Bad Request
Server: squid/3.3.8
Mime-Version: 1.0
Date: Thu, 10 Mar 2016 15:14:12 GMT
Content-Type: text/html
Content-Length: 3163
X-Squid-Error: ERR_INVALID_URL 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from proxy.abc.in
X-Cache-Lookup: NONE from proxy.abc.in:3343
Via: 1.1 proxy.abc.in (squid/3.3.8)
Connection: close
you were on the right track, just at the wrong place. You need to setup an upstream proxy at:
Options>>Connections>>Upstream proxy
There you can also setup the authentication
Options>>Connections>>Platform authentication
Here you can create different auth configurations, which will be done if the server requests it.
I've a DotnetOpenAuth authorization server which works great on my localhost. However after publishing it my refresh access token request is blocked.
The request for a accesstoken, with success
POST https://myurl/identity/oauth/token HTTP/1.1
Authorization: Basic dsjSDLFJKSKLJesww
Content-Type: application/x-www-form-urlencoded; charset=utf-8
User-Agent: DotNetOpenAuth.Core/4.2.1.13026
Host: myhost
Cache-Control: no-store,no-cache
Pragma: no-cache
Content-Length: 86
Expect: 100-continue
Connection: Keep-Alive
username=theusername&password=fancypassword&scope=somescope&grant_type=password
The refresh request:
POST https://myurl/identity/oauth/token HTTP/1.1
Authorization: Basic dsjSDLFJKSKLJesww
Content-Type: application/x-www-form-urlencoded; charset=utf-8
User-Agent: DotNetOpenAuth.Core/4.2.1.13026
Host: myhost
Cache-Control: no-store,no-cache
Pragma: no-cache
Content-Length: 272
Expect: 100-continue
refresh_token=_ttH%21IAAAAGiYhlufAaXURH5P2oDOnPYgJx7YhoR33isvZkPPvlyUgQAAAAHoBYyDMLhq1qwGHHH2uGrLoHZli77XHbCnSFJSKLFJ3kl2j3klj2kljKFSJKLSJKL#$k3ljfsklfjl2
And the response:
Technical Information (for support personnel)
Error Code: 403 Forbidden. The server denied the specified Uniform
Resource Locator (URL). Contact the server administrator. (12202)
Any help, guidelines, pointers in any direction, would be very much appriciated!
I changed the url/username/password/scope/base64/refreshtoken for this example.
Their seems to be a setting in the TMG Forefront - Authentication Delegation which blocked the request.
Method used by Forefront TMG to authenticate to the published Web
server:
No delegation, and the client cannot authenticate directly
No delegation, but client may authenticate directly
It was set to option 1 after changing it to 2 the request is no longer blocked!