I've been playing around with Azure's API Management service and came across some unexpected behavior. Specifically, I've been reading about using certs for client authentication as discussed here. I'm interested in checking the incoming thumbprint against the certs already uploaded to API management. The Azure example gives you the following example for achieving this:
<choose>
<when condition="#(context.Request.Certificate == null || !context.Deployment.Certificates.Any(c => c.Value.Thumbprint == context.Request.Certificate.Thumbprint))" >
<return-response>
<set-status code="403" reason="Invalid client certificate" />
</return-response>
</when>
Using Postman and some mocked responses on the API side this works as expected. Incoming messages that have the cert work and others return a 403. What is odd is I then removed the cert from the Client Certificates page on the Azure API Management portal and my request from Postman still makes it through. I was expecting them to be rejected since the cert is gone.
Removing the cert from Azure was successful, at least according to the notifications presented to me in the portal. I also tried it again after an hour or so thinking that it might need sometime to process.
Thank you all for your time!
This is a known issue, and will be fixed shortly. For now you'll have to change, for example, policy to force APIM to throw away certificate from runtime.
Related
https can be used in the notification url setting of the subscription.
https://fiware-orion.readthedocs.io/en/master/user/security/index.html#https-notifications
However, I couldn't find in the documentation if https can be used in the provider url setting of the registration.
Please confirm if Orion officially permits the use of https in the provider url setting of the registration API.
I'd say that Orion would allow Context Providers using HTTPS endpoints the same way as with subscriptions, as the code is the same (i.e. the code to deal with outcoming requests is shared between notification logic and request forwarding logic).
Could you check and tell us if it works (as comment to this answer), please? :)
EDIT: the test cases included in this PR assure that HTTPS CPrs are working.
I know that if presented with an mTLS request an modern browser will request the user select a certificate from a store (OS-based or in Firefox's case NSS-based). I was wondering if there is any other way for the Webpage that is returned after the mTLS handshake to requests actions be performed with the users certificate or private key, such as:
Can the webpage be aware of the selected certificate and read some of the field with a Javascript API? (IE: <h1> Hello {x509CommonName}</h1>)
Can the webpage request that the user sign something with their private key? (little risky but potentially useful)
I am not asking how easy it is to just use the web server to reflect the certificate back to the client.
From the client side, it is not possible to obtain the certificate used in the SSL connection, nor to perform a digital signature. The browser keystore is not accessible via JavaScript. Although there has been some attempt to develop a standard API, it seems that it is not succeeding. See https://www.w3.org/TR/webcrypto-key-discovery/
On the server side you can easily obtain the certificate used. Any web server will provide it to the application layer. The web page could navigate to a zone with ssl two ways authentication, the server would retrieve the certificate and return it in the response
I am trying to send email using PutEmail processor in Nifi. Below is the configuration of the processor.
However, emails are not sent and getting this error. It would be great help if addressed.
#techno_mad - I would trust the error message. Test with a known working smtp combo with 100% confirmed smtp access. I also suggest, paste the nifi error as text, not an image. Your peers need to visit the link and are likely not typing it out.
https://support.google.com/mail/thread/5621336?hl=en
Test enabling “Access for less secure apps” (which just means the
client/app doesn’t use OAuth 2.0 - https://oauth.net/2/) for the
account you are trying to access. It's found in the account settings
on the Security tab, Account permissions (not available to accounts
with 2-step verification enabled):
https://support.google.com/accounts/answer/6010255?hl=en
I'm looking to use Azure API Management to provide a centralized API for some external, authenticated APIs (Twitter, etc.), utilizing application-only authentication. I want to provide specific tweets, etc. to a dashboard-like mobile app without users needing to authenticate with their own account for each service.
I haven't been able to find any documentation or examples on doing this so far. Policies look promising, but I haven't been able to prove them out yet. Or possibly creating my own API App for each external service (to handle the authentication properly) and then managing that API via API Management.
Anyone have thoughts/ideas on better ways of accomplishing this? Thanks.
Thanks to #DarrelMiller for keeping me on the correct path
The solution ended up being just needing to pass the correct bearer token as a header, accomplished with Set-Header in the inbound policy of the operation. Twitter has non-trivial instructions on how to obtain the bearer token for their service.
Example:
<inbound>
<set-header name="Authorization" exists-action="override">
<value>Bearer xxxxxxxxxxxxxxxxxxxxx</value>
</set-header>
<base />
</inbound>
I have this app that uses EWS to access mail, using the standard /EWS/Exchange.asmx SOAP endpoint.
One my user's mail servers is protected by Microsoft Forefront, and the initial HTTP request to
https://server_name/EWS/Exchange.asmx
is redirected (HTTP 302) to:
https://server_name/
CookieAuth.dll?GetLogon?curl=Z2FEWSZ2FExchange.asmx&reason=0&formdir=3
which is an regular HTML page, the point of which, I guess, is to make the user authenticate "manually".
I've not heard about Forefront until today, not sure how to handle it.
Is this normal behavior for Forefront (i.e. it always redirects the initial HTTP request), or is it triggered by something in my app? For example, user-agent?
If it's normal, how am I supposed to get past this page and access /EWS/Exchange.asmx?
If it's triggered by something my app is doing, how can I find out what it is?
My code runs on Android and forms its own XML requests without using any SOAP library. At the transport level, I use Apache HTTP client components. The code works fine with Office 365/Exchange Online, and, according to user reports, "self-hosted" corporate Exchange servers with NTLM.
However, in this case, I'm not even getting an HTTP 401: the HTTP 302 is returned by the very first HTTP roundtrip.
Trying to preemptively authenticate the initial request using Basic authentication didn't make any difference.
The user who reported this issue also mentioned that another EWS based app works, so there must be a solution to it.