Published
Sep 06 2018 09:03 PM
11.8K
Views
First published on CloudBlogs on May, 18 2016
Hi folks, today I am happy to announce that the version 3 of our authentication library ADAL .NET v3 is generally available. ADAL .NET v3 introduces important new features, such as cross platform development via Xamarin, which will help you to easily harness the power of Azure AD and the Microsoft cloud API - no matter what OS you are targeting. To walk us through the salient features of this release I invited back Vittorio, a Program Manager from the developer experience team. As always, we welcome your feedback. John Justice Director of Program Management Microsoft Identity Developer Platform ------ Hello everybody, ADAL .NET v3 is finally ready to power your apps in production! Thanks to the new Xamarin integration features you can now write your application once, and run it on iOS, Android and Windows – ADAL v3 helps you to address your authentication needs in a single place and reuse it across all platforms. In this post I will list the most salient news and features.
The idea is that when you add a NuGet reference to ADAL, the NuGet system will pull in specific assemblies depending on your project type. For example, if you are building a portable class, you’ll get netcode45 or dnxcore50. If you are building a Xamarin iOS project, however, you’ll end up with both the netcore45 assembly and the platform-specific Xamarin.iOS10 assembly.
The primitives you use for working ADAL are largely unchanged – they are the familiar
AuthenticationContext
,
AcquireToken
*,
AuthenticationResult
and the like. However the surface has been adjusted to accommodate the fact that your code might now be running on widely different platforms – with different ways of prompting the user, different storage technology for token caches, and so on. Here there’s how we achieve adaptive behavior across platforms.
AcquireToken* now accepts a new parameter, an interface named
IPlatformParameters
. That interface has a concrete implementation,
PlatformParameter
, for all the supported platforms. The main purpose of
PlatformParameters
is to carry a reference of the parent UX element from which you want to trigger the authentication experience: that helps ADAL to determine at runtime whether it should prompt the user using iOS, Android, Windows Store or Windows desktop experiences. The subdivision in interface and concrete classes allows you to maximize code reuse: you can put most of your authentication logic in a portable class, where you use the
IPlatformParameter
– and all you need to do for leveraging that from platform specific projects is to pass in the corresponding
PlatformParameters
platform specific implementation. Let me give you a practical example.
The main ADAL sample demonstrating how to work with Xamarin can be found
here
. It is a simple application, which allows you to query the directory to find basic information about a user.
The solution structure follows the pattern introduced earlier: there is a portable class project containing the bulk of the authentication logic, and platform specific projects (in this case for desktop, UWP, iOS, Android) implementing the experience (note, Xamarin Forms is also supported. See
here
for hints on how to use it).
If you expand the references folder for the portable class library and any of the platform specific projects, you’ll observe the assemblies distribution typical of the pattern.
The portable library refers to the portable ADAL assembly; the platform specific project refers to the portable library, and the ADAL PCL & the platform specific assembly.
The portable class library project contains some basic token acquisition logic. The interesting parts are highlighted below.
public static async Task<List<User>> SearchByAlias(string alias, IPlatformParameters parent)
{
// ...
authResult = await authContext.AcquireTokenAsync(graphResourceUri,
clientId, returnUri, parent);
// ...
The call to AcquireTokenAsync looks like the good ol’ AcquireTokenAsync in ADAL 2.x, except for the new parameter passing in the IPlatformParameters.
Let’s once again pick the Android project as the representative of what happens in platform specific project. The directory searching functionality is implemented in MainActivity.cs. Here there’s the code used to trigger the search.
List<User> results = await DirectorySearcher.SearchByAlias(searchTermText.Text, new PlatformParameters(this));
The
PlatformParameters
instance passed here is the Android specific implementation of
IPlatformParameters
, taking in input the current activity. This allows ADAL to dynamically determine what logic to invoke for displaying prompts and access storage in platform specific fashion. iOS has similar code in its viewcontroller, Windows in its XAML page, and so on.
Hi folks, today I am happy to announce that the version 3 of our authentication library ADAL .NET v3 is generally available. ADAL .NET v3 introduces important new features, such as cross platform development via Xamarin, which will help you to easily harness the power of Azure AD and the Microsoft cloud API - no matter what OS you are targeting. To walk us through the salient features of this release I invited back Vittorio, a Program Manager from the developer experience team. As always, we welcome your feedback. John Justice Director of Program Management Microsoft Identity Developer Platform ------ Hello everybody, ADAL .NET v3 is finally ready to power your apps in production! Thanks to the new Xamarin integration features you can now write your application once, and run it on iOS, Android and Windows – ADAL v3 helps you to address your authentication needs in a single place and reuse it across all platforms. In this post I will list the most salient news and features.
What’s new in ADAL .NET v3
ADAL .NET v3 has been refactored to extend the range of platforms it can reach. Namely, with v3 you can target:- .NET 4.5+ applications: WPF apps, console apps, code behind of ASP.NET 4.6 web apps and API, etc etc
- UWP apps (Windows 10 and Windows 10 Mobile)
- Windows Store apps
- Xamarin iOS and Android apps
- Xamarin Forms apps
- [still preview] .NET Core apps
The idea is that when you add a NuGet reference to ADAL, the NuGet system will pull in specific assemblies depending on your project type. For example, if you are building a portable class, you’ll get netcode45 or dnxcore50. If you are building a Xamarin iOS project, however, you’ll end up with both the netcore45 assembly and the platform-specific Xamarin.iOS10 assembly.
The primitives you use for working ADAL are largely unchanged – they are the familiar
AuthenticationContext
,
AcquireToken
*,
AuthenticationResult
and the like. However the surface has been adjusted to accommodate the fact that your code might now be running on widely different platforms – with different ways of prompting the user, different storage technology for token caches, and so on. Here there’s how we achieve adaptive behavior across platforms.
AcquireToken* now accepts a new parameter, an interface named
IPlatformParameters
. That interface has a concrete implementation,
PlatformParameter
, for all the supported platforms. The main purpose of
PlatformParameters
is to carry a reference of the parent UX element from which you want to trigger the authentication experience: that helps ADAL to determine at runtime whether it should prompt the user using iOS, Android, Windows Store or Windows desktop experiences. The subdivision in interface and concrete classes allows you to maximize code reuse: you can put most of your authentication logic in a portable class, where you use the
IPlatformParameter
– and all you need to do for leveraging that from platform specific projects is to pass in the corresponding
PlatformParameters
platform specific implementation. Let me give you a practical example.
The main ADAL sample demonstrating how to work with Xamarin can be found
here
. It is a simple application, which allows you to query the directory to find basic information about a user.
The solution structure follows the pattern introduced earlier: there is a portable class project containing the bulk of the authentication logic, and platform specific projects (in this case for desktop, UWP, iOS, Android) implementing the experience (note, Xamarin Forms is also supported. See
here
for hints on how to use it).
If you expand the references folder for the portable class library and any of the platform specific projects, you’ll observe the assemblies distribution typical of the pattern.
The portable library refers to the portable ADAL assembly; the platform specific project refers to the portable library, and the ADAL PCL & the platform specific assembly.
The portable class library project contains some basic token acquisition logic. The interesting parts are highlighted below.
public static async Task<List<User>> SearchByAlias(string alias, IPlatformParameters parent)
{
// ...
authResult = await authContext.AcquireTokenAsync(graphResourceUri,
clientId, returnUri, parent);
// ...
The call to AcquireTokenAsync looks like the good ol’ AcquireTokenAsync in ADAL 2.x, except for the new parameter passing in the IPlatformParameters.
Let’s once again pick the Android project as the representative of what happens in platform specific project. The directory searching functionality is implemented in MainActivity.cs. Here there’s the code used to trigger the search.
List<User> results = await DirectorySearcher.SearchByAlias(searchTermText.Text, new PlatformParameters(this));
The
PlatformParameters
instance passed here is the Android specific implementation of
IPlatformParameters
, taking in input the current activity. This allows ADAL to dynamically determine what logic to invoke for displaying prompts and access storage in platform specific fashion. iOS has similar code in its viewcontroller, Windows in its XAML page, and so on.