Can I secure Application Insights write via an access token (similar to SqlConnection.AccessToken) or is InstrumentationKey the only method? If an access token is possible, does the C# TelemetryClient support it?
Instrumentation key is the only option. You might be concerned about security; Microsoft acknowledges this concern but doesn't feel it's a major risk. reference Google Analytics uses the same approach if it makes a difference.
Related
So long story short, I need to pass in a username and password to a web API in order to receive a JWT giving me access to use the API. I'll need to call the API for both web and console apps, so it will be used a lot.
I obviously don't want to call it using plaintext in the app(s) (them)selves because I don't want the credentials stored in version control. I also don't want to use Secret Manager or Environment Variables, because these apps will be used in production.
The only thing I can think of is storing the username/password (as plaintext) somewhere on the server and letting Windows Authentication handle the security of the data.
Is that a good practice though? I mean I guess it's as secure as the server is and if someone got access into the server we'd have bigger problems, but it just seems like it isn't good practice.
Also, I know Azure Key Vault would be ideal in this scenario, but the company is going through a lot of transitions and finances are up in the air with covid - so we're trying to minimize costs as much as possible for the time being.
Any one have any input?
I'm developing an API for a project I'm involved in. The API will be consumed by an Android app, an iOS app, and a desktop website. Almost all of the API is accessible only to registered users. The API allows authentication via WSSE which is great for the mobile apps, but not so great for the website. However, I'm using Symfony2 to develop the API, and I have configured it to allow access to the API by both WSSE and/or session/cookie authentication (multiple firewalls with common security context, if you're interested).
With an API-first approach like this, I'm concerned about things being abused. Take my signup method for example. I only want it to be used by the apps or the website. However, there's nothing to stop someone writing a simple script to hammer the API with bogus signups. Then there's the concern about CSRF. Because the API is can be accessed by a logged in user, then there's a risk that this can be exploited.
I don't want the API to be public, but I don't know if this is possible given that it will be used by the website. Is there anything I can do remove (or reduce) the risks and the vulnerability exposure?
Kind regards.
For the signup brut force problem you could enable a "rate limit" for your API calls.
This blog post introduces this concept and how to use it in a Symfony2 application thanks to the RateLimitBundle.
Is it possible to either turn off the api explorer completely or limit the access to it?
I noticed some logs in my app that come from failed requests executed from a browser. My api is only consumed by an Android app so the only place where they can come from is the api explorer. Also the api access is limited to 1 web and 1 android client id.
Unfortunately no. The API explorer works by using the Discovery Service associated with your API, which is not actually part of your backend, so you can't specify auth or visibility for those URIs.
The list method from the Discovery service is used to generate the list on the APIs Explorer app using your app as base:
discovery.apis.list:
your-app-id.appspot.com/_ah/api/discovery/v1/apis
When someone clicks one of the APIs from the list, the full discovery document is retrieved for that apiName and apiVersion using the getRest method from the Discovery service:
discovery.apis.getRest:
your-app-id.appspot.com/_ah/api/discovery/v1/apis/{apiName}/{apiVersion}/rest
If you are looking for ways to prevent the executing of the API, check out Cloud Endpoints: Control who can execute API through API Explorer
endpoints makes auth easy and you can get the current user. You should use auth to ensure people don't mess with your private apis - otherwise people could trace what kind of post or get requests you're sending anyway - auth is always a good idea rather than trying to keep your apis secret.
If you're building a secret product and you don't want your competitor to find out, you could perhaps use some obfuscation method on the backend and on your client which makes the apis unreadable.
Also a user messing with your apis shouldn't break your database - or if it does - it should only break it for the user that was being foolish. Having logic in your client for how apis are used so that the backend doesn't break is a bad idea - the backend apis should take care of themselves and not worry about how or why they are used and who by for what purpose.
In investigating federated authentication, I've been running into a protocol alongside SAML: HTTP-FED.
Curiously, I can't find any technical documentation for this protocol.
What is it? Is it, like I suspect, a claims-based protocol for use with HTTP instead of WS- services?
HTTP-Fed appears to be a creation of a commercial vendor (Symplified). It has not been ratified by any standards bodies (that I've found) which is why you probably can't find much on it. From what I've read on their website, it appears to essentially be a fancy name for credential caching/credential replay across the internet. From their site -- http://www.symplified.com/http-federation/
"... HTTP-FED leverages the existing HTTP login mechanism at the SP.
The implication of this is that no changes to the SP (destination
application) are required and no special software is needed by SPs,
thereby reducing the effort required to federate domains."
It's not a standard so there's no info on how you'd implement it outside of buying their product. If you're looking at Web SSO for Cloud Applications, I'd stick with actual standards (SAML, OpenID, OAuth, Open ID Connect) that are designed with security in mind for this type of activity.
I am a beginner in WCF and want to take some help in creating a WCF for my project.
I have to create a WCF service which can support 10,000 users simultaneous hits.
The job of the WCF service is to fetch a cached up XML object (we are using Enterprise Lib caching) and return it to the caller.
This WCF service will have to be publicly exposed. So I was thinking that we may have to use basicHttpBinding... I don't know, I may be wrong.
Can anyone please suggest the best way of going ahead with this?
Thanks a lot!
Don't use reliable messaging
Don't use sessions
Don't use transactions
Don't use Duplex
Don't use message security
Use BasicHttpBinding or NetTcpBinding
if you need security on HTTP, use HTTPS (TCP already implements encryption)
My personal view, don't use WCF if you need performance! :) Use ASP NET MVC with JSON message format and if you need security, use HTTPS.
This article might be useful - http://mikehadlow.blogspot.com/2011/03/7000-concurrent-connections-with.html