I'm about to finish an app that will run on Windows Phone and Android. It uses an azure web API and push notification service.
I was wondering if there is any standard or recommended way of protecting the 'signup' or 'register' functionality within an app like this? I note that some popular apps like snapchat will send you a text to verify the registration process. That would be ideal but obviously seems unfeasible for a modest app such as mine :-)
Can anyone enlighten me to some common ways to protect the 'register' functionality of a mobile app?
Thanks for any help!
Azure provides feature sets like Azure Mobile Services that provide authentication features that you can use in your Windows Phone apps. I doubt the authentication Azure Mobile Services uses is restricted to just Azure Mobile Services, but more information on getting started with this authentication can be found here:
http://azure.microsoft.com/en-us/develop/mobile/resources-wp8/#header-2
Related
What is the best way to build Teams messaging extension using the bot framework without ngrock. My organization is not even allowing me to use it for testing or development. My web search pointed me to Azure Service Bus, Azure Relay and a dedicated NGINX Linux server with public IP. Just wanted to know what would be the ideal way and the costs associated it if someone has already developed an app?
I want to develop a product which simplifies the way of creating conversational chat bots using Microsoft BotFramework SDK. As we can build and host web application on-premise completely.
So can we build the similar thing using bot framework on a self hosted environment?
Here is the link for Microsoft Bot Framework: https://dev.botframework.com/
You can, indeed, build a bot entirely on-premises/self-hosted, provided that you don't need to connect to a Channel like Teams.
Background
Basically, bots communicate via:
User interaction with DirectLine Client (like Web Chat) ->
DirectLine API receives data and sends to bot ->
Bot hosted anywhere receives message
Note:
WebChat is just a DirectLine client. If you want to build your own WebChat, you can clone the repo and build it yourself. However, that all this does is make it so you can host your own webchat.js file, if you really want to be self-hosted.
Steps
With that in mind, all you need is:
A Direct Line client like Web Chat (specify domain property with your own endpoint when you call createDirectLine), or you can write your own client
You own DirectLine API implementation like offline-directline (more info)
Host your bot somewhere
Security
With this approach, you won't be able to use the typical appId/password setup.
You can manually implement our security protocol by following this document
Even though it is possible to manually implement the security protocol, we recommend reusing our existing open-source libraries
Based on answers, putting a more complete answer here. Since the option exists to have internet connectivity, I'd definitely suggest creating the solution as a "regular" Bot Framework bot, using the Azure Bot registration. Importantly, there are TWO options to do this - the most obvious one creates a "registration" for the bot but ALSO defaults to hosting it in an Azure Web App, which has a cost associated that can be quite significant. HOWEVER, there's another option, to create just a "Bot Channel" registration, which means you get a bot registered in Azure, but not necessarily hosted in Azure.
I've described this more in this post and you want to use the "Bot Channels Registration" in Azure, not the "Web App Bot". Then, on the "settings" screen you can define what the bot's actual address is (see here for a view of the Settings screen).
So, overall that should help - basically the bot just needs to have an HTTPS, internet-accessible endpoint. HOWEVER, that said, it's possible to host your bots inside Azure Functions, rather than Azure Web Apps, and the cost is dramatically cheaper (cents vs dollars, especially with low traffic). It's a bit of work, especially as the default samples default to the more standard options, but it works quite well.
I've recently launched a new blog, by the way, and I've got a post describing some of what I've learned so far about how bots work, that would be good to know as part of this. See How Bot Calls Actually Work.
We're in the process of migrating from an entirely on-premise solution with our own DirectLine server to Azure Bot Channels Registration because of the requirement for MS Teams integration.
I'm trying to create a simple Xamarin application that would need to use a local ADFS to identity the user. Indeed, I wrote an internal web application in ASP.NET Core but the client would like to have a light version as a mobile app, therefore, I need to authenticate the user the same way I do it for the web application: using ADFS 2019 + OAuth/OpenIdConnect.
However, I did some researches on Google and I find nothing talking about that specific case. Most articles concern Azure but I don't want to use Azure, I want to use a local ADFS.
Can anyone provide me with a link or some idea about the way to achieve this?
There's a set of good articles here that cover ADFS and OIDC.
The libraries are the same as the Azure ones - just the parameters are different.
We're getting ready to rewrite an old native windows mobile application that accesses data through a VPN. We'd like the new version (.NET Windows 10 mobile application) to access data through web services that are protected by Okta. What is the best way to do this?
Thanks!
The best way to do this depends on how the web services are protected.
The main thing to keep in mind is that you don't want to store any secrets on the mobile application.
In an ideal world, these web services would be secured with something like OpenID Connect (OIDC), allowing you to authenticate against Okta (the "IDP") to get access to the web services (the "Relying Parties").
However, the real world is messy, where some web services are protected via SAML, OIDC, OAuth, custom headers, etc.
Without knowing more about your setup, my recommendation would be to build against OIDC, using a proxy server (or "API Gateway") as needed to secure your web services using OIDC.
One of my co-workers at Okta has written a sample iOS application in Xamarin that implements OIDC, I suggest taking a look at the ViewController.cs file in that repository.
I have a PhoneGap App running on WP7 that I would like to connect to a Windows Azure Mobile Service. However, in order for this to work in my testing using JSFiddle.net I had to add the JSFiddle domain to the CORS settings in the Windows Azure Mobile Service.
Why do I need to add domains to the CORS setting on the server when doing a simple GET?
Since the Mobile Service requires a key from the JavaScript code I don't see why I cannot open up this web service to any request that supplies the correct key but adding . does not seem to work. If this worked I could move on to testing the scenario on the Phone.
Am I missing something architecturally here or is this just a feature that no-one else is looking for?!
If you want to allow any domain to access your mobile service, you can add the * in the list of cross-origin resource sharing hostnames under the configure tab.
Notice that the application key is not secure. From the 'How to use an HTML/JavaScript client for Windows Azure Mobile Services' tutorial (emphasis mine):
Application key: A unique value that is generated by Mobile Services, distributed with your app, and presented in client-generated requests. While useful for limiting access to your mobile service from random clients, this key is not secure and should not be used to authenticate users of your app.
The takeaway is that you should not count on that key to secure your service.