I am connecting to my Azure mobile services server through my javascript files. Meaning i create the client in the controllers page and sort/update/delete data there. Is this a safe way to access my database? Do I have to use another way?
You can control access to the table as a whole with the access
property:
authenticated means you must be logged in to access the endpoint. If you are not authenticated, a 401 Unauthorized response will be
returned.
anonymous means anyone can access the endpoint.
disabled means the table is invisible. The server will return a 405 Method Not Allowed response.
Normally, you would only use authenticated as an access value at the
table level. You can also set access at the operation level, and that is
why this option exists. Anonymous access is the default.
From https://shellmonger.com/2016/04/15/30-days-of-zumo-v2-azure-mobile-apps-day-8-table-controller-basics/
You can do this from Easy tables settings in the Azure portal.
Before you change the table permission to authenticated, you'll need to add authentication to your mobile app first. For more information, please refer to this tutorial.
Controlling access to your database via a REST API where you can do authentication and authorization checks plus data validation is absolutely the right way to go. Azure Mobile Apps is just one way to get there (in my, potentially biased, opinion, it's one of the better ways). However, it isn't the only way. You should certainly consider your requirements when making such a decision.
Related
I'm currently developing a MEAN based application, I was thinking about the Angular JWT local authentication.
The backend API verifies the token server-side, so is no problem, but in the client-side authentication is handled locally.
What happens if someone tries to modify the authentication scripts locally?Will he bypass the authentication?In the case how can I avoid the problem?
Your client side app only contains views, empty html, but no data. It's usually ok to let anybody see that, view structure need not be a secret in most cases.
You are saying the server does authenticate the user though, which is fine, only authorized data should be returned and filled in the view templates.
To put it in other words, there is no such thing as client side authentication in this sense. That's more like a ux feature to not show funcionality that the user cannot access anyway.
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.
Is there a method to secure a Manual Http Trigger in a logic App with Basic Authentication.
Is this achieved through APi Management.
The authentication mechanism used by Logic Apps is based on SAS keys that only a user with management access to the resource can list. In case any of the keys are exposed, you can use the /regenerateAccessKey operation on the logic app. See this article for details.
In addition there is a capability to restrict firing a logic app if not coming from a specific range of IP addresses. This is not yet surfaced in the azure portal (as of 2016-11-09), but could be done manually via PowerShell and/or the management APIs.
For any other authentication mechanisms you would indeed want to use API Management as a frontdoor to your logic apps.
I have been trying to determine a good strategy for authentication between a single WPF application of which calls to Web API services.
The client WPF app should be the only application to ever call the Web API.
I think I do have some unique requirements I must abide by. For example, The boss does not want to use ssl in any way; he is paranoid of users may having to deal with certificates.
Like I said, the client application is the only client using the Web API. The API just calls a list of stored procedures on a separate server.
Currently, we have a user membership database that does not align with any membership db standard, but we currently have over 200,000 members. One of the stored procedures currently authenticates the user with the membership db. The client application requires valid users to sign in to the application at start-up, however, we are wanting to secure all of the Web API requests sent from client to prevent non-valid requests being made to the server and so to prevent.
We are concerned about using the individual accounts or local authentication to essentially authenticate every web API request because of the added cost.
I have been thinking that what we are really needed to do is pretty much authenticate that it is our software client(WPF application) making the request and this authentication could open up all the controllers and actions for requests made by the client rather than the user. The user and its authentication is somewhat separate and is in place to prevent unauthorized users on a particular machines install of the application.
So you must have a valid user account to use the application.
Any suggestion would be great. I am just asking to get pointed in the right direction. I am really new to security so all suggestion will be valuable to me.
Thanks.
We would like to connect a salesforce user to another salesforce user in another org without any user intervention from a service.
We have tried SAML Bearer Flow (using Remote Access Application) to connect to salesforce to retreive Access Token for one of our product. We are referring to the follwoing article.
http://help.salesforce.com/help/doc/en/remoteaccess_oauth_SAML_bearer_flow.htm
As referred by the SF article for this flow, it uses a previous user authorization to connect and retreive Token. In case the user (for whom Token is requested) has not already authorized the App, SF takes you to the Authorization page first and app will get the access token once app is authorized. This is working fine too. However it has this painful step of users authorizing the app before we can use this flow for the product. It would be good and simplified if this step can be done once for an org and the article does mentions that either User or Admin can authorize the app. However I am not able to find how an Admin can authorize the remote access application.
Does anyone knows and can guide how can an Admin authorize an App or is thre any other way we can achieve our requirement. Any thoughts will be really appreciated.
OAuth1 and OAuth2 require user intervention by design. Anything you do to defeat this would be circumspect and not best practice. You could make it easy on the user, but you will always have the initial "Authorize this app" message.
If you are trying to make it easy for the user to login to either org, then you may want to consider a hub-and-spoke SSO solution. See this doc.
If you are trying to pass information between two Salesforce instances, then you may want to consider Salesforce2Salesforce, or outbound workflow. However, this is done at system context, not user context.
If you want to maintain user context and security, you should consider the new Salesforce Canvas API. Canvas allows you to call an outbound service, and pass credentials to the service so that it can communicate back. There is no reason the foreign service could not be a Salesforce instance.