I am working on Angular Application and I want to add Azure Application Insights in my Angular SPA.
I have added all required configuration and Everything works perfectly fine.
Application Insights will logs all required details like PageView and custom events with the Help of InstrumentationKey.
But I have one doubt, that What will happen if ApplicationInsights InstrumentationKey gets stolen?
InstrumentationKey is exposed to external world and anyone can see it.
So my question is, Is there any problem if somebody gets this key?
what are replications if InstrumentationKey gets stolen and how can we avoid it?
I have gone through this article already -
https://blogs.msdn.microsoft.com/premier_developer/2017/12/14/alternative-way-to-protect-your-application-insights-instrumentation-key-in-javascript/
As described in the blog,
Alternatively, the most secure way would be to send data from the browser to your custom API on your server then forward to Application Insights resource with the correct instrumentation key (see diagram below).
You should validate if the data makes sense in your custom API before sending it to the Application Insights instance.
Here are a couple of more threads on the same issue:
Application Insights security and spoofing
https://github.com/MicrosoftDocs/azure-docs/issues/24287
Related
Is there a way to see the response to a request in the logs generated through appinsights?
I’ve got several apis, and I can see the client making the calls when querying the requests table, I can see the status of the request but I can’t see what was sent back to the client.
Also when I click appinsights in my APIs it says
‘Set up app insights without changing code’
But above it, there’s a green tick saying ‘connected by Instrumentation code’
Does this mean it’s connected and working?
Does this mean it’s connected and working?
Yes, Application Insight connected to API.
Is there a way to see the response to a request in the logs generated through App insights?
If you want to see the response of your request/Custom Events or Custom Metrics, you need to use the Custom Telemetry in your API to get the response in Application insights.
Note: Make sure you can use it for testing purpose. In an application insight who ever have the access of your subscription of the specific resource they can view the telemetry data.
Reference
Custom Metrics in API
I have successfully deployed a Google Cloud Endpoints Developer Portal for my API running on Endpoints. I would like to provide access to testing to people outside my organisation that are not using GCP in their projects.
Login to the portal works correctly if I enable the Service Consumer role for these people (on per-email basis). However, when they open it for the first time, they are being asked to grant some extra permissions to the portal:
This form can create totally unnecessary security concerns. Does anyone know, why is it needed?
I only would like my clients to be able to test my API using a GUI, before they could start connecting their projects (not necessary on GCP) to mine. This seems to be a valid use case for me, however I might be misunderstanding some basic concepts.
Or should I submit a feature request to Google about a new role that only enables the access to the portal, and nothing else, so no such forms are shown?
Since Endpoints APIs must be explicitly shared with customers, the portal needs to verify that the logged-in user has permission to view that Endpoints API. So the short answer is that these scopes are being requested primarily so the portal can check the user's access to this API.
Longer answer is that we (the Endpoints team) are looking into if it's possible to build narrower OAuth scopes that would correspond to the access checks we perform. We agree that it's unnecessarily broad of an access request and are hoping to improve this in the future. Thanks for your comment!
Scenario: Auth0 Single Page application client. .NET Web API and Angular SPA both configured to use this client. Works great.
I'd like to add Azure API Management as a layer in front of the API. Have set up the API in the Management Portal, updated SPA to call API, tested calls from SPA, works great.
Now, I'd like to configure API Management Portal with the right security settings such that people can invoke API calls from the Developer Portal. I've used this [https://auth0.com/docs/integrations/azure-api-management/configure-azure] as a guide.
Where I'm at:
From the Developer portal, I can choose Authorization Code as an Auth type, go through a successful sign-in process with Auth0 and get back a Bearer token. However, calls made to the API always return 401. I think this is because I'm confused about how to set it up right. As I understand it:
either I follow the instructions and setup a new API client in Auth0, but if that's the case then surely it's not going to work, because tokens generated from one client aren't going to work against my SPA client? (or is there something I need to change to make it work)
or, how should I configure Azure API Management to work with a SPA application. (this would be my preferred method, having two clients in Auth0 seems 'messy'). But, don't I need an 'audience' value in my authorization endpoint URL? How do I get that?
If anyone has done this, would very much appreciate some guidance here.
Well, I didn't think I'd be back to answer my own question quite so soon. The reason is mostly rooted in my general ignorance of this stuff, combined with trying to take examples and fuse them together for my needs. Posting this to help out anyone else who finds themselves here.
Rather than take the Single Application Client in Auth0 and make it work with Azure API Management, I decided to go the other way, and make the non-interactive Client work with my SPA. This eventually 'felt' more right: the API is what I'm securing, and I should get the API Management portal working, then change my SPA to work with it.
Once I remembered/realised that I needed to update my audience in the API to match the audience set in the Client in Auth0, then the Management Portal started working. Getting the SPA to work with the API then became a challenge: I was trying to find out how to change the auth0 angular code to pass an audience to match the one the API was sending, but it kept sending the ClientID instead. (by the way, finding all that out was made easier by using https://jwt.io/ to decrypt the Bearer tokens and work out what was happening - look at the 'aud' value for the audience.
In the end, I changed my API, in the new JwtBearerAuthenticationOptions object, the TokenValidationParameters object (of type TokenValidationParameters) has a property ValidAudiences (yes, there is also a ValidAudience property, confusing) which can take multiple audiences. So, I added my ClientID to that.
The only other thing I then changed (which might be specific to me, not sure) is that I had to change the JsonWebToken Signature Algorithm value in Auth0 for my non-interactive client (advanced settings, oAuth tab) from HS256 to RS256.
With all that done, now requests from both the API Management Portal, and my SPA work.
Curious to know if this is the "right" way of doing it, or if I've done anything considered dangerous here.
Since you're able to make the validation of the jwts with the .Net API work, Only few changes are actually necessary to get this working with Azure API Management.
In API management,
Create a validate-jwt inbound policy on an Operation (or all operations)
set the audiences and issuers the same as what you've used with your .NET web api. (you can check the values in Auth0 portal if you don't know this yet)
The important field that is missing at this point is the Open ID URLs since auth0 uses RS256 by default. The url can be found in you Auth0 portal at: Applications -> your single page application -> settings -> Scroll down, Show Advanced Settings -> End points. Then copy the OpenID Configuration
Here's the reference for API management's requirement for JWT tokens
optional reading
I have spent days trying to get up to speed on this but everything has changed since I last touched a web project and I'm utterly overwhelmed right now, and getting nowhere. I'm trying to put together the pieces for an implicit grant flow - just a simple web API that respects the tokens issued by my local instance of I.S.
I have been able to download and configure I.S. v2 locally. I've got it issuing authentication tokens in JWT format after sending the browser to the login page. I can see the token info come back as part of the redirect URL from IS, like 'access_token=...&token_type=urn:ietf:params:oauth:token-type:jwt&expires_in=599'.
So now I need to configure my asp.net API site to accept these tokens, and I can't figure out how. As I said, I haven't done web work in a while so Owin, WIF, and many more things involved here are brand new to me all at once.
What are the key steps I need to do have my API site accept these tokens? I guess I'm not sure what packages to include, what goes into the web.config related to the WIF aspect, do I need to write any code to make it work, or should there be some combination of config settings that just activate it? Do I need to create a custom ClaimsAuhtorizationManager?
Please, I'm bad shape here, I've been looking at this stuff for days and I still don't know enough to even figure out what else to try. Every sample I've found has had a significant different from my situation, rendering it unhelpful to me (most point to Azure or ADFS, or use the old classes which are now deprecated). It's not for a lack of effort, I've been reading everything I can get my hands on and scouring the web for days.
Thanks in advance for any help.
IdSrv issues standard JWT tokens - so there is nothing specific to it.
You can e.g. use the JWT handler from Microsoft. For Web API v2 the typical way would be to use the JWT middleware - here is a sample:
https://github.com/thinktecture/Thinktecture.AuthorizationServer/blob/master/samples/Flows/ResourceServer%20(Web%20API%20v2)/App_Start/AuthConfig.cs
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.