I have created a key on Azure Maps, and used it on a html page to view a map.
But anyone can see my map api key if they view source of the page.
So, if a person have my key, they can use it on their website.
As you know this service is a paid service, no one wants their bill go high.
How can I restrict my Azure Maps Key use to a specific domain name?
Azure Maps now provides a higher security option via Azure Active Directory which can be used instead of a key: https://learn.microsoft.com/en-us/azure/azure-maps/azure-maps-authentication This can be used in both public and private applications.
I don't think Azure Maps allows you to restrict API keys to specific domains currently.
And even though Google and Bing both provide domain restriction for API keys it's not a full proof solution. Someone can still spoof your domain by forging the HTTP Referer header - See this.
So, ideally for full security (especially for paid accounts) you wanna do one of the following:
1: Have a light-weight back-end proxy for your app. Your front-end app/client calls your back-end (which can be a simple Node.js app) which first validates the client (up to you how to handle that) and simply passes the call to Azure Maps and gives the response back to the client. This way the key is actually stored in the back-end which uses it to make calls to Azure.
2: You can also think about storing your API keys in Azure KeyVault and fetch them at runtime. Here's a sample if you're interested.
Related
I have a React app that needs to communicate with several AWS services, each requiring secret keys and I know that I should not hard-code them into the JS.
I found this:
How do I hide API key in create-react-app?
Which basically confirms the following:
* Do not store true secrets in your JS
* Do not use env files either, because they are added to the JS at compile time.
* Use server-side code to deal with secret server-to-server communications, i.e. use a proxy
But my question is now one of clarity on this or "next step". My proxy server now handles all of the private communications with AWS. However, how do I confirm my app's identity to the server? In other words, if open the proxy up, anyone will have access to my AWS content. However, my actual users are not authorized to access my external services directly, so I can't just pass through those credentials.
My idea is to set up an application ID that will redirect only to the associated URL, but is that secure enough? The appID is in the JS, but the ID will only allow the proxy to send information back to the URL on record.
Thank you,
Wayne
I think your best bet would be to use AWS Cognito.
Users will auth with it, get back a token which can have IAM access rights attached to it if that is what you desire
I'm struggling with the correct way to secure a multi-tenant Web API with Identity Server. Let me explain.
We have a multi-tenant Web API that serves a ASP.NET MVC application.
Each new customer is assigned a new TenantId.
A customer can have multiple subscriptions of the application. Its
the same as saying that the app manages multiple databases per
customer (that he can access from the same base URL).
Each user belongs to a single customer (tenant) and will have access
to all that customer's subscriptions.
The API is set in a way that every endpoint includes both the tenant id and the subscription id so it can know from which subscription/database it should get the data.:
<server>/tentantId/subscriptionId/(...)
Now imagine that I have another external app (say a console app), using the client credentials flow, that is trying to access some API resource "on behalf" of a customer, meaning that will use a specific tenantId/subscriptionId pair:
<server>/1000/1/products
Every time a call hits one of the API endpoints I need to validate that this specific client app can access that tenant/subscription.
It would make a lot of sense if the Identity Server could perform that check automatically as part of the authorization flow.
If we added some way for the customer to register (consent) a specific client app to access the Web API on it's subscriptions, may be we could also set the Identity Server to know that in the form of scopes or at least include that information in the claims so that we could perform the permission check by inspecting the token instead of calling an external component.
Is this even possible?
Should I try to use scopes? Claims?
Can anyone point me in the right direction?
Your question is confusing when you talk about multi-tenancy. Isn't an API multi-tenant by default? The way I see it, it's a resource that can be accessed by multiple users / clients.
If I understand correctly, all you want is to access the API through the MVC app on behalf of a user. In other words: a hybrid flow with API access.
Instead of putting the userid in the path, use the id from the sub claim. Which lets the API distinguish between calls on behalf of clients and calls on behalf of users.
The resource should take care of authorization. Depending on the type of authorization you can use claims. If a subscription needs to be checked then this should be done by the API, using the sub claim to distinguish the user.
Scopes on the other hand are meant to define the resource. With the scope "api1" I can access the Api1 resource (api). But it says nothing about authorization.
IdentityServer provides Authentication as a Service.
It is your apps' duty to provide the actual Authorization.
I've read a lot of posts on here and in other places but I can't quite figure out what I should be doing to secure my API properly.
I've developed an anonymous questionnaire angularjs 1.* app that calls an asp.net core 2.0 web api. Users never authenticate and may, should they wish to, add their email address at the end of the process.
FYI, it's a CQRS backend and is hosted on an Azure VM.
I initially thought I would be able to use a service like Auth0 to create a token for a temporary user that contained both a unique ID for the person completing the questionnaire (like a sessionId) and the unique ID for the questionnaire being created (these are generated at the beginning of the process). However, I'm not sure this is right and I can't figure out how to do that and also verify it on the server (would I write a custom authorisation handler or similar)!
I also planned to use an API key (generated by Auth0) and validate that on each call. This seems easy enough although I'm not sure how I would secure the API key as it would be held in the client JavaScript.
Any advice would be greatly appreciated.
(intro)
I am new to Google Cloud Endpoints and I have started to build some HTTP REST services.
The purpose of those services is to be consumed directly by the users of my application (Business to Consumer - not business to business).
(The question)
I need to secure my services in a way to have only registered users being able to retrieve sensible data (and after login). My main purpose is to have the list of registered users saved in my database on CloudSQL (Dont want to use FB of Google Accounts). I was not able to find particular information about this point in the official Google documentation regarding authentication.
Can anyone advise me of the way to proceed and suggest some tutorials?
Thank you in advance.
The Endpoints proxy can validate JWTs, and we provide a couple of alternatives for creating those. Both Auth0 and Firebase have good user management capabilities and client-side libraries for generating JWTs. Both allow you to choose an identity provider (like FB or Google) or simply use username/password.
Check out the documentation here.
If you don't want to use Auth0 or Firebase Authentication, you can sign JWTs yourself with a private key and just give the proxy the URL of the Public Key (see the "Custom" tab on that same documentation page).
As far as looking up individual users in the database, you would have to do that part on your own.
I'm pretty new to SalesForce and their Apex language. I've been reading some documentation and tried the integration between Google and SalesForce.
I'm wondering is it possible to emulate an auth token from google to SalesForce?
I'm trying to read a google spreadsheet and then fill up a SalesForce object automatically. The user login will always be the same/universal for this spreadsheet, so I have the credentials required to login.
I am working off of the sample that requires a visualforce, and I'm wondering how would I automatically do the session id token that the google spreadsheet API requires.
Any ideas?
The old-school, hard way would be to send a login() call to the API (available through SOAP messages). Salesforce API is well documented and plenty of examples are available (both in programming languages and for raw XML requests/responses).
But I have no idea what possibilities you have from Google side, if it's only JavaScript then you might not be able to send and retrieve AJAX-like calls to another domain...
Recently another option emerged and that is REST API (no SOAP needed). Looks more promising and easier in my opinion. Quick intro is available here and you'll find more documentation on the bottom of the page.
Last but not least - 2 interesting links:
http://code.google.com/apis/gdata/articles/salesforce.html for some integration tutorial
and built-in integration offered by Salesforce: http://www.salesforce.com/assets/pdf/datasheets/SalesforceGoogleApps.pdf
I've used custom settings to do this. Use OAuth to get a token for Google, then store that token in Salesforce custom settings (Setup-Develop-Custom Settings). You can then retrieve the token for callouts to Google from that custom setting for any user needing access to Google Apps. The downside is, every user will authenticate as your custom setting token user. The upside is that they won't need to individually authenticate. Custom settings are retrievable via Apex using a simple getter, and live as Apex-like objects.
Also keep in mind, Google requires each service to use it's own token. So, if your user wants to use Calendars and Spreadsheets, that's two separate tokens that will need to be stored and retrieved for the callout.
I generally allow users to create their own authenticated session tokens via OAuth if they want to do that, then failover to the custom settings to get the general admin token if necessary.
Are you trying to log into Google Apps from SFDC? There are options for Google Apps within Salesforce, go to Setup > Administration Setup > Google Apps > Settings. I've not used this and it requires some setup, but thought I'd point it out. Aside from that I can only blurt out OAuth (getting users to authenticate with Google from within Salesforce when trying to access Google Apps) and SSO (which I know can be used to authenticate from an external system, though not sure if it works the other way).
Look into the "Named Credentials" menu in salesforce setup.
There, you can store auth credentials for the services accessed via Apex:
"A named credential specifies a callout endpoint and its required authentication parameters. When setting up callouts, avoid setting authentication parameters for each callout by referencing named credentials."
a username/pass combo can be used, or a certificate, or an AWS signature, and there is a JWT option..
Help docs: https://help.salesforce.com/articleView?id=named_credentials_about.htm&type=5