i am trying to simulate client certificate based authentication for my APIs in postman.
https://www.getpostman.com/docs/postman/sending_api_requests/certificates
I have followed this document and was able to send the certificate (as shown in postman console).
In server side i look for ssl_client_cert header name to check if it is a certificate based authentication (as i have other modes of authentication too).
But it seems the header is not being sent by postman.
Is there anything else i need to activate in postman. What is hitting me is that i have kept the authorization mode in postman as no auth. I don't find any cert auth mode to select. Am i missing anything.
best Regards,
Saurav
Related
I have a VB.NET website configured in IIS to use client certificate authentication.
When a user opens website url, he gets a popup to choose the certificate. Once the user is on the web page there is a button, clicking this will make a SOAP request to a 3rd party.
Presently I am able to use a single certificate stored on the server to make the SOAP request (by attaching the certificate). Thus the same certificate is used irrespective of which user clicks on the button.
How do I attach the client certificate of the respective user to a SOAP request? Is this possible?
How do I attach the client certificate of the respective user to a SOAP request? Is this possible?
simply attaching the public certificate of client makes little sense. If you need to co-sign the SOAP request with client certificate, then you need to send unsigned SOAP request to client (say, client downloads the request from your web site), sign it, send to server, allow the server to co-sign the SOAP request and then submit this SOAP request to 3rd party.
You cannot upload client certificate to server in order to make SOAP signing on server. It is unsupported and vulnerable approach. Client certificate's private key (which is used to sign data) MUST NEVER leave client machine/device. If you need to sign anything with client certificate, signing operation must be performed on that client only.
I have an ASP.NET Core 3.0, Angular, IdentityServer4 application deployed to IIS. Which is using a server certificate exported to .pfx for token signing. (This same certificate is used for the SSL certificate but from the certificate store).
The application loads fine both as https://www.example.com and htts://example.com (no SSL errors).
However when browsing on https://www.example.com and trying to access data on any endpoints requiring authorisation, it doesn't work. The following error is observed in the response header:
www-authenticate: Bearer error="invalid_token", error_description="The issuer 'https://www.example.com' is invalid"
I'm not sure where to start looking... will this be an IdentityServer4 configuration issue?
FYI, this project was developed from the template project created by dotnet new angular -o <output_directory_name> -au Individual.
The token issuer (which is the origin of the site that issued the token) is a part of the contract between an OIDC provider and the clients and APIs that rely on it.
identityserver4 by default will use the incoming request details to determine what the value of iss should be in any tokens it issues.
As such you should usually only use a single host name for your OIDC provider - e.g. identity.example.com or something along those lines.
Another option may be to force it to use a pre-defined host name rather than determining it based on the request.
I am trying to setup IIS Client Certificate Mapping Authentication and so far I have been unsuccessful.
I have a valid client authentication certificate
I disabled all authentication methods in the Authentication feature of IIS for the target website
Using the configuration editor I setup iisClientCertificateMappingAuthentication as documented in various sources. In this series of screen we map a domain account to a certificate. This is done by exporting the certificate to a text file, removing the first and last line and making sure all is in one line.
The problem is as follows:
When I try browsing to a test page, browser correctly prompts for selection of a certificate. I select the correct certificate. I then get presented with
HTTP Error 401.2 - Unauthorized
You are not authorized to view this page due to invalid authentication headers.
If I enable Anonymous Authentication then it works, but the user is not the one in the mapping it is the user running the browser. I know this because the test page contains the following:
response.write (request.servervariables("LOGON_USER"))
response.write (request.servervariables("AUTH_USER"))
So the questions are:
For IIS Client Certificate Mapping Authentication, is this the only authentication feature that needs to be enabled?
Do we need to use the Authorisation feature to limit the users to the one provided in the mapping?
What I am trying to achieve is that only clients that have the certificate will be able to access the service.
What am I missing?
Cheers
Jose
I have multiple sets of sensor networks that are sending data to a .net web api. Somehow, I need to secure some of the endpoints of the API (so that I can be certain that the information sent to the API really is from the sensors). Basic auth and SSL seems to be one way to go. The problem is that I'm having trouble understanding the SSL part.
As of now I have created a client certificate that is stored on the sensors, information of the certificate can be retrieved in the API by the Request.GetClientCertificate() method. Is this overkill when I just want to secure my Api with basic auth? That is, is the communication secure by just sending data over https without providing a certificate?
I do not need to use the certificate for authentication (since this is done by basic auth).
Basic authentication is about sending the user name and password in the HTTP authorization header as plain text (base64 encoded but not encrypted). For this reason, you need to use HTTPS with basic authn so that folks in the middle do not get to see the user name and password that a client sends.
When it comes to HTTPS, there is a server certificate and a client certificate. Server sends the server certificate to the client so that client can determine it is the right server it is connecting to. Similarly, a client can send a client certificate to the server so that a server can determine if an authentic client is talking to it.
The client certificate part is optional in HTTPS. So, you can use basic authentication without using the client certificate. If you use client certificate, it is already a credential and you need not use basic authentication, unless you want to use a two-factor authentication. TFA is an overkill or not - it is for you to decide.
I'm looking for an existing HTTP protocol for securing authentication but not the payload that follows. I want the server to store the username, hashed password and different salt per user.
HTTP Digest Authentication fails these requirements because all accounts use the same salt. SSL fails because it encrypts the entire connection.
Edited to add:
This is for a desktop client talking to a web service (no browser involved)
The popular scheme is to have login form protected by SSL, while rest of the site doesn't use SSL. See for example popular social networking sites.
Why not just have your authentication mechanism protected by SSL and then forward to the rest of your application which runs under normal HTTP?
How about OpenID? Is there a reason that you have to store authentication information?
Edited to add
Sorry didn't catch that it was a desktop app. How about OAuth?
Is there a way that you could structure the original request URL to indicate the user? Then, the server could respond with a different different realm (acting as "salt") for every user in the HTTP digest authentication response. For example, request URLs of the form http://user.y.com/service or http://www.y.com/user/service would result in a challenge response like:
WWW-Authenticate: Digest realm="user#y.com", nonce="oqa9hvq49krprkphtqc"
Can you explain what's driving the "no encryption" mandate? If you are subject to man-in-the-middle attacks, you need to protect the integrity of the entire request. There, SSL would be very helpful. If you absolutely cannot have encryption, would SSL using an unencrypted cipher suite be acceptable?