Subscribe: Nick Randolph's .NET Travels
http://feeds.feedburner.com/NickRandolphsDotNetTravels
Added By: Feedage Forager Feedage Grade A rated
Language: English
Tags:
access  application  azure  code  forms  library  net standard  net  project  user  visual studio  visual  xamarin forms  xamarin   
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Nick Randolph's .NET Travels

Nick Randolph's .NET Travels



Continually looking for the yellow brick road so I can catch me a wizard....Join me as I explore the world of cool devices, neat technology and uber geeks. I spend most of my time talking about Microsoft related technologies such as the .NET Framework, SQ



 



Getting Started: Xamarin Forms with .NET Standard 2.0

Wed, 13 Sep 2017 19:24:47 +0600

In my earlier post Getting Started: Xamarin Forms with .NET Standard I covered how to create a new Xamarin Forms project which uses a .NET Standard 1.4 library to share the views between iOS, Android and UWP. At the time, whilst iOS and Android supported .NET Standard 2.0, support still wasn’t available for UWP. Almost immediately after publishing the blog post, Microsoft announced that Visual Studio 2017 preview 15.4 would allow UWP applications to reference .NET Standard 2.0 libraries. Unfortunately this didn’t work in the first drop, 15.4.0 Preview. This was just updated to 15.4.0 Preview 2 (Release Notes: https://www.visualstudio.com/en-us/news/releasenotes/vs2017-preview-relnotes), which brings with it the support we’ve been after. In this post, I’m going to repeat the previous post on getting started with .NET Standard, this time using .NET Standard 2.0 for the UI project. Let’s walk through the basics – create a new Cross Platform App (same as before)Select the Xamarin.Forms (UI Technology) and Portable Class Library (PCL) (Code Sharing Strategy) – Don’t pick the Shared Project option!Select the Insider Preview version of UWP for both Minimum and Target version – this is required for .NET Standard 2.0 support. If you want to target earlier versions of Windows 10, you’ll have to stick with .NET Standard 1.4.Next, we’re going to replace the PCL with a new .NET Standard libraryI’ll copy the App.xaml, App.xaml.cs, MainPage.xaml and MainPage.xaml.cs from the PCL into the .NET Standard library, before deleting the PCL from the project (see https://nicksnettravels.builttoroam.com/post/2017/08/26/Getting-Started-Xamarin-Forms-with-NET-Standard.aspx for more detailed instructions). The big difference is that I’m not going to change the default Target Framework, leaving it as .NET Standard 2.0.Next I need to make sure I add and upgrade references to Xamarin.Forms to each of the projects – this isn’t actually required, since the stable release of Xamarin Forms will actually work with .NET Standard but I’ve been working with the pre-release version quite a bit lately, so I’ll go with that for this example.I also need to remember to add a reference to the .NET Standard project to each of the head projects for iOS, Android and UWP.If you attempt to build and run at this point iOS and Android should work without issue. UWP will most likely compile but will raise an exception “Could not load file or assembly ‘netstandard, Version=2.0.0.0….” at runtime.Essentially the UWP project structure has evolved a little, so you need to upgrade it. Now I think that you may be able to do this via package manager but I’ve never got it to work for UWP projects, so I will make the changes manually to the csproj file. Start by deleting the project.json file from the UWP project.Next right-click the UWP project in Solution Explorer and select unload project. Next, right-click on the UWP project node and select Edit MySecondXamarinFormsApp.UWP.csproj. Add a new PropertyGroup – this changes the way packages are referenced, eliminating the need for the project.json file, replacing it with references within the csproj file.   PackageReference Next we need to add back the package references that were in the project.json – if you’re doing this on an existing project, you may want to keep the project.json file handy so you know which packages to add. In this case there are just two projects:        6.0.0-preview1-25631-01           2.4.0.269-pre2   Now you can right-click on the UWP project in Solution Explorer and select Reload project. Trigger a rebui[...]



Source Code Debugging with BuildIt Libraries

Sun, 27 Aug 2017 07:34:55 +0600

I was working on the BuildIt libraries yesterday and got slightly distracted – I was looking for how to make a small change to the way the Nuget packages are generated and ended up investing time in getting symbol source server support added. At first I thought “this is going to be easy and so awesome” but this quickly turned into frustration as it just didn’t seem to work. Turns out that whilst I was able to successfully generate the nuget symbol package locally, what I’d forgotten is that because we separate our build and release process (done via Visual Studio Team Services), I needed to make sure all my source code files are added to the build artefacts. The nuget packages are generated as part of our release process, which includes generating the symbol package which needed to include the source code files.The upshot is that I’ve got source code debugging added to both BuildIt.General and BuildIt.States, with other packages to get it as we roll out stable builds in the coming weeks.To get source code debugging to work, the first step is to configure Visual Studio to use the symbolsource server when attempting to step through source code. I followed the instructions at http://www.symbolsource.org/Public/Home/VisualStudio, which I’ve repeated here with the exact setup I used:In Visual Studio:Go to Tools -> Options -> Debugger -> General. Uncheck “Enable Just My Code (Managed only)”.Uncheck “Enable .NET Framework source stepping”. Check “Enable source server support”.Uncheck “Require source files to exactly match the original version”Go to Tools -> Options -> Debugger -> Symbols.Select a folder for the local symbol/source cache (I just used c:\temp\symbols)Add symbol servers under “Symbol file (.pdb) locations”.http://referencesource.microsoft.com/symbolshttp://srv.symbolsource.org/pdb/Public http://srv.symbolsource.org/pdb/MyGet http://msdl.microsoft.com/download/symbols With this all setup, you’ll find that the next time you run your application it will be incredibly slow to start debugging as it has to go through and look up the symbols for each library you have references. However, when you do finally get your application up and running you’ll be able to step through and see more information about what’s going wrong with third party libraries that have symbol and source code support.For the BuildIt libraries (General and States) the only additional step is to update to the latest stable release (1.1.0.75 at time of writing). Run the application, and you can now step through on calls made to functions contained within these libraries. You’ll also be able to intercept any exceptions that are raised within the libraries.Happy Debugging! [...]



Getting Started: Xamarin Forms with .NET Standard

Sat, 26 Aug 2017 06:12:28 +0600

With the recent release of Visual Studio 2017 v15.3 (and subsequent patch release 15.3.1 and 15.3.2…. yes, it does say something about ship quality ) came the release and support for .NET Standard 2.0. The Xamarin team also made a lot of noise about support for .NET Standard 2.0; unfortunately this doesn’t yet translate into Visual Studio templates that easily get you started. My particular annoyance is the about of steps you need to go through in order to just spin up a new Xamarin Forms application that can reference .NET Standard libraries. I thought I’d piggyback of a post done a couple of months back by Pierce Boggan. Here goes:Start by creating a new project in Visual Studio 2017, selecting the Cross Platform App (Xamarin) project template:Next, select the template you want (I’m going with the Blank App), the UI Technology and Code Sharing Strategy. As I’m going to be walking through how to use Xamarin Forms, it makes sense to pick that as the option for UI Technology. Only select the Portable Class Library option. Don’t use the Shared Project – using a shared project will lead you down the evil road of using conditional compilation which will be a maintenance nightmare, just don’t use it. I don’t care how great you think it is, don’t use it. One last time, don’t use the Shared Project option. Now that I’ve expressed my opinion on code sharing strategies, let’s click the OK button and get on with building our application. As the template goes through generating the head projects for iOS, Android and UWP, it will prompt you to select the target and minimum platforms for UWP. For the most part, unless you have specific target platform requirements for UWP, you can leave the default settings.The generated solution will have four projects: three head or target platform projects (for iOS, Android and UWP) and a portable class library (PCL) which contains the XAML pages that will make up your Xamarin Forms application layout. In order to proceed with .NET Standard support we need to replace the PCL with a .NET Standard library. Whilst Visual Studio used to have a mechanism for upgrading a library from a PCL to a .NET Standard library, this has been removed. Now the easiest way is to simply create a new project, and copy the relevant files into the new project. From the Add New Project dialog, select the Class Library (.NET Standard) template.I use the .UI naming convention for the library that will contain my XAML pages. Other developers use .Core but my preference is to separate my XAML pages away from my view models. Whilst technically with Xamarin Forms they can reside in the same library, I prefer to have a clean separation between them. I have .UI with my XAML pages in it and .Core with my view models, services, entities, essentially all the business logic for my application.For this example I’m going to keep it simple and we’ll just create the .UI project for the moment.I don’t need the default Class1.cs, so I’ll remove that. I’ll add a reference to the .NET Standard library to all the head projects.I’m also going to drop the .NET Standard version back from 2.0 (now the default in Visual Studio) back to 1.4. Whilst the tooling has been updated for the head projects for iOS and Android to support .NET Standard 2.0, of course, UWP is still lagging the field, as so you won’t be able to use a .NET Standard 2.0 library until that’s fixed. To be honest though, not much is lost by lowering the version of the .UI project to 1.4 since all the features of Xamarin Forms are still there.Next I’m going to copy App.xaml (and App.xaml.cs) and MainPage.xaml (and MainPage.xaml.cs) from the PCL into the newly created .NET Standard library. Once I’ve copied these files across I can remove the PCL project from the solution – this will remove the references to this library from each of the head projects. After coping these files across, you may well see a compilation error similar to the f[...]



Visual State Transitions in Xamarin Forms with Animations

Sun, 25 Jun 2017 05:34:31 +0600

In previous posts (Visual States in Xamarin.Forms using BuildIt.Forms and Xamarin.Forms Visual States with View Models) I demonstrated how the BuildIt.Forms library (https://www.nuget.org/packages/BuildIt.Forms) could be used to declare visual states for pages, and controls, within Xamarin Forms. Today we just added some basic support for animations so that as you transition between visual states you can animate elements of the screen:The following visual states define animations for rotating a green square:The Hide visual state defines three animations that run in parallel, with the rotation being a sequence of animations. The Show visual state has the reverse animations to return the green square to the original starting position. Unlike the setters, there’s no built in support for returning the element to its unchanged state.                                                                                                                                                                                                                                                                                                                                                 [...]



Adding Fluent Design Acrylic Material to UWP via Xamarin.Forms.

Sun, 11 Jun 2017 19:48:03 +0600

At Build Microsoft made a big deal out of the new Fluent Design that they’re encouraging developers to start taking advantage of. Out of the box it’s a little harder to take advantage of these features but using BuildIt.Forms it’s easy to start using acrylic material resources. Let’s extend the example I’ve covered in the last couple of posts (Visual States in Xamarin.Forms using BuildIt.Forms and Xamarin.Forms Visual States with View Models). I’ve added a Grid, that will span the whole page (the StackLayout was positioned to keep all the elements in the centre of the page) and included the BackgroundEffect to set the background of the whole page.                               



Xamarin.Forms Visual States with View Models

Sat, 10 Jun 2017 20:38:26 +0600

In my previous post, Visual States in Xamarin.Forms using BuildIt.Forms, I showed how to use BuildIt.Forms (https://www.nuget.org/packages/BuildIt.Forms) to create visual states that can be used to define how the user interface changes to reflect different states of the page. The example demonstrated switching between visual states in the code behind with calls to VisualStateManager.GoToState. In this post I’m going to extend the example to allow the states to be switched from a view model.I’ll start by creating a view model that will be data bound to the page. Usually I’d use a framework like MvvmCross to drive the view model/view instantiation but for this example I’ll keep it simple. I will however still put the view model in a separate project – again this promotes good separation between the view models and their associated view. I’ll create a new .NET Standard library, FormsWithStates.Core, and add a reference to it into the FormsWithStates.UI project.I’ll add a new class to the project, MainViewModel, which will be the view model for the MainPage of the application. To track states within the view model, I need to add a reference to the BuildIt.States library on NuGet.The MainViewModel will define a simple property WelcomeText to demonstrate that the view model is indeed data bound to the page. It also implements the interface IHasStates which defines a property StateManager – you can think of the IStateManager implementation as an object that can track states and state transitions. public enum SampleStates {     Base,     Show,     Hide } public class MainViewModel : IHasStates {     public IStateManager StateManager { get; } = new StateManager();     public string WelcomeText => "Welcome to Forms!";     public MainViewModel()     {         StateManager.Group().DefineAllStates();     }     public void Show()     {         StateManager.GoToState(SampleStates.Show);     }     public void Hide()     {         StateManager.GoToState(SampleStates.Hide);     } }The enumeration SampleStates defines the states that the MainViewModel references – both the enumeration and the states themselves have to match the names of the visual state group and visual states defined in the XAML for the page. The final step is to link the visual states on the page to the IStateManager instance, so that when there is a state change in the IStateManager, it will be reflected on the page via a change to the visual states. This is done by the Bind method on the VisualStateManager class.public partial class MainPage : ContentPage {     private MainViewModel ViewModel { get; } = new MainViewModel();     public MainPage()     {         InitializeComponent();         BindingContext = ViewModel;         VisualStateManager.Bind(this, ViewModel.StateManager);     }     public void ShowClicked(object sender, EventArgs e)     {         ViewModel.Show();     }     public void HideClicked(object sender, EventArgs e)     {         ViewModel.Hide();     } }Whilst from the perspective of a user, there is no difference (since the Show and Hide buttons do the same thing), state management has been shifted to the view model [...]



Visual States in Xamarin.Forms using BuildIt.Forms

Sat, 10 Jun 2017 06:03:54 +0600

A couple of weeks ago I started building out some helpers to make working with Xamarin.Forms a little nicer (see Styling Pages and Controls in Xamarin Forms using Visual States,Rebuilding the Xamarin.Forms Button with Visual States and Control Templates and Ambient Properties in Xamarin.Forms). Since then we’ve been working on building out a library that encapsulates these features, again making it easier for us and others to build apps using Xamarin.Forms. There is now a pre-release version of BuildIt.Forms (https://www.nuget.org/packages/BuildIt.Forms) that anyone can reference to take advantage of these helpers. The library makes use of some methods/properties that are only available in the pre-release version of Xamarin.Forms, which is why we don’t have an actual release out yet.In this post I’m going to walk through using visual states in a Xamarin.Forms project. To set the scene, I’m going to step through creating a new Xamarin.Forms project in Visual Studio 2017 (current RTM build, not the preview, although the preview build should be similar). I’ll do this in this post to make sure the basics of creating a Xamarin.Forms project that uses a .NET Standard Library instead of a PCL library is covered. I highly recommend switching to a .NET Standard library as soon as possible to avoid issues with upgrading nuget references etc (most third party library now have a .NET Standard version and it will become increasingly harder to maintain and update your old PCL libraries).Ok, so let’s get started with a new project – I’m going with the Cross Platform App (Xamarin) template in the New Projects dialog:Next, I’ll select the Blank App template, using Xamarin.Forms (UI Technology) and Portable Class Library (Code Sharing Strategy). Side note here – I highly recommend not using the Shared Project option for Code Sharing Strategy; using this option is a recipe for disaster as it promote poorly separated UI logic and allows for using conditional compilation based on #defines which is not a good strategy if you want maintainable code. After clicking OK my solution has four projects: A PCL which has got the Xamarin.Forms UI defined in XAML files, and three “head” projects, one for each target platform. At this point, I would suggest running each project to make sure you have a working application before going any further (and commit this code to your source repository before going any further!)Now to replace the PCL with a .NET Standard library. I’ll add a new .NET Standard class library. I like to make it clear that this library will contain the UI for my Xamarin.Forms project by using the .UI suffix. I do not include my view models in this library – I’ll talk about this in a subsequent post.After creating the new class library, I just need to copy across the XAML and .cs files that were in the PCL library (App.xaml, App.xaml.cs, MainPage.xaml, MainPage.xaml.cs).  I can then remove the PCL library from the solution. Of course, I need to go through each of the head projects and add a reference to the UI project.At this point I would again build and run the application on each platform – If you do this without doing anything the solution won’t compile as the UI library doesn’t have a reference to the Xamarin.Forms NuGet library. I suggest adding a reference to the Xamarin.Forms NuGet library and then upgrading any libraries where there is an update available. Again before proceeding, build and run each platform.The next step is to add a reference to BuildIt.Forms. This is a prerelease library so you’ll need to check the “Include prerelease” option when searching. You need to add this library to all projects, even though you’ll only be adding code into the UI project – this makes sure the platform specific libraries that are included in BuildIt.Forms are correctly referenced and will be included.As part of referencing Bu[...]



Ambient Properties in Xamarin.Forms

Sat, 27 May 2017 20:12:53 +0600

One of the aspects of XAML that is often misunderstood is that of ambient properties. Probably the best example of this is being able to set the foreground colour on a Page in UWP and for the foreground color to be set on every element on the page. Unfortunately this doesn’t seem to be something that’s available in Xamarin.Forms, which lead me to wonder how hard it would be to implement.

The implementation would be slightly different from UWP which uses the AmbientAttribute. Instead I’ll create an attached property which can be set on any element. The ForeColor will be then set on each child element, unless the TextColor is explcitly set on an element.

For example the following XAML

    vsm:Ambient.ForeColor="Blue">
    

would generate the following output

(image)

Over the next couple of days the Ambient.ForeColor property will be added to BuildIt.Forms, which also includes the VisualStateManager I described in my past two posts (here and here).

(image)



Rebuilding the Xamarin.Forms Button with Visual States and Control Templates

Tue, 23 May 2017 19:54:32 +0600

In my previous post I provided a demonstrable way that visual states could be used in a Xamarin.Forms application to adjust layout. Whilst I showed how this can be used on a page to show/hide a piece of text, it can also be used to define the different states of a button. Before I get onto using visual states within a button, I’ll first show how a ContentView can be adapted to provide the basic button behaviour, whilst allowing both Content and ControlTemplate to be defined. Ok, perhaps that doesn’t make sense but let’s walk through an example:             In this code, I can add any XAML elements as Content within the ContentButton tags. The ContentButton raises a Pressed event, instead of a Click or Clicked event, to which an event handler can be attached. In the next code snippet, I’ve overridden the default ControlTemplate, wrapping the ContentPresenter in a Grid which has a yellow background.                                                                             Overriding the ControlTemplate demonstrates an easy way to override the style of the button in a way that can be replicated across all instances of the button in an application. Let’s take a look at the inner workings of the ContentButton, in particular the default ContentTemplate which is used to define different visual states of the button. In this case there are four visual states: Normal, PointerOver, Pressed and Disabled.             Styling Pages and Controls in Xamarin Forms using Visual States

Tue, 23 May 2017 19:07:47 +0600

I’ve been a bit proponent of both Xamarin and Xamarin.Forms for a long time but recently I’ve been taking another look at some of the fundamentals. Xamarin.Forms, for all its great intent is still a poor-man’s answer to declaring layout of an application in Xaml. Unlike Xaml platforms that have come before it (WPF, Silverlight, UWP), Forms doesn’t support some of even the basic features that you’d expect. On the chopping board today is the Button control – as one of the fundamental controls for any application, the Button should be able to be completely customised. Unfortunately it’s far from easy to alter the look of the basic button. If you look at how a simple button renders on different platforms, there is a clear difference between the style of the button. The following image shows how the button control renders across UWP, iOS and Android (UWP has an extra visual state as it supports mouse/pointer over on desktop). Button States Across Three Platforms The difference in style is by design – the rendering of the button on each platform uses the built in style for each platform. This works well if you’re interesting in building a generic looking application (eg perhaps a simple LOB data capture application). However, if you want to style the button in line with your branding and the design of your application, you’re going to want to make the buttons look and behave the same across all devices. You’d think this would be as simple as defining a common style, or perhaps overriding the default layout of the button. This is in fact doable – for example on UWP you can use an implicit style to override the look of every button across the application. Having to override the style of the button on each platform defeats the purpose of using Forms in the first place – once you’ve overridden the style, you then need to make platform specific changes every time you want to alter the style of the button control; imagine doing this for every control in your application – pretty soon, you might as well have developed the application using the traditional Xamarin model, rather than Forms. So, let’s look at the limitations of the Button control and see what we can do to address some of its shortcomings in a way that will help us build better applications quicker. There are two issues that I have with the Button control. The first is that it’s not easy to customise the content within the Button itself. For example if you wanted to have two lines of text, with the first being centred in bold, and the second justified italics with word wrapping enabled to allow it to flow to multiple lines. In UWP this would be easy with the Button control as the Content could be customised to have multiple TextBlock elements, with the style set accordingly. This would[...]



Xamarin Live Player from Build 2017

Sat, 13 May 2017 16:05:00 +0600

Microsoft’s Build conference is over for another year and I’m still working my way through the various sessions. I did however get a chance to take a look at the Xamarin Live Player (https://developer.xamarin.com/guides/cross-platform/live/player/) which is an interesting announcement and one that can help reduce the friction of getting pre-release applications onto devices. The Live Player is in preview, which means you’ll need the preview version of Visual Studio, the updated Xamarin bits and the alpha channel Xamarin bits on your Mac build machine (for those of you doing development on Windows). I highly recommend following all the setup instructions - https://developer.xamarin.com/guides/cross-platform/live/install/. Getting the Live Player setup and running was relatively straight forward, after I fixed up my Mac build machine because it was missing certificates/provision profile etc. I was able to install the Live Player on both my iPhone and a test Android device. After creating a simple Xamarin Forms project in Visual Studio, the Live Player is available from the device dropdown. After clicking run with the Live Player selected, the following dialog is displayed. Launch the Live Player app on your test device. You can either scan the QR code, or you can enter the code presented within the app into the dial. After scanning the QR code, a connection is established between the Live Player app running on your device and the instance of Visual Studio. A new entry should appear in the devices dropdown with your device name followed by the word Player. Now that you’ve associated your device, each time you want to run the application on your device, you can simply select the appropriate player from the devices dropdown and hit run. The app takes a second or two to deploy and will appear on your device – this provides a very quick way for you to deploy and test applications, particularly on an iOS device when doing development on a Windows machine. I can definitely see the advantage of using the Live Player but it had a few limitations (https://developer.xamarin.com/guides/cross-platform/live/limitations/) so I’m not sure how effective it will be until they resolve some of these. [...]



Thinking about Synchronisation in a Cloud-First World

Sun, 09 Apr 2017 17:04:00 +0600

As a mobile applications enthusiast from way back before Windows Mobile was a thing (yeh, I mean the first time), one of the challenges has always been data synchronisation. The challenge comes down to a trade off between stale data and user experience. Simple applications don’t worry about any form of data synchronisation; instead relying on pulling whatever data they need, when they need it. Unfortunately, these applications feel like the user is always waiting on data, or worse, seeing no data or error messages when there’s no connection. In order to fix, what is essentially a user experience issue, application developers often look at caching, or synchronising, data so that it can be made available offline. This both improves performance, since data is read from what’s cached on the device, it also means the data can be access when offline. The inevitable question is then how much data should be cached, and how should data be synchronised. There is no golden-bullet when it comes to identifying what data needs to be cached on the device. Some applications only cache data that the user has chosen to look at; allowing them to come back and review the data at a later point without having to request the data again. Other applications will proactively cache all data related to the current user – whilst this seems like a good idea initially, as the data related to a user increases, so does the time taken to complete an initial, or even future, synchronisations. In addition, the logic to retrieve all data related to a user can grow in complexity, often resulting in more data than necessary being retrieved, to ensure no data is omitted. Data synchronisation used to be an important topic with several attempts being made by Microsoft to assist developers. For example there was a Windows Mobile client for Merge Replication; there was the Microsoft Sync Framework and more recently the Mobile App Service has a limited form of data synchronization. Unfortunately none of these methods are well supported. Nor are they optimised to take advantage of some the benefits of the cloud. Let’s look at the most recent attempt by Microsoft to provide a synchronisation framework for mobile apps – Offline Data Sync for Azure Mobile Apps. The basic premise is that the application defines a table, or a query on a table, that will be pulled into a local Sqlite database. Local changes can be made to the data. Data can then be synchronised by pulling any server side changes and pushing local changes to the server. The architecture has the mobile application connecting to a service, which then either retrieves data from the database, or submits changes to the database. Thinking about how a cloud application should scale, there are a number of issues with this architecture: If you look at how to scale cloud applications, having any services which connect directly to the database, can be a source for bottlenecks. I’m definitely not advocating for no relational database, just a bit of separation between the service tier and the database, such that most service calls don’t block waiting for the database to be available. Connecting directly to services is a very slow way to retrieve data – it involves querying the database, processing the data into the format to be returned, and then returning it directly from the service instance. Compare this to retrieving the same data, pre-fetched and available via a CDN. The latter is going to be significantly faster, will cut down on bandwidth costs, will reduce load on both services and database since they no longer have to do work for every request for data. Changes submitted to the services have to be applied directly to the database – if the database[...]



Screenshots for a UWP Xbox App

Thu, 23 Feb 2017 08:55:57 +0600

We’ve been doing a bit of work building out an Xbox app and part of the fit-and-finish of any app is aligning the application layout with those of the designs. One of the easiest ways to do this is to take a screenshot of the app and then mark it up alongside the original designs, which are hopefully high enough fidelity to allow you to do the final round of tweaks against. On Xbox we noticed that within a UWP application the normal double-tap of the Xbox button doesn’t seem to take a screenshot. This is was confirmed by a post on the forum (https://social.msdn.microsoft.com/Forums/en-US/e100560d-a26b-48f8-a2bf-acce75ea4d26/uwpxbox-how-to-capture-screenshot-on-xbox-one-for-uwp-app?forum=wpdevelop) where the recommendation was to write code to take a screenshot. I even started down the path of using similar code to extract a screenshot, when I remembered there was a developer portal that’s exposed when you switch the device into dev mode (see https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/devkit-activation). I figured that once I took a screenshot using code, I’d need a way to get the image off the console, and that the developer portal was the way to do this. The first thing to do is to go to Dev Home – there should be a link on the right of the home screen when your console is in developer mode. If you don’t see it but you’ve setup dev mode, it may be that your device has reverted to retail mode, in which case you’ll need to run the dev mode activation app again. In Dev Home, there is an option to “Manage Xbox Device Portal” Where you have one option, “Enable the Device Portal” Once enabled you’ll need to configure authorisation by specifying username and password – write these down as you’ll need them shortly to access the dev portal. The next step is to go to a computer that’s on the same network as the Xbox (or at least a network that can reach the Xbox). Enter the IP address with the corresponding port number (see previous screenshot which is shown after enabling device portal, which shows the IP address and port number of your console). In most browser (this was Edge, but similar behaviour happens on most modern browsers) you’ll see a warning that the site you’re attempting to access can’t be verified. You need to expand, in this case, Details in order to see a link that will allow you to continue on to the device portal. Now that you’re in the device portal, select the Media capture node on the left. Click the “Capture Screenshot” at any point to screenshot whatever’s currently being displayed on the Xbox. You’ll also be prompted to open or save the captured image. [...]



Why String Interpolation is a BAD thing

Sun, 19 Feb 2017 06:04:22 +0600

So I’ll set the scene – I was reviewing some code and refactoring it. First thing to do was to go through and take a look at the Resharper comments as they do a good job at tightening up sloppy code. In this instance I came across code that looked a bit like this:

var url = “http://someservice.com/”;
url += queryParameters;
DoSomething(url);

Of course, this can easily be refactored using string interpolation to

var url = $“http://someservice.com/{queryParameters}”;
DoSomething(url);

Which looks so much cleaner. Unfortunately this has actually just made my code even worse – I still have this horrible nasty string literal, now with embedded code. Argh, who does this stuff. Next step, factor the string out into a constants, or ideally configuration file.

private const string ServiceUrlTemplate = “http://someservice.com/{0}”;

and then:

var url = string.Format(Constants.ServiceUrlTemplate,queryParameters);
DoSomething(url);

I’m sure there are a ton of other ways to make this nicer and perhaps more readable but having a string literal with interpolation is not one of them.

Additional Note: If you’re not using Resharper or another equivalent tool, you’re not working effectively. Start using a refactoring tool today and don’t ignore the warnings. Spend time everyday reviewing and improving the code you write

(image)



Call out to the ADAL team! – Authenticate Using External Browser

Sat, 18 Feb 2017 03:33:45 +0600

In my post, Authorizing Access to Resources using Azure Active Directory, I talk about authenticating using the built in browser on the device, rather than authenticating via a webview, which is all too common. Unfortunately despite being fully supported by Azure Active Directory, the team responsible for ADAL haven’t, as far as I can tell, provided support for using an external browser to authenticate.

I was super impressed when I just downloaded the Facebook app on Windows, that it supports “Log in with Browser”.

(image)

In my opinion, this not only represents a more secure form of authentication (since I can validate the website I’m signing into), it is also a better experience, since I’m already logged into Facebook in the browser anyhow.

I definitely encourage developers to consider using the external browser, rather than supporting SDKs and libraries that us the in-app browser.

(image)



Unable to Connect or Debug to Visual Studio Android Emulator with Visual Studio 2017 RC

Sun, 29 Jan 2017 11:12:42 +0600

Now I do appreciate that running prerelease software comes with some risk and I’m also aware that emulators are hard to get working 100% right on every machine. Ever since I can remember there have been connectivity issues with Windows Mobile, Windows Phone and now Windows 10 Mobile emulators; whether connectivity meaning to the internet, the local machine or being able to debug an application. So, it came as no surprise that after rebuilding my computer and installing Visual Studio 2017 RC that my installation of the Visual Studio Android Emulator was semi-broken. Turns out I had two issues I needed to overcome. When I attempted to launch the emulator, I got the following notice, saying that the Internet Connection needs to be configured – this is pretty typical for first run as Hyper-V needs to setup the virtual switches that the emulator image will use. After clicking Yes, the emulator is launched and my application is deployed. Unfortunately when Visual Studio attempts to launch the application and attach the debugger, the application closes immediately. This is again an issues I’ve seen before and in fact it appears on the troubleshooting web page for the Android Emulator (https://msdn.microsoft.com/en-us/library/mt228282.aspx): - After you’ve run the emulator image the first time, close the Android Emulator - Open Hyper-V Manager - Select the virtual machine that matches the emulator you were attempting to run (make sure it’s in the Off state), and click Settings - Under Processor –> Compatibility –> check the “Migrate to a physical computer with a different processor version” checkbox - Click OK - Important: Make sure you stop and restart the Hyper-V service, otherwise, for some reason the setting is lost the next time you run the emulator. Having done this I can now deploy and run applications on the emulator. The next issue was that for some reason the emulator couldn’t access the internet. I took a look in the Virtual Switch Manager in Hyper-V Manager (click Virtual Switch Manager from the Actions list on the right side of the Hyper-V Manager management console) and there was only a single “Windows Phone Emulator Internal” switch. I clicked on New virtual network switch, selected External Access and gave the switch a name: Each emulator virtual machine needs to have access to both the internal and external switches, so after clicking OK to exit the Virtual Switch Manager, I clicked on the virtual machine that I want to assign the new virtual switch to. Make sure you’ve stopped the virtual machine (closing the Android emulator will do this). Click Settings, click Add Hardware and select Network Adapter and click Add. From the Virtual switch dropdown, select the virtual switch you just created (External Access in my case), and click OK. Now launch the emulator (either via the Visual Studio Android Emulator interface that can be launched from the Start menu independently of Visual Studio, or by attempting to run an application from Visual Studio) and you should now have internet access – check via the web browser in the emulator if you’re in any doubt. [...]



UseWindowsAzureActiveDirectoryBearerAuthentication v’s UseJwtBearerAuthentication for Authorization with Azure Active Directory for an ASP.NET Web API

Sun, 29 Jan 2017 10:36:02 +0600

In my previous post, Securing a Web API using Azure Active Directory and OWIN, I covered how to authorize requests against Azure Active Directory using the UseWindowsAzureActiveDirectoryBearerAuthentication extension method in the OWN startup class. This extension method has been designed specifically for Azure Active Directory but if you think about it, the Authorization token is just a JWT token, so in theory you could take a much more generic approach to authorizing access by validating the JWT. This can be done using the UseJwtBearerAuthentication extension method. There are a couple of steps to using the UseJwtBearerAuthentication extension method. Firstly, in order to validate the signature of the JWT, we’re going to need the public certificate that matches the key identifier contained in the JWT. In my post on Verifying Azure Active Directory JWT Tokens I cover how to examine the JWT using https://jwt.io in order to retrieve the kid, retrieve the openid configuration, locate the jwks uri, retrieve the keys and save out the key as a certificate. In the post I used the certificate (ie wrapping the raw key in ---BEGIN---, ---END--- markers) to validate the JWT; in this case I’ve copied the contents into a text file which I’ve named azure.cer and added it to the root of my web project (making sure the build action is set to Content so it is deployed with the website). The next thing to do is to remove the UseWindowsAzureActiveDirectoryBearerAuthentication extension method, replacing it with the following code. var fileName = HostingEnvironment.MapPath("~/") + "azure.cer";var cert = new X509Certificate2(fileName);app.UseJwtBearerAuthentication(new JwtBearerAuthenticationOptions{    AllowedAudiences = new[] {ConfigurationManager.AppSettings["ida:Audience"]},    IssuerSecurityTokenProviders = new IIssuerSecurityTokenProvider[]    {        new X509CertificateSecurityTokenProvider(ConfigurationManager.AppSettings["ida:IssuerName"], cert)    }}); This code uses the azure.cer certificate file combined with the Audience and IssuerName which I’ve added to the web.config. The Audience is the application id (aka client id) of the Azure application registration. The IssuerName needs to match to what appears in the JWT. Opening one of the tokens in https://jwt.io it’s the ISS value that you want to use as the IssuerName. Now you can run the project and see that again the requests are validated to ensure they’re correctly signed. [...]



Securing a Web API using Azure Active Directory and OWIN

Sat, 28 Jan 2017 13:24:02 +0600

In this post we’re going to look at how to use Azure Active Directory to secure a web api built using ASP.NET (full framework – we’ll come back to .NET Core in a future post). To get started I’m going to create a very vanilla web project using Visual Studio 2017. At this point VS2017 is still in RC and so you’ll get slightly different behaviour than what you’ll get using the Visual Studio 2015 templates. In actual fact the VS2015 templates seem to provide more in the way of out of the box support for OWIN. I ran into issues recently when I hadn’t realised what VS2015 was adding for me behind the scenes, so in this post I’ll endeavour not to assume anything or skip any steps along the way. After creating the project, the first thing I always to is to run it and make sure the project has been correctly created from the template. In the case of a web application, I also take note of the startup url, in this case http://localhost:39063/. However, at this point I also realised that I should do the rest of this post following some semblance of best practice and do everything over SSL. Luckily, recent enhancements to IIS Express makes it simple to configure and support SSL with minimal fuss. In fact, all you need to do is select the web project node and press F4 (note, going to Properties in the shortcut menu brings up the main project properties pane, which is not what you’re after) to bring up the Properties window. At the bottom of the list of properties is the SSL Enabled and SSL URL, which is https://localhost:44331/. Take note of this url as we’ll need it in a minute. To setup the Web API in order to authorize requests, I’m going to create a new application registration in Azure Active Directory. This time I need to select Web app / API from the Application Type dropdown. I’ll give it a Name (that will be shown in the Azure portal and when signing into use this resource) and I’ll enter the SSL address as the Sign-on URL. This URL will also be listed as one of the redirect URIs used during the sign in process. During debugging you can opt to do this over HTTP but I would discourage this as it’s no longer required. After creating the application, take note of the Application Id of the newly created application. This is often referred to as the client id and will be used when authenticating a user for access to the web api. Application Id (aka Client Id): a07aa09e-21b9-4e86-b269-a18903b5fe54 We’re done for the moment with Azure Active Directory, let’s turn to the web application we recently created. The authorization process for in-bound requests involves extracting the Authorization header and processing the bearer token to determine if the calling party should have access to the services. In order to do this for tokens issues by Azure AD I’ll add references to both the Microsoft.Own.Security.ActiveDirectory and Microsoft.Own.Host.SystemWeb packages. Note: Adding these references takes a while! Make sure they’re completely finished before attempting to continue. Depending on the project template, you may, or may not, already have a Startup.cs file in your project. If you don’t, add a new item based on the OWIN Startup class template The code for this class should be kept relatively simple: [assembly: OwinStartup(typeof(SampleWebApp.Startup))]namespace SampleWebApp{    public partial class Startup    {        public void Configuration(IAppBuilder app)        {           [...]



Improving the Azure Active Directory Sign-on Experience

Sat, 28 Jan 2017 03:41:46 +0600

I was talking to a customer the other day and had to log into the Azure portal. Normally when I launch the portal I’m already signed in and I’m not prompted but for whatever reason this time I was prompted to authenticate. Doing this in front of the customer lead to three interesting discussions: - Use of two factor authentication to secure sign in- Separate global administrator account for primary organisation tenant- Company branding for Azure AD sign in Firstly, the use of two factor authentication (TFA) is a must requirement for anyone who is using the Azure portal – if you are an administrator of your organisation, please make sure you enforce this requirement for anyone accessing your tenant/directory/subscription. This applies to staff, contractors, guests etc who might be using your Azure portal or the Office 365 portal. In fact, in this day in age, I would be enforcing two factor authentication for all employees – note that Outlook and Skype for Business are still stuck in the dark-ages and don’t access TFA sign in. For these you’ll need to generate an application password (go to https://myapps.microsoft.com, click on your profile image in top right corner and select “Profile”, click through to “Additional security verification,” click on the “app passwords” tab and then click “Create” to generate an app password. Ok, next is the use of a separate global administrator account – this is in part tied to the previous point about using TFA. If you’re a global administrator of your tenant and you enable TFA, you won’t be able to generate app passwords. This is essentially forcing you down the path of best practice, which is to have a separate account which is the global administrator for your tenant. If other people in your organisation need administrative permissions, you can do this on a user or role basis within the Azure portal – our preference is to assign permissions to a resource group but there is enough fidelity within the portal to control access at the level you desire. The other thing we’ve also enforced is that we do not host any Azure resources in our primary tenant (ie in our case builttoroam.com). Given the importance of Office365 based services we felt it important that we isolate off any resources we create in Azure to make sure they’re completely independent of our primary tenant. The only exception to this is if we are building internal LOB applications (ie only apps for Built to Roam use) – for these we include the app registrations within the builttoroam.com tenant so that we can restrict sign in and at the same time deliver a great sign in experience for our employees. For example we’re using Facebook Workplace (https://workplace.fb.com/) – we configured this within the builttoroam.com tenant in Azure AD to allow for a SSO experience. Now, onto the point of this post – the last thing that came out of signing into the portal in front of the customer was that they were startled when we went to sign into the portal and our company branding appeared. To illustrate, when you first land on the portal sign in page you see: After entering my email address, the sign in page changes to incorporate the Built to Roam branding This not only improves the perception (for internal and external users), it also gives everyone a sense of confidence that they’re signing into a legitimate Built to Roam service. In order to set this up, you need to navigate to the Active Directory node in the Azure portal and click on the Company branding. If you’re using Office 365 you should a[...]



The Danger of Admin Consent for Applications

Thu, 26 Jan 2017 06:11:38 +0600

In the last couple of posts I covered the use of admin consent to grant permissions for an application to access more than simply data related to the signed in user: Admin Consent for Permissions in Azure Active Directory Making your Azure Active Directory application Multi-tenanted In my initial post talking about admin consent I added the “Read directory data” to the set of permissions that the application would request. This permission, along with a number of other permissions for the Windows Azure Active Directory resource, have a green tick in the “Requires Admin” column. It’s all to easy for developers, when setting up the permissions for an application to not think through what enabling permissions for an application does. When you enable permissions for an application, by ticking the box alongside the permission in the Azure AD application configuration (see previous) image, you are essentially saying that the application will be able to perform those actions after the user has signed in and provided consent – this is true regardless of what role the user belongs to within the organisation (the application can perform the same actions whether a receptionist or the CEO of an organisation is signed in). The division between permissions that require admin consent, versus those that do not, usually are based on whether the permission is for an action that only administrators should be able to do, versus those that any user should be able to do. For example in the case of Windows Azure Active Directory all users should be able to sign in and read their profile, read the basic profile of all users in the directory and access the directory as the signed-in user – all of these do not require admin consent as they are either actions that pertain to the signed in user, or they are actions that all users should be able to perform. The last permission does permits more access control as elements within the directory can be secured so users/roles/groups can access them; if the user is accessing the directory as themselves, they’ll only be able to access objects that they have permissions on. When I checked the box alongside the “Read directory data” permission, I was essentially saying that all users (assuming a global administrator had performed the admin consent) would be able to read all data in their organisation’s directory (see https://msdn.microsoft.com/en-us/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes): In order words, once someone has signed into the application, the access token granted to the application can be used to retrieve all directory data – ummm that’s starting to sound pretty scary. No imagine if I granted “Read and write directory data” permissions to the application. Now the access token can read and write directory data. Put this into the context of hackers who use social engineering to access low level employees, you can imagine it wouldn’t be hard for them to access this application in order to access employee information. The moral of this post is DO NOT enable REQUIRES ADMIN permissions to any native application (unless you’re 100% sure you know what the implications are) – it’s way to easy to intercept access tokens and act on behalf of the user. [...]



Making your Azure Active Directory application Multi-tenanted

Thu, 26 Jan 2017 05:13:44 +0600

So far in my previous posts I’ve discussed signing into an application using Azure Active Directory (Azure AD) using a basic application registration in Azure AD. Last post we added some additional permissions that required administrator consent. However, up until now, only users in the same directory (aka tenant) that the application is registered in, can sign in. In the case of the sample application I’ve been working with, the application is registered to the nicksdemodir.onmicrosoft.com tenant, so only users belonging to that tenant can sign in eg admin@nicksdemodir.onmicrosoft.com. If I attempt to sign in with an account from a different tenant, I run into a few issues, and depending on what type of account I sign in with, the error that is displayed varies. I’ll start by signing in with a regular user account that belongs to a different tenant (in this case btro365dev.onmicrosoft.com). When I attempt to sign in with this account, everything seems to go well – I’m prompted to sign in; I successfully sign in; I’m returned to the application where the code is exchanged for an access token. However, when I attempt to use this access token I get a rather cryptic error about an “Unsupported token” eg: {"odata.error":{"code":"Request_BadRequest","message":{"lang":"en","value":"Unsupported token. Unable to initialize the authorization context."},"requestId":"86481ea2-79bd-461b-93ad-4f649286617a","date":"2017-01-25T21:28:14"}} This is actually less cryptic than it seems – essentially it’s saying that I’m attempting to present a token that the API can’t process. If you were to open the access token in https://jwt.io, you’d see that the token has been issued by the nicksdemodir.onmicrosoft.com tenant (actually you’d see the STS url that correlates to this tenant) for an account that doesn’t exist in that tenant (eg testuser@btro365dev.onmicrosoft.com). Whilst this is a legitimate access token, when you present it to the Graph API, it attempts to retrieve information about the user in the issuing tenant, which of course fails, since the user doesn’t exist there. Ok, let’s see what happens if I attempt to launch the admin consent prompt. In this case, after I sign in (now using admin@btro365dev.onmicrosoft.com which is a global administrator) I get a more useful error message saying “AADSTS50020: User account … does not exist in tenant”. The reason this error message is useful is that it prompts me to think about what I’m attempting to do – I’ve been prompting the user to sign into the nicksdemodir.onmicrosoft.com tenant, which is fine if I’m a user that belongs to that tenant but since I’m attempting to use a different user, this is clearly not correct. So, the first step in making my application multi-tenanted is to change the authorization url that I’m directing the user to in order to sign in, to one that is more generic and will allow signing in by users from any tenant. This involves exchanging the “nicksdemodir.onmicrosoft.com” with “common” in the url – the following code shows how I adapted the code in my sample application to support urls that are single tenanted (ie AuthorizationUrl and AdminConsentUrl) as well as the multi-tenanted equivalent (ie MultiTenantAuthorizationUrl and MultiTenantAdminConsentUrl). private string BaseAuthorizationUrl =>    "https://login.microsoftonline.com/{0}/oauth2/authorize?" +    "client_id=40dba662-4c53-4154-a5cf-976473306060&" +    [...]



Admin Consent for Permissions in Azure Active Directory

Tue, 24 Jan 2017 19:08:14 +0600

In the previous posts I’ve discussed authenticating and authorizing a user with Azure Active Directory (Azure AD) using a basic application registration. All application registrations are given default permissions to access the Azure Graph API – this was used in my previous post to retrieve information about the signed in user. The default permission set is a delegated permission that allows the user to sign in and view their own profile. This can be viewed in the Azure portal by extending the Required permissions tab for the application. In this post I’m going to extend this permission set to include the “Read directory data” permission. You’ll notice in the previous image that there is a green tick in the “Requires Admin” column. What this means is that in order for a regular user (ie a user that is not a global administrator for the tenant) to sign in, a global administrator must first sign in and consent to permission on behalf of the organisation. If a regular user attempts to sign in, they’ll be confronted with an error message such as:   Essentially the error “AADSTS90093: Calling principal cannot consent due to lack of permissions” indicates that a global administrator needs to sign in an consent on behalf of the organisation before users can sign in. If a global administrator signs in, they’ll see a prompt where they can consent permissions – this is slightly confusing as it would imply that the administrator is consenting on behalf of the organisation. Unfortunately this is not the case, they’re only consenting for use by their account. In order for a global administrator to consent on behalf of an organisation, so that all users can make use of the “admin consent” permissions, they have to be directed to a new sign in page with the parameter “prompt=admin_consent” set in the query. In other words, the admin consent url is exactly the same as the authorization url, except it has “&prompt=admin_consent” appended to the end. https://login.microsoftonline.com/nicksdemodir.onmicrosoft.com/oauth2/authorize?client_id=40dba662-4c53-4154-a5cf-976473306060&response_type=code&redirect_uri=sample://callback&nonce=1234&resource=https://graph.windows.net&prompt=admin_consent The admin consent prompt looks slightly different to a regular consent prompt as it highlights that consent is going to be assigned for the entire organisation As this is a one-off operation, a global administrator can either navigate to the url in the browser, or the application can have a separate button that would launch the url so that the admin can consent. After the global administrator has consented, user’s will still be prompted to consent but this is for the delegated permission. In the same way that user permissions can be revoked by going to https://myapps.microsoft.com and deleting the application entry, organisation permissions can be revoked by opening the Enterprise applications tab for the Active Directory in the Azure portal. Select the application you want to remove and click the Delete button. After the global administrator has consented for the organisation, any user can then read the directory data (ie more than just their own profile). [...]



Verifying Azure Active Directory JWT Tokens

Tue, 24 Jan 2017 18:02:14 +0600

When working with OAuth and Open ID Connect, there are times when you’ll want to inspect the contents of id, access or refresh tokens. The website https://jwt.io is useful as you can drop in the token in the pane on the left, and the site dynamically decodes the header, body and signature for the JWT. Unfortunately by itself the signature on the JWT can’t be verified as the website doesn’t know what key to use to validate the signature. The header of the JWT does provide information about the algorithm used (ie RS256) and the id of the key used but this by itself isn’t enough to locate the key to be used. As RS256 is a public/private key algorithm, there is a private key, which the issuer holds, and a public key which is available to anyone to access. The former is used to generate the signature for a JWT; the later can then be used to validate the signature. To find the public key to use to validate the signature I’ll start with the OpenID Connect configuration document, which is available for any tenant at: https://login.microsoftonline.com/{tenantId}/.well-known/openid-configuration eg https://login.microsoftonline.com/nicksdemodir.onmicrosoft.com/.well-known/openid-configuration The returned configuration document contains an attribute, jwks_uri, which points at https://login.microsoftonline.com/common/discovery/keys Loading the jwks_uri returns another JSON document which lists a number of keys. Now we can use the kid from the header of the JWT to identify which key to use, in this case the first key in the list. Attempting to simply copy the x5c value from the list of keys into the Public Key or Certificate box on the jwt.io website will still not verify the signature of the JWT. In order to verify the signature, wrap the key in BEGIN and END CERTIFICATE markers as follows: -----BEGIN CERTIFICATE-----MIIDBTCCAe2gAwIBAgIQEsuEXXy6BbJCK3bMU6GZ/TANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJhY2NvdW50cy5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0MB4XDTE2MTEyNjAwMDAwMFoXDTE4MTEyNzAwMDAwMFowLTErMCkGA1UEAxMiYWNjb3VudHMuYWNjZXNzY29udHJvbC53aW5kb3dzLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKd6Sq5aJ/zYB8AbWpQWNn+zcnadhcMYezFvPm85NH4VQohTm+FMo3IIJl6JASPSK13m9er3jgPXZuDkdrEDHsF+QMEvqmffS2wHh3tKzasw4U0jRTYB0HSCbmnw9HpUnv/UJ0X/athO2GRmL+KA2eSGmb4+5oOQCQ+qbaRXic/RkAOLIw1z63kRneLwduQMsFNJ8FZbWkQFj3TtF5SL13P2s/0PnrqwGD59zcbDu9oHOtciu0h++YhF5CWdWEIgafcZk9m+8eY12BKamvPdBnyfpz6GVTenJQe2M+AGz5RSNshvI976VUbBiaIeNzvzaG91m62kFWLRqE3igq6D02ECAwEAAaMhMB8wHQYDVR0OBBYEFAgoZ9HLgFxH2VFGP6PGc4nFizD2MA0GCSqGSIb3DQEBCwUAA4IBAQBSFXalwSJP/jihg04oJUMV2MTbuWtuFhdrdXiIye+UNc/RX02Q9rxd46BfGeKEBflUgNfEHgyEiWTSLAOSDK70vu+ceCVQCGIQPjnGyYOpm80qAj/DNWZujVcSTTV3KZjMFsBVP7miQowfJQ58u9h8yuJHNhPpB2vOFmNhm4uZq3ve529Xt51HdtQGG9+Z9n1DhObqzkbz8xEFjA+KdfcRsZXa14ZkpAOe35VgyY0f8x34Y0LPfibWcNpfp0AhxKzyqT1GRRlKTjiBA6WNJIJIEeqh/nfOnwM0UQKRnt+2qeV3u00a5lrvJtEy7nq+s7xYtpVAsCvn5T0U1/8IHkxt-----END CERTIFICATE----- Entering the wrapped key into the Public Key or Certificate box on the jwt.io website will successfully verify the signature of the JWT. [...]



Authorizing Access to Resources using Azure Active Directory

Tue, 24 Jan 2017 09:10:39 +0600

In my previous post I discussed authenticating a user using Azure Active Directory (Azure AD), returning an id_token that can be used to identify the user that has signed in. However, this token isn’t an access token and as such can’t be presented in order to access remote services. In this post I’m going to show how you can request an access token that can be presented in the Authorization header when calling a service. The workflow is very similar to the workflow to retrieve the id_token: - User attempts to sign into an application - Application launches the Authorize URL in an external browser (includes “resource” parameter in Authorize URL) - User is directed to a Microsoft URL where they are prompted to sign in - User signs in - User is prompted to consent that the application can access the specified resource - After sign in, the User is redirected back to the application via a custom protocol - Application receives an authorization code - Application performs a POST request to the Token URL in order to exchange authorization code for an access token - Application receives the access token - Application makes call to remote service, attaching the access token in the Authorization header To demonstrate this workflow I’m going to adapt the sample application I created in my previous post in order to access the Azure Graph API. The sample application is already configured with access to the Azure Graph API – this is done by default for all application registrations. In order to request access to a resource, you need to know the url of the resource you want to access. In this case the url for the Azure Graph API is https://graph.windows.net. In addition to including the resource url in the authorization url, the other change I need to make is to switch the response type from id_token to code. The updated authorization url is: var  authorizationUrl=    "https://login.microsoftonline.com/nicksdemodir.onmicrosoft.com/oauth2/authorize?" +    "client_id=40dba662-4c53-4154-a5cf-976473306060&" +    "response_type=code&" +    "redirect_uri=sample://callback&" +    "nonce=1234&" +    "resource=https://graph.windows.net"; Launching this url in the external browser will again prompt the user to sign in (unless they have previously signed in for this application, such as if you followed my previous post) but rather than immediately being redirected back to the application, the user will see a consent prompt – you’ll note that similar to the sign in prompt, the name of the application specified in Azure AD is used when requesting permissions. The other thing to note is that once you’ve consented permissions for the application, you won’t be prompted again – Azure AD remembers that you’ve granted permissions. Permissions can be revoked by going to https://myapps.microsoft.com, selecting the application and clicking Remove. The same “Remove” option is available if you turn on the new look (it’s the same url to get there – https://myapps.microsoft.com) After completing the sign in and consent workflow, the user is navigated back to the application using the custom protocol. This time, instead of an id_token, the application receives a code as part of the url: sample://callback/?code=AQABAAAAAADRN…….L7YiQ7PIAA&session_state=ffffd83b-3820-489e-9f35-70e97d58fd0[...]



Authenticating an Application using Azure Active Directory

Mon, 23 Jan 2017 18:38:07 +0600

In my previous post I discussed in brief the use of the OAuth Authorization Code workflow and the corresponding endpoints. As a brief recap, the workflow I’ll going to walk through is the following: - User attempts to sign into an application - Application launches the Authorize URL in an external browser - User is directed to a Microsoft URL where they are prompted to sign in - User signs in - After sign in, the User is redirected back to the application via a custom protocol - Application receives the token containing information about the user that has signed in In this walk through I’ll use a UWP application but the workflow works well for any platform that supports custom protocol. Before I get started I’m going to need a few things: Authorize URL - https://login.microsoftonline.com/{tenantId}/oauth2/authorizeTenant Id - nicksdemodir.onmicrosoft.com (this can also be specified as a guid) Next, I’m going to register an application with Azure Active Directory (Azure AD). You can think of this registration as identifying the application that is going to connect to Azure AD. In the Azure portal, open the Active Directory management pane and select App registrations At the top of the app registrations pane, click the Add button. In the Create form I’ll give the application registration a name (the name is used both in the Azure portal as well as on the sign in page when a user is signing into the application). The application type needs to be set to Native – this allows the application to exchange an Authorization Code for an Access Token without having to provide a client secret. The final property is the Redirect URI, which is the URL that the browser will be directed to after the user has signed in. In this case I’m specifying a custom protocol which will be used to redirect back to the application. Once the application registration is complete I can copy the Application Id from the application pane. I have all the information I need in order to authenticate a user; all I need to do is form the authorization url that will be launched in the external browser: private async void AuthenticateClick(object sender, RoutedEventArgs e){    var  authorizationUrl=        "https://login.microsoftonline.com/nicksdemodir.onmicrosoft.com/oauth2/authorize?" +        "client_id=40dba662-4c53-4154-a5cf-976473306060&" +        "response_type=id_token&" +        "redirect_uri=sample%3A%2F%2Fcallback&" +        "nonce=1234";    await Launcher.LaunchUriAsync(new Uri(authorizationUrl));} There are various components to the authorization url: nicksdemodir.onmicrosoft.com – The tenant where the application is registered. Alternatively use “common” for multi-tenanted applications. 0dba662-4c53-4154-a5cf-976473306060 – This is the Application ID (also referred to as the client ID) of the application registration in Azure AD id_token – This is the requested response, which in this case is a JWT token that represents information about the user. When using OAuth to authorize access to a resource, either specify “code” or “code id_token”. sample://callback – This is the url that the browser will be redirected to after the sign in process has been[...]



Azure Active Directory and Google OAuth 2.0 Endpoints

Sun, 22 Jan 2017 17:46:31 +0600

There are a lot of arguments for and against using pre-built SDKs for doing OAuth authentication with Azure AD and Google. Having worked with the ADAL library for Azure quite a bit I think the team have done a reasonable job, especially considering it now works across the three mobile platforms (iOS, Android and Windows), and works with a PCL that is .NET Standard based. However, using any library does force you into working within the bounds of the library. For example, we recently found two shortcomings in the library: - It doesn’t provide a good solution for doing a browser based workflow for signing in – instead it uses a webview hosted within the context of the application (depending on the platform this may be augmented with more security, for example the Web Authentication Broker - https://msdn.microsoft.com/en-us/library/windows/apps/windows.security.authentication.web.webauthenticationbroker.aspx). A browser based workflow involves launching the external browser for the user to sign in; upon successful sign on, the user is redirected back to the app. - It doesn’t provide a mechanism to clear cached credentials. Whilst the tokens can be cleared, this doesn’t clear the cookies held within the hosted webview, which can lead to issues if the application is multi-tenanted. If the provided libraries don’t align with what you want, you may have to roll your own solution. The Authorization Code workflow requires two endpoints: - Authorize URL – this is the URL that you navigate the user to in order for them to sign into your application. After signing in an Authorization Code is returned to the application - Token URL – this is the URL that the application does a POST request to in order to convert the Authorization Code into an access token. For Azure Active Directory, these endpoints are: Authorize - https://login.microsoftonline.com/{tenantId}/oauth2/authorize Token - https://login.microsoftonline.com/{tenantId}/oauth2/token For Google, these endpoints are: Authorize - https://accounts.google.com/o/oauth2/v2/auth Token - https://www.googleapis.com/oauth2/v4/token As both services conform to OAuth/OpenID Connect, the parameters are the same, although there are some variations on the values that you need to supply for scope and client id. [...]



Useful OAuth, OpenID Connect, Azure Active Directory and Google Authentication Links

Sun, 22 Jan 2017 12:31:46 +0600

Over the past couple of weeks I’ve been assisting with the development work of an enterprise system that uses both Azure Active Directory (Azure AD) and Google to authenticate users. It’s a cross platform solution which means we need code that works across both authentication platforms, and the three mobile platforms. Unfortunately this is easier said than done – The Azure AD team have done a reasonable job with the ADAL library but it’s not like we can repurpose that library for authenticating against Google. This is a tad annoying since both Azure AD and Google both use OAuth and OpenID Connect, so you’d expect there to be a good library that would work across both. In trying to find a workable solution I can across a number of links that I want to bookmark here for future reference: OAuth 2 Home - https://oauth.net/2/ The OAuth home page is a good starting point if you want to get more links and information about OAuth (1 and 2) but I actually found it’s main use for me was to point at the OAuth 2.0 Framework RFC OAuth 2.0 Framework RFC - https://tools.ietf.org/html/rfc6749 You can think of the OAuth 2.0 Framework RFC as being the specification for OAuth 2.0. There are some extensions and other standards that relate to OAuth 2.0 but this is a must read if you want to understand what OAuth 2.0 is all about. You may need to refer back to this when reading other blogs/tutorials as it can help clarify what each of the roles and responsibilities are in the process. Simple overview of OAuth 2 - https://aaronparecki.com/2012/07/29/2/oauth2-simplified This overview provides a quick summary of the various flows for OAuth 2.0. However, I disagree with the use of the implicit workflow for mobile applications. Whilst mobile applications are not “trusted,” which would normally imply the use of the implicit workflow, the reality is that the implicit workflow can’t issue refresh tokens. This means that unless you want your users to have to log in each time they use your mobile application, you need to use the Authorization Code workflow (the client secret shouldn’t be required when requesting access tokens for mobile apps – this depends on which authentication provider you’re using).   OpenID Connect Home - http://openid.net/connect/ The OpenID Connect home page is again a good starting point as it links to the many different parts of the OpenID Connect standard. OpenID Connect builds on top of OAuth 2.0 in order to provide a mechanism for users to be authenticated as well as authorized for resource access. In addition to the creation of access tokens, OpenID Connect defines an id_token which can be issued in absence of any resource that is just used to identify the user that has authenticated. OpenID Connect Core 1.0 - http://openid.net/specs/openid-connect-core-1_0.html This is the core specification of OpenID Connect. Similar to the specification for OAuth, this is worth both a read and to be used as a reference when working with OpenID Connect implementations. OpenID Connect Session Management 1.0 - http://openid.net/specs/openid-connect-session-1_0.html Whilst still in draft this standard covers how implementers are supposed to handle log out scenarios, which is useful as your application can’t simply delete it’s access tokens when a user opts to log out. Ideally when a user logs out, you’d[...]



NuGet does my head in….. No thanks to Xamarin.Forms

Tue, 06 Dec 2016 12:52:59 +0600

This is a bit of a rant with hopefully a fix that will help others. Firstly, the rant: In my post on Building Cross Platform Apps I used the new project templates in Visual Studio 2017 to create a new Xamarin.Forms application that targets iOS, Android and UWP. What I didn’t mention is the time I wasted trying to upgrade NuGet packages in order to get the thing to build and run. Namely I get the following exception when attempting to build the newly created application. Severity    Code    Description    Project    File    Line    Suppression StateError        Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'Xamarin.Android.Support.v7.RecyclerView, Version=1.0.0.0, Culture=neutral, PublicKeyToken='. Perhaps it doesn't exist in the Mono for Android profile?File name: 'Xamarin.Android.Support.v7.RecyclerView.dll'   at Java.Interop.Tools.Cecil.DirectoryAssemblyResolver.Resolve(AssemblyNameReference reference, ReaderParameters parameters)   at Xamarin.Android.Tasks.ResolveAssemblies.AddAssemblyReferences(DirectoryAssemblyResolver resolver, ICollection`1 assemblies, AssemblyDefinition assembly, Boolean topLevel)   at Xamarin.Android.Tasks.ResolveAssemblies.Execute(DirectoryAssemblyResolver resolver)    App5.Droid            I figured that there was something wrong with the Xamarin.Forms and/or Xamarin Android NuGet packages, so I thought I’d just go an upgrade the Xamarin.Forms NuGet package. Note: Don’t every try to upgrade the Xamarin Android packages independently – let the Xamarin.Forms NuGet package determine which versions of those libraries you need. Anyhow, unfortunately that just generates another exception: Severity    Code    Description    Project    File    Line    Suppression StateError        Unable to resolve dependencies. 'Xamarin.Android.Support.Compat 24.2.1' is not compatible with 'Xamarin.Android.Support.Design 24.2.1 constraint: Xamarin.Android.Support.Compat (= 24.2.1)'.            0    At this point I was starting to get annoyed – it looks like there was already an inconsistency between the Xamarin.Forms package and the Xamarin Android packages included in the template. Luckily it was easier to fix than I thought it was. I opened up the packages.config file for the Android head project and delete the Xamarin.Android libraries.          



When I grow up I want to be a .NETStandard Library!

Tue, 06 Dec 2016 11:48:06 +0600

A month or so ago we made the decision to upgrade some of the portable libraries we use for projects from being based on PCL Profiles (eg profile 111 or profile 259) across to .NET Standard. To do this, we followed the upgrade prompt in the project properties page in Visual Studio. After clicking the “Target .NET Platform Standard” you can then pick which .NET Standard you want. Where possible we try for .NETStandard 1.0, which aligns with PCL Profile 259, or .NETStandard 1.1, which aligns with PCL Profile 111 (see https://docs.nuget.org/ndocs/schema/target-frameworks). The theory being that a .NETStandard 1.0 library can be consumed by any .NETStandard library 1.0 and above, as well as any PCL profile library that is profile 259 – in other words, we’re aiming for maximum reach. Take for example, BuildIt.General, which is a general purpose utility library. This is now a .NETStandard 1.0 library….. or so we thought. I was doing some testing on the current stable version of the library to make sure it could be added into a Xamarin Forms application. In my previous post I showed how easily you can create a new Xamarin Forms project that has a PCL that contains all the UI for the application, and then head projects for each target platform (iOS, Android, UWP). Before adding in BuildIt.General I upgraded all the existing NuGet references – always good practice when creating new project (disclaimer: this sounds easier than it is due to an issue with the current Xamarin.Forms template which makes it hard to upgrade – more on this in a future post). Next I added a reference to the BuildIt.General NuGet package – I made sure it was added to all projects as it includes a UWP library that has some useful extensions such as converters that are specific to UWP. At this point everything was able to build and I was able to run the UWP application (I didn’t get round to running the other platforms but I assumed that they would also work since I hadn’t really modified anything from what comes out of the box). I then wanted to test that I could invoke functions from the BuildIt.General library, so I added the following into the MainPage.xaml.cs file within the Xamarin.Forms PCL library: LogHelper.Log("test"); Now, when I attempted to build the library I got the following error: The primary reference "BuildIt.General, Version=1.0.0.20, Culture=neutral, processorArchitecture=MSIL" could not be resolved because it was built against the ".NETPortable,Version=v5.0" framework. This is a higher version than the currently targeted framework ".NETPortable,Version=v4.5,Profile=Profile259". This completely confused me….. what’s this reference to .NETPortable and what’s the difference between v5.0 and v4.5. Immediately I thought that it was an issue with Visual Studio 2017 but after a bit of investigating it turns out that it’s a more fundamental issue with the way that we, actually MSBuild/Visual Studio, is creating the BuildIt.General library. I came across this thread which includes this comment: (Oren has one of the best explanations on the whole .NET Standard v’s PCL Profile discussion at https://oren.codes/2016/06/23/portable-is-dead-long-live-netstandard/) Anyhow, I wondered whether our library was suffering from the same ill fate. Using ILSpy I took a look a[...]



Building Cross Platform Applications with Visual Studio 2017

Mon, 05 Dec 2016 10:56:01 +0600

Ok, before I jump into this, I want to point out a couple of things: - Visual Studio 2017 is still in RC - When you install the RC of Visual Studio 2017 and enable the options to install Xamarin, you will break any existing Xamarin support for earlier versions of Visual Studio (see https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes#KIXamarin). I noticed the other day when I was creating a throwaway project is that there’s a new dialog when creating cross platform applications within Visual Studio 2017. In the New Project dialog, select the Cross Platform node and there is a single Cross Platform App option. Selecting this option presents you with some project templates – there are only a couple at the moment but I’m hoping that they provide more examples. Unfortunately, and it’s a little hard to see in this screenshot, for the Master Detail template, you can only select Shared Projects. Without exploring the template, I can only assume it was setup this way to share UI code that has platform specific code that compiles based on conditional flags. I really like the way that you can switch between a Forms application and a Native (and no they don’t literally mean “native” (eg Objective-C/Swift or Java/C++), they mean traditional Xamarin where you have platform specific UI. I opted for the “Blank App (XAML)” which requires Forms, I selected PCL, but unfortunately the “Host in the cloud” option was then disabled. After hitting Accept, the new solution was created and I was immediately able to build and run the application across iOS, Android and Windows (UWP). Very nice. [...]