I would like to build a web based application and use CloudKit as the only backend.
Understand CloudKit supports both Public and Private Containers (where data in public container is available to all users of the app and data in private containers is only available to the specific user)
What's the best practice to allow users to sign up for an application that is using CloudKit in the backend:
when user first lands on the application, is it a fair assumption that it gets redirected to apple authentication ULR and come back to the application as authenticated ?
Assuming CloudKitJs runs on client browser, how does it securely write to public container for the application - can any authenticate user (in step1) read/write to application public container or there is a way to differentiate ?
Related
Summary
I need to create an application where the user will subscribe to a plan that will give him a consumption of requests to the backend.
Backend: I will use nodejs and express to create the backend
Frontend: I will use reactjs to create the frontend. I will create the admin panel for user control you account.
Detail
I need to create a plugin for Wordpress that will consume these requests from the user's account. As I've never worked with this type of structure, I don't know how to guarantee that these plugins are the client's own and not someone who took his credentials and is spending his plan.
I took a look at RSA encrypt to make a data signature, but I still don't understand the best way to create this application.
I also saw about JWT but the plugin in wordpress would not have the account credentials to use JWT as login, and usually plugins and REST API using public key and secret key or api key.
Another use would be embedding a form on another site or using the REST API.
Im writing a application where I can have multiple users login and store their password in windows credentials. I currently can successfully validate the user's login. My question is where is the proper place to store the permissions(ex access to a certain page). I have several databases but I don't think that's secure. Possibly encrypt the data in the table. Or maybe in the local settings
You should use the PasswordVault class in a UWP app for storing user credentials so the app can validate silently to your cloud service later. Here are details on how to use the API.
for non-password, non-sensitive data, you can store it in LocalStorage or RoamingStorage but that is not secure. The only secure location to store data is on your service. Look to use something cloud-based like Azure Mobile apps to store that kind of info.
I created an Azure Mobile App Service which is currently accessible 'Anonymously'
Anonymous access is enabled on the App Service app. Users will not be prompted for login.
To make it secure I can enable App Service Authentication which will ask users to log in
But this is not what I want - The data in this app is only accessed by Application without the need of each and every user to login to my app before using it.
So you might say, in this case, Anonymous access is fine but I want to restrict it with something at least like an API Key so I will have access to the API which my app can use to access the data to prevent random requests as anyone can just go and use Postman and start getting data without any authentication.
So in short, I don't want individual user authentication, but at least an API Key to ensure only requests made from my app are authenticated and nothing else.
I am using the following in my mobile app to create a connection and also doing Offline sync etc
MobileServiceClient client = new MobileServiceClient(applicationURL);
Any idea how do I do that?
FYI. My server side backend is in C#
Since you are using Azure Mobile Apps, for your requirement, you could leverage Custom Authentication for building your CustomAuthController to login and generate the JWT token for a specific user without user interaction. The core code snippet for logging would look like as follow:
MobileServiceClient client = new MobileServiceClient("https://{your-mobileapp-name}.azurewebsites.net/");
client.LoginAsync("custom", JObject.FromObject(new{Username="***",Password="***"}));
Note: As the above tutorial mentions as follows:
You must turn on Authentication / Authorization in your App Service. Set the Action to take when request is not authenticated to Allow Request (no action) and do not configure any of the supported authentication providers.
And you must explicitly add [Authorize] attribute for your controllers / actions which need to be authorized access. Details you could follow Authentication in the Backend.
I would like to secure access to a ASP.NET Web API 2 as well as SignalR hubs both exposed using a self-hosted OWIN app hosted by a WPF desktop application. The WPF application is currently binding the OWIN HTTP listener to a TCP port on localhost for now, i.e it is not accessible from other machines.
The intention is that only my own other desktop applications as well as other third party desktop applications trusted by the end user (all running on the same end user machine as the WPF application) should be able to access the the Web API and SignalR hubs.
My current thought is to require the client application to authenticate with the WPF application, perhaps using a OWIN Authorization server (hosted by the WPF-application process) and a OAuth2 Client credentials flow where the WPF application would store the client credentials (client id and a salted password hash) in e.g., a settings file of the WPF application.
I have realised that since both the WPF application and all client desktop applications accessing it's Web API and SignalR hubs all run on the end user machine there is no point in attempting to "hide" any credentials used between the applications from the user. Since any encrypted password would need to be stored on the end user machine the desktop client applications may just as well use some security library or the underlying OS facilities to store an encrypted password knowing that the end user would be able to access it.
I have a few questions related to this.
Am I on the right track using OAuth2 Client credentials flow at all or is it inherently insecure when used for IPC on the same (end user) machine via the loopback interface?
With the realisation that the end user at least in theory have access to the credentials of a client desktop application and the end user could be a malicious user I have understood that in order to limit any damage done by a malicious end user only to that particular installation the same password for a specific client id should not be used in any two end user installations of the WPF application.
If the same password would be used a malicious end user A could install client desktop application with client ID X, reverse engineer it to retrieve the password stored by it, write his/her own malicious application Y tricking victim end user B to run the malicious application Y which would then impersonate client ID X using the same password to authenticate with the WPF application running on victim end user B machine.
Given that each client id must have a unique password for each end user installation of the WPF application I would still like to keep the establishment of trust between the applications as transparent as possible to the end user.
Any advice on this point would be very appreciated.
I.e., the less amount of steps needed by the end user to generate the password for an installed desktop client application and register the client id and password in the WPF application the better.
If OAuth2 is inappropriate for securing loopback (localhost) access to the ASP.NET Web API 2 and SignalR hubs. What would be the alternative?
Thanks
/John
I am building an online application using AngularJS on the front-end, hosted in an MVC 5/Web API application (basically a single-page application). However I have a hard constraint: the application's data will be held in a private network. I have to build a second Web API application inside the private network that exposes the web application's functionality. Further, the user authentication needs to happen inside the private network API (so the private network API will act as the authentication provider), as this is where the user tables exist.
The app in the DMZ is basically going to act as a proxy to the web API in the private network. So every request received in an ApiController in the UI API will be calling the private network API, ideally passing the token on received in the initial request.
From an authentication perspective, this is what I need:
User navigates to the site, can see only certain pages (I want to use MVC filters in the view controllers to control access).
They will log in once with a username and password.
After login the user can navigate to application pages and as a result the pages will call into the DMZ API for data.
This DMZ's API controllers will be calling into the private network API.
Both APIs whould be able to identify and apply authorization on their controller methods, based on the user's credentials.
If I didn't have a need for the second tier of API I would just use the MVC Single User Authentication implementation, which provides support for both cookie (UI) and token (API) authentication.
Any help providing insight into how I can do a similar thing with the above scenario would be much appreciated. (I guess my requirement is a bit like Windows impersonation for the UI web app).
See below for a high level view of the static architecture:
You may want to look at Azure service bus relays, which are designed to bridged the corporate firewall and call on-premise APIs.
Your WebAPI service would authenticate against the service bus to be allowed to call your service through it. You can pass user credentials using a bearer token in the request.
I'm not sure, but you may need to change your backend service implementation to use WCF though. You can find an explanation of the use of relays in Microsoft Dynamics in this link.