We have a PII masking requirement and I happen to come across a post here: https://social.msdn.microsoft.com/Forums/azure/en-US/0b38fd1e-8aa9-45f7-91a7-fd0631ef8bba/dealing-with-pii-or-sensitive-data-captured-by-application-insights?forum=ApplicationInsights
My question is how we do this for API Management (APIM)? As I am not sure how to associate the Custom Telemetry with API Management (as per MICROSOFT APP Insights Team it is not possible to set Custom Cloud Rolename or use Custom Telemetry in APIM).
As right now its all configured thru Azure Portal and no custom telemetry to it, our backend services (API) do use Custom Telemetry but in Azure portal, the PII data is marked as coming from APIM and not the APIs itself. Any help? Can someone help on how we can MASK Such data coming from POST request logged in App Insights from APIM?
Application Insights cannot control on what telemetry APIM instances would send to Application Insights, this is something need to be controlled from APIM stand point.
Hopefully you have request/response body logging enabled in APIM. Can you please check what are the bytes of body setting setup with in APIM and please make sure its specified as 0 (zero).
Additionally you can also check out the purge functionality which can be leveraged to purge the data which is already residing in Application Insights based on user defined filters.
Hope the above information helps
Related
We configured Azure web app infrastructure such way that consist
customer web portal and WebApp API site
Scenario: when a user accessing a customer web portal where all requests communicate from Web API like (GET, POST, DELETE, PUT).
Here actually the problem is Web API portal is publicly available for now (but I don't know about for what extent Web API visible to users publicly still requires or not?).
In our case Customer ----API call should be in internal communication only there no third-party vendors supply.
Is there any methods secure the cus--API.
We tried to secure cus---API azure network restrictions in Web API network settings but that not helps us (we got stuck the complete cus--API communication is blocked)
As I mentioned Web API hide from the internet then we applied Azure AD authentication for Web API.
In this case, we got results were negative
we have no prior knowledge from code level securing and communication token generation
Finally, we looking for suggestions, and suggest me what are security checks to WEB APP-API COMMUNICATING WITH CUSTOMER PORTAL. WHAT ARE SECURITY CHECKS THAT NEED FIGURE OUT?
Another big problem is really WEBAPP-API put publicly if yes then what are the ways to tighten security.
Please share ideas and suggestion it would be greatly helpful to us.
Thank you
I have a sheets bound google apps script file that is triggered by the installable trigger onFormSubmit(), which was set up by me. The script, therefore, always runs with my data, no matter who fills out the google form which I am collecting data from.
As a part of this script, the Drive advanced API is utilized, and I create and edit teamdrives using this advanced service.
I want to be able to use the Drive Advanced Service, with all of its authentication management and autocomplete features, while using a service account.
I've seen from other questions on this topic that there are libraries for the management and use of service accounts within Google Apps Script, but they require managing authorization tokens and such of the users which the service account acts on behalf of, and using them to access the API. Going this route, I will have to use the HTTP Interface for the Drive API rather than the Advanced Service, which isn't optimal, but still doable.
Is there a way to authorize advanced services such as the Drive API for a service account acting on behalf of a particular user of my G suite organization in my scenario?
Thanks in advance!
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 use APIGee for both API Proxy and Documentation, using a customized documentation site.
Following the recent APIGee outage this weekend, when I access my registered application list using my personal login on the documentation portal, I can no longer retrieve my application keys.
I get the error
STATUS: 404 - Not Found; Communication with the Apigee endpoint is
compromised. Cannot get API Products List.
The strange thing is that if I use my admin login at accounts.apigee.com, I can see 2 of my 3 applications listed... but one has disappeared. And more worryingly, this portal provides different application keys to the ones that were initially provided though the documentation portal.
I haven't been able to find any good documentation on this. How are these two sites linked together? Why are the keys different on both sites? What has caused my data to go missing?!
Tadhg -
This sounds like an issue that needs investigation by Apigee Global Support.
Would you please create an Apigee Support case? Please provide any applicable details, including your Organization name, the API call(s) you are making, the 3 applications you expect to see, and any other details you think might be helpful to diagnose.
Thanks!