I have a end point which gives a jwt on a post request.I am sending one CA certificate and one Pfx file along with password via postman. Everything is working fine with postman.
Can someone advise how this can be done via Rest Assured.
Note: I have no idea on what key store and a trust store is ,which is why I feel that I am unable to solve the problem.If someone can help me understand these ,I can import and export the certificates accordingly and give an attempt with Rest Assured.
I have not shared any sample code casuse I have not decided my approach yet.
Regards
Mohan
Related
We are generating document PDF's as part of our server application workflow. We need to be able to sign these documents to prove they are from us and have not been tampered with. We currently do this using a self-signed cert and using syncfusion's PDF module (excellent sw btw!). The problem is (of course) that the self-signed cert is not in the CA trust chain so although the document is secured, it doesnt automatically validate that its from us.
I have been researching where to purchase AATL certified certificates from and have found several vendors (Identrust being one of the more affordable options). However, they all share the same delivery method which is they ship it to you on a secure USB or similar token. What I dont understand then is how to use this token with our hosted VM. Does anyone have any experience in using these types of token ie. are we simply able to export the private key from the token onto the server?
Thanks
You cannot use the tokens in this scenario.
The certificate issuer should provide you with a web-based API that you integrate in your signing process. Usually you send the document hash and get back the signature, but the actual flow and ins/outs depends on the certificate provider.
Then the PDF library you use should let you embed in the PDF file the externally computed signature.
Is there anyone with experience in using Azure API Management, and in particular with validating JWT tokens sent to it using the policy model?
I've configured the <validate-jwt> tag properly, but my tokens are signed asymmetrically so I need to use the <openid-config> tag to let the system know where to get the public key.
And in doing so, the system will call to that url over SSL/TLS, but in my case the host is configure to offer SSL/TLS with a self-signed certificate.
Is there any way to disable this? I know the official docs mention disabling certificate validation when it comes to calling the backend APIs, but this is a front-facing API. And setting that doesn't seem to work.
I also tried abusing the declarative model of the policies, to somehow run C# code that disables that, but to no avail.
Does anyone know any other way of doing this? Either disabling the validation, or forcing trust with the self-signed certificate.
Thank you, and have a good one.
EDIT: This is how my configuration looks like:
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized" require-expiration-time="true" require-scheme="https" require-signed-tokens="true">
<openid-config url="https://identityserverhost/.well-known/openid-configuration" />
<audiences>
<audience>audience</audience>
</audiences>
<issuers>
<issuer>issuer</issuer>
</issuers>
</validate-jwt>
The https://identityserverhost is served over https, but with a self-signed certificate, if this makes it more clear.
I don't think it's possible at the moment, would be a good feature though. You could switch to http instead of https in openid-config, if you're comfortable with that.
if you have the certificate you can load it on API Management
and validate the tokens by means of the following policy
<issuer-signing-keys>
<key certificate-id="my-rsa-cert" />
</issuer-signing-keys>
I'm currently working on an automated deployment process for a hosted service for Windows Azure. The creation of the .cspkg and .cscfg files works perfectly using a call to msbuild. Now I'm writing a small .NET console app that should deploy these files to Azure using the Management REST API.
There is no problem concerning the API itself. I can send a request to the API using one of my management certificates. I upload the .cspkg file to Azure BLOB Storage and then try to call Upgrade Deployment. But every time I try, I get a "400 Bad Request" response stating that the certificate with thumbprint xy was not found. This certificate is the SSL certificate (not a management certificate) I'm using for HTTPS for my custom domain (DNS CNAME).
And now, the whole thing gets interesting:
When I deploy the files using the "Publish" command in my Visual Studio, there is no problem. (I compared the .cscfg/.cspkg files from VS and from my msbuild output: apart from a few GUIDs, they're identical). And furthermore, using the Silverlight Management thingy in my browser, I can even upload my generated files that could not be uploaded using the API.
When I retrieve a list of all certificates using the List Certificates call, the certificate which is said to be missing is apparently there. I can also retrieve its data using the Get Certificate call.
So why does Azure keep telling me that the certificate was not found when using the Upgrade Deployment call? Did anyone experience something similar? Has anyone the hint for me? Thanks in advance.
P.S.: This is what Azure says when I use the API:
<Error xmlns="http://schemas.microsoft.com/windowsazure" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<Code>BadRequest</Code>
<Message>The certitficate with thumbprint 7b232c4a2d6e3deadbeef120d5dbc1fe8049fbea was not found.</Message>
</Error>
P.P.S.: Yes, the word in the response is certitficate, not certificate.
OK, after using the List Subscription Operations API call to find out what Visual Studio calls to deploy apps, I found the solution.
Turns out that the URL I used for the API request was wrong, but: with all due respect, I blame Microsoft for lousily documenting its Azure Management API.
In their documentation, they write the URL to use is:
https://management.core.windows.net/<subscription-id>/services/hostedservices/<service-name>/deploymentslots/<deployment-slot>/?comp=upgrade
And the description is the following:
To generate the request URI, replace <subscription-id> with your subscription ID, <service-name> with the name of your service, <deployment-slot> with staging or production, and <deployment-name> with the unique name of your deployment.
What they forgot to mention is, that you have to use the DNS Name of your service, and not the Name! They could at least return an appropriate error message telling you that the service name is invalid, non-existent or doesn't belong to your subscription ID, instead of complaining about some certificate issue.
Thank you Microsoft, that cost me more than two days.
The error indicates that you have not uploaded that certificate into the hosted service's secret store. Visual Studio might be doing that automagically for you, but if you want to replicate it programmatically, then use the Add Certificate API call and upload the PFX into the deployment.
You can see '400 BadRequest - The certificate with thumbprint XYZ was not found.' appear in the CreateDeployment or UpgradeDeployment scenario for the following reason (which I just debugged):
You use the same certificate for subscription management as you do for e.g. SSL or Remote Desktop password encryption in your hosted service. You therefore will use the certificate with thumbprint XYZ to authenticate your service management REST call that creates the deployment.
When specifying your deployment parameters you pass in your CSCFG which references that same cert by its thumbprint, because it needs to configure Remote Desktop/SSL etc.
That cert is not yet added to your hosted service certs.
In this case the 400 Bad Request error really is telling you that you have a bad request, because the certificate in your CSCFG is not yet attached to your hosted service. The confusion arises (for me) because, since its a multi purpose cert, you misinterpret the error message as referring to the authentication of the request, even though you are not getting 401.
Google and stackoverflow seem to be silent on how to do this. I must be missing something but how do you get VS2010 to allow you to add a x.509 certificate and password to authenticate an SSL service reference so that you can add it to your project?
I am trying to connect to a webservice with an address similar to:
https://services.acme.com/abc/service.wsdl
It requires the x.509 cert and password retrieve the wsdl. This is easy to do in SoapUI, but I can't seem to decipher how to get this going in VS2010.
Okay, so for anyone else who may not know how certificates work in the Microsoft world, VS2010 uses whatever certs you have imported on your machine to try and authenticate. You have to go into IE>Internet Options>Content>Certificates and then import your certificate here. After that, VS2010 will automatically look there for a cert which matches the URL you are using for your wsdl.
I want to be able to set up a web application to automatically (i.e. on a cron run) send a POST request to a remote website. The remote website requires a username/password combination to be sent as part of the POST data. I want the web application to be able to make the POST requests of the remote website without requiring the user to provide the password to be sent with the POST data, each time the request is made.
It seems to me that the only way to do this is to store passwords directly in the database, so that the cron run can execute a POST request that includes the password as part of its POST data. Without storing the password in some form in the database, it seems it would be impossible to provide it in the POST data, unless the user provides it each time the request is made.
Question 1: Am I mistaken and somehow overlooking something logical?
Question 2: Assuming I have to store the passwords in the database, what is the safest procedure for doing so? (MD5 and similar one-way encryption clearly will not work because I have to send an unencrypted password in the POST request.)
Thank you for your help!
a. if you don't know the password... you can't authenticate, that's the idea of a password !
b. if you need to know the password - you need to save it in a decryptable way - hence - less secured.
c. if you own the site, you can use a cookie with a very long timeout value, but - you still need to authenticate at least once.
d. unless you're guarding money / rocket science, you need to encrypt the password and store it in the DB and decrypt it every time before use, at least you are guarded from DB theft.
e. make sure you're authenticating over secure channel (as https) so the password will no be sent as clear text.
One good solution is probably to use SSL (i.e. HTTPS). You can create a certificate authority on the server side, then have this certificate authority sign a client certificate that you generate. Make sure the HTTP server is configured to trust the newly created certificate authority.
Once this is done, you should install the certificate on the client side. The client must present the certificate when talking to the HTTP server. You have to configure the HTTP server to require a trusted certificate when POSTing to your secure URLs.
Awesome example of how to do this with Apache HTTPD is posted right here!
The document I linked doesn't describe how to set up the certificate authority and create self-signed certificates, but there are tons of examples out there, for example here.
This is a good solution because:
no passwords are stored in the clear
if the private key of the client's certificate is stolen or compromised, you can revoke it on the server side
The key here is that the client is providing its credentials to the server, which is the opposite of what is usually done in a browser context. You can also have the client trust your newly created certificate authority so that it knows it's talking to the right server and not a man in the middle.
Given that you have to send the password in clear-text and do it repeatedly without user-interaction you'll need to store and retrieve the same from a data-store (file/database/memory).
What you really need to consider is the last-line-of-security of the password store.
Whether you encrypt it or not doesn't matter. The person/program with access to the data or the cipher key will be able to read that password.
Sort this issue out, document it - (this becomes your security policy for the app) and then implement it.
Security is only a level of difficulty you implement to lessen a risk.
Fortunately, Tumblr now implements OAuth, which solves this problem.