Referring to the Azure keyvault Sign API at https://learn.microsoft.com/en-us/rest/api/keyvault/sign/sign. Its not clear if the "value" which is string (in request and response both), how the API expects the encoding for binary strings like digest and how the response has this 'value' encoded? Is this in base64? If so, Azure has any difference in base64? Any sample code showing this REST API request/response processing?
For the Sign API, the value is a digest. This page tells that it needs to be base64url encoded, and conforming to JOSE specifications. The actual value will vary according to the signing algorithm. Links to libraries and sample code in many programming languages can be found here.
Related
In my current application under test using Karate framework, I came across TWO APIs - Token and Extended, which provides the APIGEE token value to access backend services.
API-1: Token API
Input payload (form-data) -
grant-type: authorization_code
code: *8-digit-characters*
redirect_uri: https://../oauth-code-callback
code-verifier:*28-digit-characters*
client_id: *Unique-Client-Key*
Response -
{"access-token":"..."}
API-2: Extended API
Input payload (JSON) -
{"access-token":"..."}
Response -
"APIGEE_Token"
Looking at the input payload in API-1, code and code-verifier are SHA-256 encrypted values generated using typescript. Now, in order to generate the final APIGEE token, I need to generate code and code-verifier values using the same typescript libraries in Karate. Is there any possibility as such? Else, please suggest if there is any alternative approach for my requirement. Thanks in advance!
First, I suggest you check if the tokens can be generated using some standard algorithm, in that case you can re-write them in Java or JS. Examples here: https://stackoverflow.com/search?q=%5Bkarate%5D+jwt
Else here are 2 extra creative solutions:
Karate uses the Graal JS engine, so if you can get the pure-JS equivalent of the routine you need, it may be possible to load it into Karate by reading the .js file. For example read() (or karate.read()) can return a JS function, which you can then invoke within your test flow.
If you have node / npm installed, you can write a command-line program that takes command-line args and returns the data you need. Note that you can even return JSON and use karate.fromString() to parse it. Karate happens to have very good support for OS command-line execution, refer: https://stackoverflow.com/a/62911366/143475 and a similar idea is described here: https://stackoverflow.com/a/51150286/143475
Finally, it may well be worth it to ask your dev-team to stand-up a small REST service that returns these tokens for you in your pre-prod environment. And the moment you have a REST option, guess what Karate is really good at :) The REST is up to you.
I am writing an app on iOS that uses the Amazon API to display a list of products in a category.
The problem I'm having is in signing the API. I am using the advertising API in India, and am using scratchpad to test out the api call.
For the unsigned url generated by Amazon Scratch I have:
http://webservices.amazon.in/onca/xml?Service=AWSECommerceService&Operation=BrowseNodeLookup&SubscriptionId=IAMHIDINGTHISINFO&AssociateTag=HIDINGTHIS-XX&BrowseNodeId=1350388031&ResponseGroup=BrowseNodeInfo
For the signed I have:
http://webservices.amazon.in/onca/xml?AWSAccessKeyId= IAMHIDINGTHISINFO&AssociateTag=HIDINGTHIS-XX&BrowseNodeId=1350388031&Operation=BrowseNodeLookup&ResponseGroup=BrowseNodeInfo&Service=AWSECommerceService&Timestamp=2016-11-21T16%3A06%3A05.000Z&Signature=LETSSAYITGENERATEDTHIS
Following the steps on Amazon's documentation on signing the, I get the final canonical form as:
GET webservices.amazon.co.in/onca/xml AWSAccessKeyId= IAMHIDINGTHISINFO&AssociateTag=HIDINGTHIS-XX&BrowseNodeId=1350388031&Operation=BrowseNodeLookup&ResponseGroup=BrowseNodeInfo&Service=AWSECommerceService&Timestamp=2016-11-20T22%3A55%3A41.000Z
Which is following their steps EXACTLY. I prepend GET\nwebservices.amazon.co.in\n/onca/xml\n to the byte order the rest of the keys and then use HMAC SHA-256 to obtain the signature. Despite this, I get an incorrect signature generated.I know the hashing algorithm I use is correct since when I hash the example that they give in the documentation, it generates the exact hash (I am using AWSSignatureSignerUtility from their iOS SDK).
Can someone please tell me if I should not prepend GET\nwebservices.amazon.co.in\n/onca/xml\n or if it should be something else?
Just figured out the problem with the help of Signed Requests Helper.
Apparently, I was supposed to prepend
GET\nwebservices.amazon.in\n/onca/xml\n
and not
GET\nwebservices.amazon.co.in\n/onca/xml\n
I'm trying to POST "mutlipart\form-data" to my EC2 instance through AWS API Gateway, but I couldn't find a way to this. There is a way to post data using "application/x-www-form-urlencoded" and Mapping Tamplate to convert it to JSON but still posting a binary data like an image file is missing I guess. Is there anything I'm missing ?
EDIT:
I have found another way:
I convert the image to base64 string then POST it as with content type "application/x-www-form-urlencoded". By this way I'm sending whole image as string. After I got the message I can convert it back to image in PHP. Only down side of this I could find is when I convert image to base64 its size gets a bit bigger. Other than that, I couldnt find any other downside. If there is could you please share with me ?
Api Gateway team here.
Binary data isn't supported at the moment, but it's on our backlog. Several customers have requested this.
Some customers have had success using the base64 util in the mapping templates which may get it working for you: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#util-template-reference
Other than that you'll have to wait for official support.
Edit
Binary support is finally here!!
Context: I'm updating my WordPress plugin to authenticate against the YouTube v3 API using a server key that has to be requested and entered by the user of the plugin.
Problem: I would like to perform validation of some kind on that key before using it, but can't seem to find documentation of the format a Google API server key adheres to. Based on (a very limited) number of examples it seems as though a key is:
is 39 characters long
is case-sensitive
consists of letters, numbers and at least dashes
So the question, obviously: Is this documented somewhere? Can anyone confirm or expand?
thanks,
frank
I couldn’t find any published key format either. Maybe because they want to keep the freedom to change the format in the future. If you want to be on the safe side, you should probably just do sanity checks well above the observed format. For example <=1024 bytes and non-control ascii characters, or even base64, or just don’t do any validation at all and let Google do that.
How about taking the key and passing it to a server-side script that attempts to use the key for some call. Then if it works return a success, else fail and call this async for the validation. Just seems more reliable than trying to decoded or anticipate the format of the hash.
I am using Delphi 7's HTTPReqResp component to send a digitally signed SOAP XML Document to a HTTPS web service. I use Eldos XML BlackBox and have set all the transformAlgorithms, CanonicalizationMethod, signaturemethod, etc. to the ones the web service requires and have confirmed this with a tech support officer.
I have validated the signature using XML BlackBox and also this XML Verifier website.
Both ways confirm the signature is correct. However, when I send the XML document via HTTPReqResp.execute, the response I get back is BadSignature (The signature value is invalid).
Originally, I received back a different error messages due to XML errors (malformed, etc.). It appears that the service will do all the standard formatting checks first, then it will attempt to validate the signature. Since I get back the BadSignature response, the rest of the XML must be correct.
I suppose I have 2 questions here.
Does the HTTPReqResp component alter the XML.
Is it likely the webservice alters the XML.
The site is using Access Manager WebSEAL.
It's very likely that the receiving partner is getting a modified document somehow. Some minor modifications shouldn't affect the signature (that's the idea, at least) so you may want to check the following:
"Recommended" encoding used by the receiving partner. A very annoying practice by some receiving partners is to favor one form of encoding and completely ignore others. XML signatures should use utf-8 but I've seen servers that only accept iso-8859-1
Make sure you don't accidentally change encoding after signing.
Verify that the receiving partner is using a sane canonicalization method.
Verify with your receiving partner that no extraneous elements are being added to your document.
Also, have you tried to post this using the SecureBlackBox components? They also have an HTTP client that can do SSL, and that can be used to also verify the bytes being sent through the wire.