For the Azure CLI, is there a way to use proxy authentication? Our proxy servers needs all requests to be authenticated and I do not see any document relating. Using HTTP_PROXY environment variable, I can instruct the az cli to use a particular proxy server but I cannot define it to use proxy authentication, OR if there is a way to do this, I do not know. Our Proxy authentication has to be done either through NTLM or Kerberos.
Can the relevant team, please check If we can configure az cli to use Kerberos proxy authentication?
The root of the answer lies in the fact that Azure CLI is built on top of Python. Now as regards Authentication, Azure CLI uses AAD based protocol, which is handled by the ADAL library for Python whose source code is published here.
So if this is of interest and someone wanted to see the wire level details, please dig in here.
As mentioned Azure CLI is built on TOP of python, one of the reasons being to give it a broad cross-platform reach, as it available across Windows, Mac, Linux (and may be other ports are available).
And ADAL Python is based on a popular Python HTTP library. While the proxy can be configured (and that is not the question here), what was asked and what enterprises want is a way to use Kerberos/NTLM to authenticate the requests while funneling it through a proxy. So if you dig into the documents for the Python HTTP library, you can see named requests, whose proxy support can be configured inline or by environment vars (again that is not the ASK).
Now when you dig into authentication when requests are being proxied, the document mentions HTTP basic auth only, and there is no mention of Kerberos/NTLM type of authentication. Now if one has worked with any security conscious enterprise, this would be difficult to get an exception. This has been requested by some enterprises, where they want to authenticate (security requirement) all Azure CLI requests at their external facing proxies before it leaves the perimeter.
The current answer is there is not a supported way to do this, unless an auth handler is implemented that does this, for the scenario where a proxy is in place. This is a request that would squarely belong to the Python HTTP library owners, if I am not mistaken.
For anyone still looking for the answer to this question the answer can be found here
# Non-authenticated HTTP server:
HTTP_PROXY=http://10.10.1.10:1180
# Authenticated HTTP server:
HTTP_PROXY=http://username:password#10.10.1.10:1180
# Non-authenticated HTTPS server:
HTTPS_PROXY=http://10.10.1.10:1180
# Authenticated HTTPS server:
HTTPS_PROXY=http://username:password#10.10.1.10:1180
Obviously not the most secure approach and be careful to url encode any special characters.
In my case I had to remove protocol "http|https" from variable string
# Non-authenticated HTTP server:
HTTP_PROXY=server.fqdn.int:8080
# Non-authenticated HTTPS server:
HTTPS_PROXY=server.fqdn.int:8080
Related
A client of mine has a bunch of APIs in CloudHub that communicate with two APIs on premise in their runtime. The question I get asked, to which I don't really know the answer, is how to secure the communication between the APIs on CloudHub and on premise without using API Manager (since the client preferred not to pay for it) ? I thought of a middleware (middleware inception) that hashes the messages from one end to another, is this a viable idea? What could the best answer be?
The server applications should implement some basic security best practices like authentication and encryption.
Having applications deployed in any cloud environment without security is a big security risk. I assume that there is a secure link between the CloudHub environment and their on premise environment, like a VPN, but even so this architecture would not probably pass a security audit.
They should implement authentication using HTTP Basic authentication or OAuth 2. These are the most common authentication schemas used for REST APIs. Note that credentials go in clear text so they should also implement encryption.
To encrypt the traffic the server applications should use TLS, ie HTTPS connections instead of plain HTTP.
Optionally you could also implement mutual TLS authentication, requiring the client to have a valid certificate that the HTTPS server validates.
Hashing message could be an additional level of security, but that implies changing the applications logic to implement some custom security. The effort should be better put into implementing standard security practices as mentioned. If after that you want to add it feel free to do so.
You have not shared details of the technology of the on prem applications. Mule applications can implement both the client and server side of any of these methods. Read the documentation for details:
https://docs.mulesoft.com/http-connector/1.7/http-authentication
https://docs.mulesoft.com/mule-runtime/4.4/tls-configuration
https://help.mulesoft.com/s/article/Tutorial-how-to-create-a-simple-Mule-4-http-basic-authentication-application
I've developed simple REST API using a expressJs. I'm using React as my client side application. So the problem is anyone can see my API endpoints because of react app is in client side. So they will also able to make request and fetch data from my REST API. (May be they will build their own client side apps using my API.) I've seen some question about this and couldn't find any comprehensive answer. How these kind of a security problem should be handled? Is it possible to give the access for API to only my client app? If not how huge brands that using REST API prevent that? (Also I don't have a user authenticating scenario in my product as well. People can just visit and use the website. They don't need to register).
Authentication can be a way but it can be bypassed. Another way is you can create a proxy server which strictly blocks cross origin requests, hence it blocks requests from other domains to make request to your API, and you can make your API call from that proxy server. In this way your API server endpoint will also be not compromised.
If, as you state in your comment, this is about users on your own website being allowed to use your site's API, while disallowing off-site use (e.g. other websites, wget/curl, etc) then you need to make sure to set up proper CORS rules (to disallowed cross-origin use of your API) as well as CSP rules (to prevent user-injected scripts from proxying your API), and you also make sure to only allow API calls from connections that have an active session (so even if you don't want user authentication: use a session managemer so you can tell if someone landed on your site and got a session cookie set before they started calling API endpoints).
Session management and CORS come with express itself (see https://expressjs.com/en/resources/middleware/session.html and https://expressjs.com/en/resources/middleware/cors.html), for CSP, and lots of other security layers like HSTS, XSS filtering, etc, you typically use helmet.
I want to build a server using Node.js, which acts as some kind of proxy. The clients that connect to my server use NTLMv2 for authentication (there is no chance to change this), but the upstream server my server shall connect to requires a Kerberos token.
So, my question is pretty simple: How do I, using Node.js, transform the information provided by NTLMv2 into a Kerberos token? On npm, so far I have found modules for NTLMv2 authentication, but I somehow would probably need to talk to Windows to translate NTLMv2 data of a user into a token for this user.
Any hints on this, how to approach this problem?
Absolutely not! NTLM and Kerberos operate completely different. First of all, I would highly recommend get rid off NTLM as fast as you can.
You can solve your problem in an easy fashion if you can access C interfaces. I also assume you MIT Kerberos on a Unix-like OS like CentOS or FreeBSD, etc.
NTLM will provide you the downlevel logon name. You need first to convert the NetBIOS domain to a DNS domain via LDAP (use libopenldap) then you can construct the Kerberos principal or the enterprise principal for your client. Then create a service account in your KDC and enable protocol transition and contrained delegation on that account for the target service. Now request a TGT on behalf of that user principal and request a service ticket for the user, voila you can access your Kerberos backend.
Here is a decent read: https://k5wiki.kerberos.org/wiki/Projects/Services4User
If you run HTTPd as your reverse proxy, it might handle all the magic for your with mod_auth_gssapi.
On Windows, this is a bit of a pain with the security API and SSPI. While the the principal transformation comes for free with Windows. You'll need LsaLogonUser with KERB_S4U_LOGON, impersonate with that handle and then require SSPI to acquire a cred handle...
If your KDC allows constrained delegation, you can setup your intermedaite server to allow impersonation. This way it can established security context with the client in one mechanism (in your case, NTLM), and talk to the backend server on behalf of the client in another mechanism (Kerberos). Google for "constrained delegation" and "protocol transition" for more information. Hope this helps.
I am trying to restrict access to my azure web app only to one of my web jobs.
Can I use IP Restrictions to achieve this.
To achieve this type of restriction, IP Based restriction will not be of use for the following reasons:
There might be other applications(owned by you, in case of standard above plans, or other customer apps in case of free/shared planes) that will be running on the same server and those also will have access to your web app.
There is no fixed outbound IP for your web job as it might be moving to different instances (in case you have multiple instances in your app)
A quick and easy solution for your original problem is:
Implement either BASIC Auth (username/pwd) or Bearer token Auth on your web app side.
From your web Job (in the Invoke-WebRequest) pass either the username/pwd or auth token based on whichever auth mode you choose.
Here are a few links that discuss implementing Basic Auth for Azure Web Apps and how to call such an app via PowerShell:
How to use the script (Invoke-WebRequest -Uri) to pass a parameter to your page
Use Invoke-WebRequest with a username and password for basic authentication on the GitHub API
How to use a C# code in the Web App to authenticate the request parameter
https://learn.microsoft.com/en-us/rest/api/datacatalog/authenticate-a-client-app
Since with basic authentication, credentials are passed in plaintext an can be easily decoded, we recommend that the web job calls the WebApp URL over SSL. Also, Basic Auth is one of the simplest authentication mechanisms, there are other more complex authentication schemes available too that you might want to explore.
I have Published my WebApi on azure as AppService. In Web API some urls requires client certificate and some not. I set certEnabled=true in AppService using ARMClient, but It makes my other calls(non-certificate) invalid.
When I researched on this issue, I came to know that certEnabled=true expects certificate for all calls.
I want to make request using certificate on specific api urls only.
What should I do.
I want to make request using certificate on specific api urls only. What should I do.
Unfortuntly ,it is not supported on the Azure WebApp currently. I also find a similar feedback that is underview by azure team. And optional client certificates for TLS mutual auth is also not supported now.
The only thing I have found is to allow both http and https, and then, in the code, filter which requests you accept on http.