Azure Mobile Services .NET Updates

Support for CORS using ASP.NET Web API CORS enabling first class support for specifying CORS policy at a per-service, per-controller, or per-action level.

An extensible authentication model enabling you to control which authentication mechanisms are available for your mobile service clients. For example, you can add your own authentication mechanisms in addition to or in place of the default support for Azure Active Directory, Twitter, Facebook, Google, and Microsoft Account.

You can always let us know what you think via our MSDN forum or you can tweet me @frystyk.

Getting the Updates

Regardless of whether you start from a Mobile Service QuickStart or from a Visual Studio Project, you can you can get the updates (version 1.0.342) from NuGet. Simply go to the NuGet Package Manager in your Visual Studio project, select Updates, and type windowszure.mobileservices in the search window. It should look similar to this:

Install the Mobile Services updates by searching for windowsazure.mobileservices and you are ready to go. These packages will include whatever other updates they need so don’t update other packages manually.

By default, Azure Mobile Services enables CORS with a default policy that doesn’t allow any CORS requests. If you just want to set the list of allowed origin domains then you can do that via the portal or through config using the MS_CrossDomainOrigins app setting with a value of comma-separated origins, for example:

As always, you can of course also set a particular CORS policy on a per-controller and/or a per-action basis allowing for great flexibility in how you want to use CORS.

Extensible Authentication Model

Azure Mobile Services provides a common authentication model across Azure Active Directory, Twitter, Facebook, Google, and Microsoft Account. But in addition to these login providers, you can now add your own or even modify or remove the default ones.

Note that we leverage two new custom application settings (LinkedInClientId and LinkedInClientSecret) which can be set directly in the local Web.config file to set the LinkedIn client ID and secret through configuration – more about this later.

Second step is to ensure that the LinkedIn access token is added as a claim to our identity:

You can now run your service locally in Visual Studio and point your browser at the address /login/linkedin which after a redirect should provide a page looking similar to this:

Logging in using your LinkedIn credentials will then get you redirected to a final URI looking something like this: http://localhost:31475/login/done#token=<token>. To use your new LoginProvider from the client, you simply use the string “LinkedIn” to point to it:

The default Azure Active Directory LoginProvider supports the client side flow provided by Active Directory Authentication Library but this only works on client platforms where that library is supported.

To enable the server-side flow, which can work with any client supported by Azure Mobile Services, first install the Microsoft Azure Mobile Services .NET Backend Security Extension Nuget preview package into your server project. Then replace the default Azure Active Directory LoginProvider by doing the following in your Register method in the WebApiConfig class:

I thought this was already implemented. Now the support for AMS managed is GA. I think it will be implemented soon. I am using the standard mechanism for now. Had problems as well with the redirect-urls, but that’s fortunately history

Do I need to create new CustomRegistrationLinkedInController?
And how implement it?

Dmitriy Shatalov

Matthew Henderson solved my question – “In that case, I would hook into the CreateCredentials() method of your LinkedInLoginProvider. This is a method that gets invoked after each login, between the point where the runtime has validated the identity, but before a token gets issued. Here you could check to see if the record already exists and if not create one. You actually get the UserID in this method as part of the tutorial.”