I'm trying to add / install Microsoft.Azure.Mobile.Server.Authentication into my PCL project but there is an error says
Could not install package 'Microsoft.Azure.Mobile.Server 2.0.0'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.5,Profile=Profile49', but the package does not contain any assembly references or content files that are compatible with that framework.
I've tried installing the previous version, but the exact same error appeared. I've also tried to changing Framework version to .NET 4.6, but other errors come up.
I want to use GetAppServiceIdentityAsync() method which only supported by that namespace. Is there any other way to add that reference into my PCL project?
As I known, GetAppServiceIdentityAsync is used to retrieve the Identity (ProviderCredentials) for the specific provider in your server-side code. For your mobile client, I assumed that you could leverage MobileServiceClient.InvokeApiAsync<List<AppServiceIdentity>>("/.auth/me"); to retrieve the identities and filter them with the specific provider, them you could get Provider, UserId and UserClaims properties as you expected. For more details, you could refer to Obtaining User Claims.
Azure Mobile Apps has two versions - one that runs on the server and the other runs on the client. You are trying to use the server version and that requires ASP.NET and .NET Framework 4.5+ (4.6 at the moment). It won't work in your client.
If you are using Azure Mobile Apps on the server, then you have already added a referenced to Microsoft.Azure.Mobile.Client and created a mobile client reference to your Azure App Service. You have also already configured your Azure Mobile Apps Server and linked your auth provider using Azure App Service Authentication. If you haven't, check out the book http://aka.ms/zumobook - this will give you the right instruction on this.
If you are still with me, you then need to do a HTTPS connection to your Azure App Service URL + /.auth/me - this returns a JSON blob which contains the provider information that Azure App Service Authentication knows about. One of the things that the service knows about is the auth token used to authenticate. You can then use this auth token to get additional information about the user if it isn't in the JSON blob.
A great way to get that information is to use the client.InvokeApiAsync<>() method as Bruce mentioned. This is covered in the book as well.
Have you tried to set the Android API Level to a higher level? I had this error by installing Moq and I could solve this problem with changing the Android API Level to the highest API level. Please try to use Android 7.1 (Nougat) with API-Level 25, also at the minimum SDK.
You can change it with: Right click on the project -> Options -> Build -> General -> Android Application
Under General you can also try to change the target version for the app to a higher level.
Related
This question refers to the article:
https://learn.microsoft.com/en-us/azure/app-service/app-service-managed-service-identity
I'm trying to figure out how I can simulate using the service principal that is generate for my azure application to work locally.
I followed the article and when I deploy azure function to azure and run it from there, I'm able to successfully use the MSI_ENDPOINT and the MSI_SECRET to successfully get the token. However, when i run the same deployment locally it fails. I use the exact same MSI_SECRET and change the MSI_ENDPOINT to the Domain that I use to the azure function endpoint.
Example: On azure the MSI_ENDPOINT = http://127.0.0.1:41831 and locally it is http://localhost:7071 (http://0.0.0.0:7071
However, when I run it locally I get a 404 error with the request. The request is http://0.0.0.0:7071/MSI/token?resource=https://vault.azure.net&api-version=2017-09-01 with the secret in the header. Exact same params with the working one loaded on azure except for the MSI_ENDPOINT.
Any advice on how to address this so I can run and test locally?
Using the Microsoft.Azure.Services.AppAuthentication library for .NET
for .NET applications and functions, the simplest way to work with a
managed identity is through the
Microsoft.Azure.Services.AppAuthentication package. This library will
also allow you to test your code locally on your development machine,
using your user account from Visual Studio, the Azure CLI, or Active
Directory Integrated Authentication. For more on local development
options with this library, see the
Microsoft.Azure.Services.AppAuthentication reference. This section
shows you how to get started with the library in your code.
Add references to the Microsoft.Azure.Services.AppAuthentication and Microsoft.Azure.KeyVault NuGet packages to your application.
However, this library is only available in .net which i'm not using and does not really explain how you would do it via REST call.
Thanks!
As far as I understand, MSI via REST works for you in the cloud, but not locally.
Unfortunately, it seems this is currently not easily possible when you can't use the AppAuthentication library. See this GitHub suggestion.
So if you don't want to hack some debug code into your production code, you probably need to host a "custom MSI proxy" locally which just performs the classic authentication via client credentials (appId + secret) to return the token.
curl -d "grant_type=client_credentials&client_id=<removed_for_security>&client_secret=<removed_for_security>&resource=https%3A%2F%2Fvault.azure.net" https://login.microsoftonline.com/<removed_for_security>/oauth2/token
Note that I added the KeyVault as the resource parameter. See your built MSI URL - http://0.0.0.0:7071/MSI/token?resource=https://vault.azure.net&api-version=2017-09-01
UPDATE: DNX does not exist anymore. Please ignore this question.
Current WindowsAzure.ServiceBus (3.0.4) nuget package (http://nuget-preprod-0-v2gallery.cloudapp.net/packages/WindowsAzure.ServiceBus/) requires .NET Framework 4.5 Full Profile and it is not usable with an application build specifically to use DNX Core.
As I understand, the only way to build such application at this moment is to use REST API.
What is the recommended way to include authentication information to requests? Do we have any open source nuget to handle it or should the SAS token creation be implemented by each developer? Links to the REST API authentication samples are broken.
While the Service Bus nuget package is not open sourced, do we have any active channels to reach the developers to find out if they have any plans to support DNX Core and we should not use REST API because the library update is coming soon?
The REST URL to publish a message on Queue/Topic will be like,
http{s}://{serviceNamespace}.servicebus.windows.net/{queuePath|topicPath}/messages
The authorization SAS Token has to be part of the request header
For further read, REST Run-Time APIs
It's also possible by using the AMQP protocol. I recently used AMQP to communicate with an Azure IoTHubClient, all in a DNXCore5.0 project. I used the AMQPNetLite Library to do so, it also has Service Bus Examples!
(Reposting as my prior answer was erroneously deleted by the moderators.)
Microsoft now provides a .NET core version of this library. I am shipping a .NET Core app on Linux that calls it.
https://github.com/azure/azure-service-bus-dotnet
Announcement post:
https://blogs.msdn.microsoft.com/servicebus/2016/12/20/service-bus-net-standard-and-open-source/
I'm trying to access an Azure DocumentDB database from a universal app I'm developing.
I've created a short sample of code that accesses my database based on the following sample:https://github.com/Azure/azure-documentdb-net/blob/master/tutorials/get-started/src/Program.cs
I've put that in a Console Application and it works fine.
Now, just moving this code to my universal app doesn't work as the Microsoft.Azure.Documents.Client.dll cannot be added to the references of the universal app (not targeting the same Framework).
So, I've created a portable class Library that would provide the database access to my solution. I've tried to install Microsoft.Azure.Documents.Client.dll through NuGet, which didn't work. So I've manually added the reference which did seem to work.
But, when trying to compile the code, I get an error on this line:
_client = new DocumentClient(new Uri(_endPointUrl), _authorizationKey);
Error:
CS7069 Reference to type 'SecureString' claims it is defined in 'mscorlib', but it could not be found MyProject.StorageManager
So it looks like it didn't like the .dll either.
Here's where I am, it seems that each project type in which the documentDB code works cannot be used by an universal app.
Am I missing something?
The DocumentDB .NET SDK does not work from a store application, yet. This is something we're working on providing.
For now, there are two approaches you can consider
1) use a Middle tier to access DocumentDB (either Azure Mobile Apps, or your own Web Api)
2) use the JavaScript client SDK to talk to DocumentDB directly from the app (but you need to have a service that generates resource tokens for the client to use as using master key on the client is not supported for security reasons).
My problem is that I have a NuGet server on an Azure website using Azure AD for auth. It works as expected if I hit the NuGet URL in Chrome (requires the login, which accepts appropriate credentials), but if I try to access it in Visual Studio 2013 (through manage NuGet packages) it won't accept the account/password as appropriate credentials (the prompt just pops up again). My approach was as follows:
With the goal of creating a simple internal NuGet server, I largely followed the instructions in this article to deploy one on an Azure website: http://www.codeproject.com/Articles/872230/Create-Your-Own-Private-NuGet-Server-in-Windows-Az
The NuGet server works just fine, but I wanted to add some basic auth since we'll be hosting some of our code there. I decided to try to use Azure AD for this. I added a couple Microsoft accounts (mine and a coworker's) to our otherwise empty default Azure active directory. Through the management portal, I then selected the 'configure' tab in the website dashboard and added the default directory in the auth section.
Since the developers who will be pulling down our packages will do so through Visual Studio, I need to figure this out or find an alternative. I would like (if possible) to avoid writing my own auth module, since this feature is supposed to be baked into Azure.
It turns out that NuGet does not currently support Azure AD. However, they are working on it and progress can be tracked here: https://github.com/NuGet/Home/issues/708
I am currently doing some research for the development of a mobile application for our company that should support offline data sync (on an iPad). We have explored many possibilities including PhoneGap/Cordova, Xamarin and simply native iOS development. Xamarin, for many different reasons, seems to be our best choice, so my question will assume we will develop in Xamarin.
I was looking into a library for managing offline data synchronization and the most obvious solution is Microsoft Azure MobileServices. However, my company is Canadian, and apparently it's hard to trust (legally) our data to clouds based in the US. Since we already deployed internally our WebApi on our intranet, I figured there was probably a way to point the MobileServices library to our own WebApi. I have read about the Azure Hybrid Connection possibility, but our data still conveying through Microsoft servers might not be a possibility. So, my question is this:
Is there a way to configure the Microsoft.WindowsAzure.MobileServices Client library to point directly to our intranet, RESTful WebApi backend, without going through any Microsoft Azure servers ?
I understand that, in order to be able to use the Client librairies seamlessly, we probably would have to adapt our WebApi to implement the necessary .net Backend interfaces. I'm mostly wondering if it's even possible as the MSDN documentation on the libraries all seem to point to direct connections to their servers (no possibilities to configure your own connection strings) and all instructions redirect you to their Azure Mobile Services website.
Thank you.
If you look at the API for your mobile client, you'll notice that the Azure Mobile Services Client SDK only cares about two things:
new AzureMobileClient( url, appkey)
...where it's hosted shouldn't be a concern. Everything else is just configuration.
If you want to host the Azure Mobile Services Backend on your own servers, technically you could do this, but there are likely a few caveats. Microsoft has announced that they will be launching a Canadian Azure data center, but we won't see it until 2016.
In the meantime, here's how you can host the services locally. Note that I have not tried to emulate all of the features of Azure Mobile Services (aka Zumo) so your mileage (or kilometerage) will vary.
Hosting Locally:
From a technical feasibility, you absolutely can run the services locally. I know this because you can create the Azure Mobile Services Backend project from within Visual Studio and run it locally for development purposes. This is what our development team does for testing their mobile applications.
Note that you can create the Azure Mobile Service backend directly from within Visual Studio: New Project -> Cloud -> Azure Mobile Service. You can also download the exact same template (pre-configured with your URL and ApplicationKey) directly from the Azure dashboard: Create -> Mobile Service.
Obviously, if you're hosting it on your server it will be up to you to configure and use a proper SSL certificate for your site.
ZUMO Permissions:
By default, the security roles on the server are turned off. So if you're locking down any of your methods using the [AuthorizeLevel] attribute these settings will be ignored at runtime. If you need to enable this feature you can do so by modifying the WebApiConfig.Register() method and marking the site as self-hosted: config.SetSelfHosted(true).
Configuration:
From a configuration perspective, the Azure Mobile Service dashboard provides several tabs for configuring Identity, Push Notifications, Connection Strings and App Settings. Sadly, you won't have a dashboard, but all of these settings have a corresponding value in the local web.config. Any value you provide here is automatically overwritten in Azure, but they're used when running locally.
The minimum settings you'll need to configure are listed here. The ApplicationKey you can distribute with your ZuMo client, but the MasterKey is for the Admin authorization level so you'll want to keep that secret. The MobileServiceName is used by the EntityFramework for your database schema and what appears in the URL of your site.
<add key="MS_MobileServiceName" value="myzumosite" />
<add key="MS_MasterKey" value="masterkey" />
<add key="MS_ApplicationKey" value="appkey" />
Values that start with a MS_ prefix map to corresponding values in the Azure Portal. MS_GoogleClientID and MS_GoogleClientSecret map to the Google Identity values in the dashboard, for example.
Any other value in the AppSettings node is immediately accessible via the ApiServices.Settings property and corresponds to the Settings node in the Azure dashboard.
Database connection strings continue to exist in the connectionStrings node. The same is true for azure notification hub.
Database:
Obviously, the database you configure will be up to you as well. Permissions and User accounts are also obvious. There may be some minor differences between the SQL Azure syntax for Entity Framework database migration scripts that you'll need to worry about. (I've discovered the database migration scripts don't work from the Package Manager, but they do work when the database scripts are run when your website starts)
Caveats:
You will not have a nice dashboard for monitoring performance of your site, reviewing logs or changing runtime settings
You will not be able to scale out your site immediately; Scaling and deployment will be your problem
Deployment configuration is your responsibility (Project -> Publish won't be available unless you configure it)
Not sure if you'll be able to use Azure Active Directory as an authentication scheme, though from the sounds of it that won't be a concern. You can write your own authentication providers: Microsoft's Zumo library only supports a handful, but the underlying Owin.Security package that Microsoft uses supports several dozen systems!
Your site will need to be publically visible to your mobile clients
Push Notifications should work, but you will be using Azure's notification hub for this.
I have no idea where ApiServices.Log will go
The easiest path to take would be to:
Create the Mobile Service in Azure to get the notification hub and settings preconfigured
Download the starter site from the dashboard
Configure the web.config as mentioned here.
It's not possible to simply configure WAMS Client library to work with your own WebApi Backend.
But WAMS library is available at github, so I'm sure you can reuse a lot of code from the WAMS project, especially if you want to use a PCL project.
To route your data securly through Azure, you could think about setting up express route. Additionally, for last weeks update, it's possible to apply a custom domain to the WAMS Backend, including your own certificate to secure your connection.