How do I send credentials using Fiddler in a POST request (or any Http Method)? I don't see anything in the Composer tab.
That entirely depends on what sort of credentials your server uses. If it's using HTTP authentication, the headers go in an Authorization header. If your server uses cookies, the creds go in the Cookie request header. If your server uses HTTPS client certificates, the credential is attached to the TLS connection itself and does not appear anywhere in the HTTP request.
If you are simply trying to authenticate to a service that uses HTTP authentication with your current Windows credentials, tick the Automatically Authenticate box on the Composer's Options subtab.
Related
I have Keycloak instance configured as an identity provider and front-end and back-end server separately. So on front-end side I send auth and token requests and receive all needed user information to send sign-up/login request. But here is a problem How I should properly secure the request?
I thought that I can set up access type as confidential for client then I would receive token from 'token' request, I would add it to sign-up's headers request and verify it on server on server side with client secret on server side. But as it appeared you can set only public access type for HTML/Javascript clients.
I saw that someone proposed to use two clients private and public with token exchange but it sounds weird to me.
I just created an REST API in API Connect and the endpoint works when I test it in the APIC assemble tab. It requires a client id and client secret. When I send a request through Postman, I currently get a “Could not get any response” message from when I try to add them as header values or OAuth authorization. I’m using the request endpoint that’s displayed when I hit the debug button from the successful response on the Assemble tab. Is this the correct endpoint to use? How do I properly include the client id and client secret in a Postman request?
If you get a "Could not get any response in Postman", that means that Postman can't reach the destination of the request.
There are several reasons for that:
Is it an intranet or internet endpoint?
Are you using a proxy? (check proxy config)
Is the hostname resolvable? (try ip)
If it is an https
endpoint, with a self signed certificate, check if you have SSL
Certificate verification enabled (Settings-> general)
On the other hand, to send the client-id and client-secret headers, just click on Headers tab and add both (see the following picture)
Please check the below things to get access to API Connect published services.
Service needs to be allowed to invoke from postman(System from which you are invoking.)
Please check the web-api MPGW service titled in DataPower default domain created when you configure your API connect with DataPower have you created an access control list in the front-side-handler.
Please disable the SSL configuration in the postman, sometime this may create a problem(since the service exposed from API Connect will be with SSL)
From the error you are getting, I suspect there is no connection or only one-way traffic is enabled which means you are blocking response. If there is an issue with the request parameters you are sending, an error will be different saying, wrong client id or client secret.
Testing API which is on-boarded from API Connect will be straightforward or same we invoke other rest services.
Thx Srikanth
I needed to include the client id and client secret in the headers using the correct name for them, which is specified when creating/editing the api under the 'Security Definitions' category as 'Parameter Name'.
I was also hitting the wrong endpoint. To find the correct endpoint click the hamburger icon in the upper left of api connect website, select dashboard, click on the environment you want such as sandbox or dev, click settings, click gateway, then you'll see the endpoint.
I am trying to send out a WebRequest request like https://identityserver.github.io/Documentation/docsv2/advanced/clientCerts.html specifies with a handler containing the Client Certificate.
I've gotten to the point that i have determined that the ClientCertificate is just not being sent through fiddler, so it is not read in the ServerVariables["CERT_FLAGS"] when the Owin LoadCertificate is called.
So i have removed all the steps from the process except (IdentityServer3.Samples/source/Clients/ClientCertificateConsoleClient/Program.cs)
async Task<TokenResponse> RequestTokenAsync()
{
var cert = new X509Certificate2("Client.pfx");
var handler = new WebRequestHandler();
handler.ClientCertificates.Add(cert);
var client = new TokenClient(
Constants.TokenEndpoint,
"certclient",
handler);
return await client.RequestClientCredentialsAsync("read write");
}
but I am still not seeing in fiddler in the raw request the certificate. I have looked at the source code for HttpWebRequest and only see it handles the ClientCertificate in the GetConnectionGroupLine, and then its a hash code which i also don't see in fiddler. I'm working with Windows 7 and i have turned on the iis client certificate mapping authentication and enabled the setting in iis express applicationhost in the 2015 .vs subfolder and the primary one in my docuemnts. What am I missing here?
reference: https://social.msdn.microsoft.com/Forums/en-US/f88a23f2-3dbe-4202-baf2-a5b05b027fe6/httpwebrequest-not-sending-client-certificate-to-server?forum=netfxnetcom
https://github.com/IdentityServer/IdentityServer3/issues/3220 - can't really find this on stackoverflow..
TLDR: Your problem (at this point) is Fiddler not HttpWebRequest/dotnet. (Edited to clarify.)
Fiddler doesn't display TLS info including certs. Fiddler works on, and displays in numerous formats, the HTTP-level data (requests and responses, including application data). When HTTPS transports this HTTP data over SSL/TLS, Fiddler does not display the SSL/TLS-specific data, which in addition to server and optional client certificates (currently) includes version, suite, possibly compression, curve, format and next-protocol negotiation, nonces, ephemeral keys, renegotiation control, signature algorithm control, server name indication, ticket, and other crypto options like encrypt-then-mac and extended-master-secret. The "raw" tab displays all the HTTP data without interpretation, but not the SSL/TLS data.
Fiddler doesn't request client auth. An SSL/TLS session uses a client certificate to perform client authentication only when requested by the server, and when your client connects to the real IdentityServer it presumably requests this. But when Fiddler is used, there is one SSL/TLS session from the client to Fiddler, and an entirely separate SSL/TLS session from Fiddler to the server. On the session from your client to Fiddler, Fiddler does not request client authentication, so your client doesn't and can't send or use its certificate.
Client auth can't be relayed anyway. If Fiddler did request client auth on the session from your client, it couldn't use that information to authenticate the session to the real server. Client auth doesn't just send the client cert, it also uses the private key to sign the concatenation (called a transcript) of the handshake messages. Since the handshake between your client and Fiddler and between Fiddler and the server are quite different, this signature is invalid for the server-side handshake and sending it would (correctly) be rejected as invalid by the server.
Instead Fiddler can do the client auth. If you want to route HTTPS traffic using client auth through Fiddler, you need to instead configure Fiddler to do the client auth on the session with the server; for a fixed setting you can just drop the identifying certificate in Fiddler's config directory, for per-session settings you need to write some FiddlerScript. The private key (and chain) needs to be in the Windows cert store, not (just) in a file. See:
http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/RespondWithClientCert
https://www.fiddlerbook.com/fiddler/help/httpsclientcerts.asp
Fiddler: Respond to Requests Requiring a Client Certificate (on SO)
https://security.stackexchange.com/questions/72916/can-fiddler-decrypt-https-traffic-when-using-elliptic-curves-client-cert-authe
If your actual problem is getting the client to support client auth when NOT using Fiddler, you need to take Fiddler out of the situation and use other debugging tools like a network trace.
We have Rest web services on a glassfish4 (payara) server
Our rest client is based on httpClient Lib
As Authentication we use certificate and basic auth.
The client work well getting and posting infos to WS
But when we send a multipart post with file bigger than few bytes, parsing the request hang until a timeout
If we disable the certification auth, all is working
Thanks to payara blog, we address the problem: we needed to change a configuration in payara, "Max Save Post Size" in Network Config->Network Listener -> http-listener-2 (the one using ssl) - http tab
I saw the word "endpoint" many times in OAuth documents.. However, I still don't know what does this word really mean.. Does anyone have ideas about this?
The OAuth 2.0 Authorization Framework
The authorization process utilizes two authorization server endpoints
(HTTP resources):
Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
Token endpoint - used by the client to exchange an
authorization
grant for an access token, typically with client authentication.
Its basically the HTTP web address of the authentication server. It could probably be server addresses depending upon how its worked. The first is for requesting access of the user the second could be for granting access to the application. this probably depends upon how the Authentication server is set up.
OAuth endpoints are the URLs you use to make OAuth authentication requests to Server. You need to use the correct OAuth endpoint when issuing authentication requests in your application. The primary OAuth endpoints depend upon the system you are trying to access.
Example Google has two end points:
Request access of user:
https://accounts.google.com/o/oauth2
Exchange tokens
https://accounts.google.com/o/oauth2/token