Azure AD – Spikes Apps

Troubleshooting your WebAPI authentication

Rob Lempens — Tue, 01 Aug 2017 12:57:16 +0000

Setting up the security and authentication for a Web API using Azure Active Directory is a well-documented matter. There are some very detailed blogposts out there that will walk you through it step-by-step.

But what happens when you follow all the steps correctly (at least you think so) and the response you get is “Unauthorized”.
Well, that’s what happened to me. I poured blood, sweat, and tears into finding the solution.

The following steps helped me to troubleshoot the issues I had:

Ping-Pong

First, I created a “Ping-Pong” (Hello World) service. I even created one with and one without authentication. By doing this I could be sure all the other possible issues would be ignored.

Chrome Dev Tools & jwt.io

Of course, I also used the Chrome developer tools to debug the JavaScript code calling the service. Here I could find the bearer token and decrypt it using https://jwt.io/ which was giving me a lot more useful information:

Finding the token:

Decrypting the token:

The properties that I thought were helpful were:
– aud –> This should correspond with the “resource” parameter in the web.config
– unique_name –> The owner of this token
– scp –> The permissions granted by this token. Example: AllSites.Write

App Service Editor

Validating the web.config settings of your webAPI in Azure can be done easily using the App Service Editor. You can be sure validating the correct settings by opening this file from Azure.

Always validate that the “tenant” and “audience” parameters are configured correctly.

Custom Authentication Provider

I created a custom Authentication Provider by inheriting from the OAuthBearerAuthenticationProvider class. This code will not do anything except making debugging a lot easier.

public class OAuthBearerAuthenticationProviderEx : OAuthBearerAuthenticationProvider{public override Task ValidateIdentity(OAuthValidateIdentityContext context){return base.ValidateIdentity(context);}public override Task RequestToken(OAuthRequestTokenContext context){return base.RequestToken(context);}}

To implement this extra class I had to update the startup class of my webAPI.

public class Startup{public void Configuration(IAppBuilder app){HttpConfiguration config = new HttpConfiguration();WebApiConfig.Register(config);ConfigureAuth(app);app.UseWebApi(config);var jsonFormatter = config.Formatters.OfType<JsonMediaTypeFormatter>().First();jsonFormatter.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver();}public void ConfigureAuth(IAppBuilder app){app.UseWindowsAzureActiveDirectoryBearerAuthentication(new WindowsAzureActiveDirectoryBearerAuthenticationOptions{Tenant = ConfigurationManager.AppSettings["ida:Tenant"],TokenValidationParameters = new TokenValidationParameters{ValidAudience = ConfigurationManager.AppSettings["ida:Audience"]}, Provider = new OAuthBearerAuthenticationProviderEx()});}}

Diagnostic settings

Finally, I changed the diagnostic settings for more debug information. You can do this by adding the following to your web.config file:

As the result of this change you will get a lot more information in the output window such as a detailed error message as described below.

In the previous example you can see the message “Audiences did not match”. This was caused by a difference in the web.config settings and the configuration in the token. Figuring this out without the detailed information could be very frustrating.

Summary:

Hello world call
Developer tools
Decrypting the bearer token
App service editor to validate the files in Azure
Extending the OAuthBearerAuthenticationProvider class
Enable verbose logging

I hope one of these steps helps you to solve your issue.

Rob Lempens

–

Securing an Angular application with Azure AD

Joren Paps — Thu, 27 Jul 2017 11:33:39 +0000

In this post, I’ll guide you through setting up a new Angular app and configuring it to use Azure AD authentication. This will be as much about the structure of the app itself as it will be about the security setup. The post consists of three main parts:

Create the base application structure
Configure and implement Azure AD authentication
Call a secured Web API

I won’t be using any CSS/UI frameworks so the app itself will look pretty crude. But at the end of this post, you should have a solid barebones app to build upon. Spruce it up with some bootstrap/material/… and you’ll be golden.

Laying the foundations

First, let’s create a new Angular app. We will use the Angular CLI for this, so open up a command prompt and run the ‘ng new’ command.

ng new AdalSample

Now that we have our app, let’s open the folder with VS Code (or your editor of choice) and get going.

The basic structure

Let’s start by creating a new component called ‘main’. This will be the root component for the functional part of our application. It will contain the shared layout for the application (navigation, header, footer…).

ng g component Main

Open up the main.component.html and copy/past the snippet below. The most important part here is the ‘router-outlet’ tag. Our content will get injected after this tag.

  Home

Next is the home component. This will be the landing page for our application.

ng g component main/Home

Before moving on to the next part we also have to replace the content of app.component.html with a router-outlet tag.

Keeping order

When we open the app.module, we’ll see that the Angular CLI automatically adds new components to the declarations array. It also creates a separate import line for each component. We currently only have two components in larger applications, this can become quite a list. We can remedy this by using a barrel to group our components together.

Barrels are files with a fixed name (index.ts), that contain exports of other files. They are a great way to keep import statements to a minimum or to group imports (for example rxjs operator imports). So let’s create one in the app folder.

export * from './app.component';export * from './main/main.component';export * from './main/home/home.component';

Now we can import the barrel and have all our component imports on one line. While we’re in the app.module, let’s make sure the router module is imported. Otherwise our router-outlet won’t work.

import { Route, RouterModule } from '@angular/router';import * as c from './';@NgModule({  imports: [BrowserModule,RouterModule  ],  declarations: [c.AppComponent,c.MainComponent,c.HomeComponent  ],  providers: [],  bootstrap: [c.AppComponent]})export class AppModule { }

Routing

We still need to tell our application how to use our newly created components. Routing can be configured straight in the app.module, but we will be using a separate file to house our route configuration.

Create a new typescript file called ‘app.routing.ts’ in the app folder and paste the code below into it.

import { ModuleWithProviders } from '@angular/core';import { Route, RouterModule } from '@angular/router';import { MainComponent, HomeComponent } from './';const routes: Route[] = [{ path: '', component: MainComponent, children: [  { path: '', component: HomeComponent },]}];export const AppRoutes: ModuleWithProviders = RouterModule.forRoot(routes);

Now all that’s left is adding the AppRoutes constant to the app.module imports. If we start the development server and navigate to localhost:4200, we’ll see the ‘home works!’ message.

Error pages

A good app needs to have error pages. So let’s start by creating a 404 page. I’m using a separate module for the error pages to make use of lazy loading.

ng g module ErrorPages

ng g component error-pages/NotFound

Just like in the app.module, we also have to define the routing for our new module. Create a new file called ‘error-pages.routing.ts’ and add the code below. Don’t forget to add the ErrorPagesRoutes to the error-pages.module imports.

import { ModuleWithProviders } from '@angular/core';import { Route, RouterModule } from '@angular/router';import * as c from './';const routes: Route[] = [{ path: '404', component: c.NotFoundComponent }];export const ErrorPagesRoutes: ModuleWithProviders = RouterModule.forChild(routes);

For our 404 to work, we also need to add some routes to the app.routing file. The ** path in the last route is a wildcard that matches any route that isn’t defined.

const routes: Route[] = [{ path: 'error', loadChildren: 'app/error-pages/error-pages.module#ErrorPagesModule'},{ path: '', component: MainComponent, children: [  { path: '', component: HomeComponent },]},{ path: '**', pathMatch: 'full', redirectTo: 'error/404' }];

If we go back to our website enter a non-existing URL in the address bar, our 404 page is shown. So far, so good.

Authentication

Authentication is done via the Azure Active Directory Authentication Library (ADAL) created by Microsoft. However, we won’t be using Microsoft’s ADAL.js directly, instead we’ll use an Angular wrapper library for ADAL. That way, we can skip over a lot of the boiler plate code. The one we’ll be using in this example is adal-angular4, so let’s go ahead and add the package to our solution.

npm i adal-angular4 --save

Once installation is complete, open up the app.module and add the imports below.

import { Http, HttpModule } from '@angular/http';import { Adal4Service, Adal4HTTPService } from 'adal-angular4';

To allow the Adal4Service to be injected into our components, we need to add it to the providers array.

  providers: [Adal4Service,{provide: Adal4HTTPService,useFactory: Adal4HTTPService.factory,deps: [Http, Adal4Service]}  ],

The Azure part

Now we need to make Azure aware of our app. Go to the Azure portal and select the Azure Active Directory blade. Under App Registrations, create a new App Registration.

The name you enter here will be displayed on the login screen, so choose something friendly. For the remaining fields, select ‘Web app / API’ and enter the Angular development server URL.

Do not close the Azure portal just yet, we’ll come back to it in a minute.

Setting up ADAL

Back in our Angular project, it is now time to add our ADAL configuration to the environments file(s). The CLI creates two environment files by default. One for production (when building with the –prod switch) and one for everything else.

Open the environments.ts file and add an adalConfig entry as shown. The tenant value can be found in the Azure Active Directory blade under ‘Domain names’. For the clientId we need to go back to the App Registrations list. Open the registration we just created and copy the Application ID guid.

export const environment = {  production: false,  adalConfig: {tenant: 'my-tenant.onmicrosoft.com',clientId: '00000000-0000-0000-0000-000000000000'postLogoutRedirectUri: 'http://localhost:4200/logout'  },};

Now we’re ready to enable authentication for our app. Open the app.component and change it to the the following.

import { Component, OnInit } from '@angular/core';import { Adal4Service } from 'adal-angular4';import { environment } from '../environments/environment';@Component({  selector: 'app-root',  templateUrl: './app.component.html',  styleUrls: ['./app.component.css']})export class AppComponent implements OnInit {  constructor(private adalSvc: Adal4Service) {this.adalSvc.init(environment.adalConfig);  }  ngOnInit(): void {this.adalSvc.handleWindowCallback();  }}

The init call speaks for itself. It initializes the ADAL service using the settings in our environment file. The handleWindowCallback call will extract the bearer token from the URL when Azure returns to our application after sign-in.

At this point, we’ve fully configured the ADAL service, but when we run the application we won’t see any change just yet.

Login / Logout

It is now time to enable login for our application. For this purpose we will create two additional pages.

ng g component Login

ng g component Logout

The actual logging in is handled by Azure, I hear you think. So why do we need a login page in our application? Well, the name says it all. This is going to be the page where we will call the ADAL login function. Additionally it serves as a splash screen of sorts. So the user won’t see a flash of the actual application before being redirected to the Azure login page.

You’ll see I’ve also included the option to provide a return URL in the querystring. This will be used by our authentication guard. If we didn’t have this in place, the user would always end up on the home screen after logging in.

import { Component, OnInit } from '@angular/core';import { ActivatedRoute, Router } from '@angular/router';import { Adal4Service } from 'adal-angular4';@Component({  selector: 'app-login',  templateUrl: './login.component.html',  styleUrls: ['./login.component.css']})export class LoginComponent implements OnInit {  constructor(private route: ActivatedRoute,private router: Router,private adalSvc: Adal4Service  ) { }  ngOnInit() {const returnUrl = this.route.snapshot.queryParams['returnUrl'] || '/';if (this.adalSvc.userInfo.authenticated) {  this.router.navigate([returnUrl]);} else {  this.adalSvc.login();}  }}

Next is the logout page. When the user clicks the logout link, this will be the place they’re sent. This will also be the page Azure redirects to after logging out. We set the redirect using the ‘postLogoutRedirectUri’ property in the Adal configuration.

As you can see in the code, the only thing that happens here is the logout call. Like with the login page, a reason for keeping this in a separate component is to have a splash screen to show between the time the user clicks logout, and the redirect to Azure.

import { Component, OnInit } from '@angular/core';import { Adal4Service } from 'adal-angular4';@Component({  selector: 'app-logout',  templateUrl: './logout.component.html',  styleUrls: ['./logout.component.css']})export class LogoutComponent implements OnInit {  isAuthenticated = false;  constructor(private adalSvc: Adal4Service  ) {this.isAuthenticated = this.adalSvc.userInfo.authenticated;  }  ngOnInit() {if (this.isAuthenticated) {  this.adalSvc.logOut();}  }}

In the markup we set different messages to show based on the status of the user (authenticated or not).

Signing out...  Signed out successfully. Click here to log back in.

To test the logout page, we also have to add a logout link to our main.component.

  Home  Logout

And before moving on, we still need to clean up some things. As usual, the CLI has already added our new components to the app.module. But we’re using a barrel, remember?

So first add the new components to our barrel in the app folder and correct the declarations in the module. The now unused imports can be removed.

export * from './app.component';export * from './login/login.component';export * from './logout/logout.component';export * from './main/main.component';export * from './main/home/home.component';

  declarations: [c.AppComponent,c.MainComponent,c.HomeComponent,c.LoginComponent,c.LogoutComponent  ],

Securing content

We’ve done a lot of setup work up to this point. But, this is where we will actually see everything come together.

To secure our main component and everything below it, we’re going to use a guard. This is nothing more than a class that implements some interfaces. Angular provides four interfaces for protecting routes.

CanActivate
CanActivateChild
CanDeactivate
CanLoad

For our app, we will only use CanActivate and CanActivateChild. If you want a more in depth explanation, Pascal Precht has a very nice post on guards.

First, let’s create a new folder called ‘common’ with a subfolder ‘guards’. In the guards folder, we create a new file called ‘authentication-guard.ts’ with the following content.

import { Injectable } from '@angular/core';import { Router, CanActivate, CanActivateChild, ActivatedRouteSnapshot, RouterStateSnapshot } from '@angular/router';import { Adal4Service } from 'adal-angular4';@Injectable()export class AuthenticationGuard implements CanActivate, CanActivateChild {  constructor(private router: Router,private adalSvc: Adal4Service  ) { }  canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): boolean {if (this.adalSvc.userInfo.authenticated) {  return true;} else {  this.router.navigate(['/login'], { queryParams: { returnUrl: state.url } });  return false;}  }  canActivateChild(childRoute: ActivatedRouteSnapshot, state: RouterStateSnapshot): boolean {return this.canActivate(childRoute, state);  }}

When any of the CanActivate methods get called, our guard checks whether the user is logged in. If the user needs to login, it will redirect to our login page with the current route’s URL in the querystring.

For all this to work, we still need to do two things. Add our guard to the providers array in our app.module and register it on some routes.

  providers: [Adal4Service,{provide: Adal4HTTPService,useFactory: Adal4HTTPService.factory,deps: [Http, Adal4Service]},AuthenticationGuard  ],

const routes: Route[] = [{ path: 'error', loadChildren: 'app/error-pages/error-pages.module#ErrorPagesModule'},{ path: 'login', component: LoginComponent },{ path: 'logout', component: LogoutComponent },{ path: '', component: MainComponent, canActivate: [AuthenticationGuard], canActivateChild: [AuthenticationGuard], children: [  { path: '', component: HomeComponent },]},{ path: '**', pathMatch: 'full', redirectTo: 'error/404' }];

Our guard will get called when the user navigates to the main component or one of it’s child routes.

When running the application, you will see that the functional part of our application now requires authentication, while things like the error pages, login and logout are reachable without logging in.

Getting data

Now that we’ve secured our application, it is time to get some data. For that purpose, I have a secure WebAPI hosted in Azure that returns some hard-coded employee data. I won’t go into detail on how to set up a WebAPI since it not in the scope of this post. Koen has written an excellent post on how to do this.

The setup

To make use of Angular’s lazy loading, we will create a new module to group everything employee related. Organising your application into functional blocks like this has the added benefit of having components, services and models in close proximity.

First we’re going to create the module, the list component and the service class.

ng g module main/Employee

ng g component main/employee/List

ng g service main/employee/Employee

Next is our employee model. Add a folder ‘models’ in the employee folder and create a new file called ’employee.ts’. Copy the snippet below and save.

export interface IEmployee {  id: number;  name: string;  function: string;}export class Employee implements IEmployee {  id: number;  name: string;  function: string;  constructor(obj?: IEmployee) {if (obj) {  Object.assign(this, obj);}  }}

Normally I would also create barrels in the ’employee’ and ‘models’ folders. But since this example won’t get any extra functionality, we will skip the barrels.

Create a file called ’employee.routing.ts’ And add the route to the list component.

import { ModuleWithProviders } from '@angular/core';import { Route, RouterModule } from '@angular/router';import { ListComponent } from './list/list.component';const routes: Route[] = [{ path: '', component: ListComponent }];export const EmployeeRoutes: ModuleWithProviders = RouterModule.forChild(routes);

We still need to link everything up, so open up the employee module and add the EmployeeRoutes and EmployeeService.

import { NgModule } from '@angular/core';import { CommonModule } from '@angular/common';import { EmployeeRoutes } from './employee.routing';import { EmployeeService } from './employee.service';import { ListComponent } from './list/list.component';@NgModule({  imports: [CommonModule,EmployeeRoutes  ],  declarations: [ListComponent  ],  providers: [EmployeeService  ]})export class EmployeeModule { }

And lastly, add a link to our employee list and that’s it for the setup.

  Home  Employees  Logout

The implementation

For the service implementation, we have it pretty easy. Adal-angular4 will do almost everything for us. But first we need to make Adal aware of our api and that requires we make some changes in our environments file.

export const environment = {  production: false,  adalConfig: {tenant: 'my-tenant.onmicrosoft.com',clientId: '00000000-0000-0000-0000-000000000000'postLogoutRedirectUri: 'http://localhost:4200/logout',endpoints: {  'https://adaltestapi.azurewebsites.net': 'https://adaltestapi.azurewebsites.net'},  },  apiUrl: 'https://adaltestapi.azurewebsites.net/api/'};

The ‘apiUrl’ is for use in our service and it contains the base URL of our WebAPI. For service authentication to work correctly, we also need to add our API to the endpoints in our Adal configuration. The endpoints value is an object with key/value pairs for each resource the application uses. The key is the resource URL and the value is the App ID URI. You can find this value in the Azure portal under the app registration settings of your API.

Now on to the service itself. We do essentially the same as we normally do, but instead of Angular’s Http, we use the Adal4HTTPService. This wrapper works virtually the same as Http, but it will automatically add the bearer token to the request. But only if the request URL is defined as an endpoint.

import { Adal4HTTPService } from 'adal-angular4';import { environment } from '../../../environments/environment';import { Employee, IEmployee } from './models';@Injectable()export class EmployeeService {constructor(private http: Adal4HTTPService  ) { }  public getEmployees(): Observable> {return this.http.get(`${environment.apiUrl}Employee`)  .map(response => {const tmp = response.json();return tmp.map(e => new Employee(e));  });  }}

All that is left, is to call our service and show the data on screen. This is exactly the same as you’re used to.

export class ListComponent implements OnInit {  employeeList: Array = [];  constructor(private empSvc: EmployeeService  ) { }  ngOnInit() {this.empSvc.getEmployees().subscribe(  rslt => this.employeeList = rslt,  error => console.log(error));  }}

Employees
Id Name Function
{{emp.id}} {{emp.name}} {{emp.function}}

Id	Name	Function
{{emp.id}}	{{emp.name}}	{{emp.function}}

Conclusion

And that is it. Using Adal with Angular is pretty easy when using a wrapper like adal-angular4. But as I said in the intro, this post is mostly about providing a decent starting structure for the types of business apps a lot of us typically work on. The biggest advantage I find, is that authentication code is centralised. None of the components under main have to know anything about Adal, Azure or security. All this is handled far away from the business and UI logic, which makes for an easier to maintain application.

The source code of the sample projects can be found on our GitHub.

Joren Paps

Senior Developer @ Spikes

Azure AD provider for Horizon

Ruben B — Sun, 07 May 2017 15:12:56 +0000

Intro

We’re employing 2 interns this year at Spikes. They are developing an application for internal use and are learning new technologies to accomplish that goal. One of those is Horizon .

Horizon offers multiple OAuth providers out of the box, such as Auth0, Github, Facebook, Google, … We would like to use Azure AD in this project and as the interns already have enough on their plate, we decided to implement this part for them.

Creating the provider

Having a close look at the already implemented providers, it wasn’t that hard to figure out the mechanics used for the others. Most of them had a similar implementation, except for the Twitter one.

I focused on the standard implementations which all implement 3 specific calls:

Acquire an authorization code
Use the acquired authorization code to request an access token
Acquire user information based on the access token

Microsoft has a pretty good documentation for part 1 and 2, which you can find here.

Part 3 however was another story. Apparently, the userinfo endpoint on Azure requires a non standard access token. This token can be acquired by requesting an authorization code and access token without mentioning a resource. (source)

Looking more closely at the information that Horizon needs from the user, we decided to just decode the acquired access token.

The code

Acquiring the the authorization code (source):

oauth_options.make_acquire_url = (state, redirect_uri) =>url.format({protocol: 'https',host: 'login.microsoftonline.com',pathname: `/${options.tenant}/oauth2/authorize`,query: { client_id, redirect_uri, state, response_type: 'code', response_mode: 'query' },body: { response_type: 'code' }});

Acquiring the access token (source):

oauth_options.make_token_request = (code, redirect_uri) => {const body_params = querystring.stringify({grant_type: 'authorization_code', client_id, client_secret, redirect_uri, code,resource: options.resource});const path = `/${options.tenant}/oauth2/token`;const req = https.request({method: 'POST',port: 443,host: 'login.microsoftonline.com',path: path,headers: {'content-type': 'application/x-www-form-urlencoded','Content-Length': body_params.length}}); req.write(body_params);return req;};

Decoding the access token (source):

if (provider === 'azuread') {const user_info = jwt(access_token);const user_id = user_info.oid;horizon._auth.generate(provider, user_id).nodeify((err3, jwt) => {// Clear the nonce just so we aren't polluting clients' cookiesclear_nonce(res, horizon._name);do_redirect(res, err3 ?  make_failure_url('invalid user') :  make_success_url(jwt.token));});}

Full code can be found here.

Usage

Using the provider in a nodejs server application:

const horizon = require('@horizon/server');const http = require('http'); const server = http.createServer();server.listen(80); const options = {project_name: '',rdb_host: '.cloudapp.azure.com',rdb_port: '',auto_create_collection: true,auto_create_index: true,permissions: false,access_control_allow_origin: '*',auth: {token_secret: '',allow_anonymous: false,allow_unauthenticated: false,success_redirect: ''}};const horizonServer = horizon(server, options); horizonServer.add_auth_provider(horizon.auth.azuread,{id: '',secret: '',path: 'azuread',tenant: '',resource: ''});

Feel free to comment down below!

Ruben Biesemans

Analyst Developer @ Spikes

What’s my login again?

jasperbernaers — Thu, 29 Dec 2016 10:19:15 +0000

Over the last few years I’ve worked on projects where we enable customers towards Office 365. Mail migration, collaboration (SharePoint) skype for business, yammer etc..

Most of the times we have difficult discussions about the choice that could be make about changing the userprincipalname and if it’s really required to change it.

Next to it, it looks like is has become a complex situation convincing our customers to choose for the one single identity. And understand the importance of it. Mostly struggling thought an assessment phase we give the understand to our customers that we should take enough time for the importancy of “identity”. Certainly in this time were security is one of the most important priorities for organizations to improve. And we don’t want to mix-up accounts and make new account for each platform where we like a user could connect to.

In this blog I would like you to understand from an end-user and administrator perspective why to choose for a single identity, cross-premises. And how we could start from this perspective to guarantee that it will become easier for you and your end-users.
In parallel i’ve mixed it with the discussion of changing a part of your identity which is an uniform userlogonname, the userprincipalname.

Hybrid identity – is it a central identity?

“The core of a Microsoft-based centralized identity is Active Directory.” As for a lot of customers we see they have a well implement Active Directory in their organization on a mature and strict way. They use their identity for signing in on their devices, use their identity for their CRM solution, HR platforms, etc…

Hybrid identity – cross premises.

Now, after we have our ‘central identity’ platform ADDS on-premise. We could extend this towards another premise. Therefore we use Azure AD to synchronize the on-premise identity towards Azure Active Directory.

“What is a UserPrincipalname, should it change, and if we change it, will we impact all our users?”

It’s one of the most raised questions, and it could be a complex one. An userprincipalname is the logon name for the user to authenticate toward Active Directory. In an O365 deployment it’s the unique identifier we are using through the environment. As for exchange on-premise and in the cloud.

Administrators are aware where to find it, but let me show you what I meant:

Blue = Userprincipalname = Userlogon (max lenght in characters 64)
Orange Samaccount = Pre-Windows 2000 Logon (max lenght in characters 20)

Like it or not, working towards an identity synchronization directory requires some effort for administrators to provide the best experience for your end-users. In a lot of companies we see a difference in configuration when we are talking about UserPrincipalName (UPN) and the synchronization of it. Some companies are confident that they should not change their UPN and keep them identical to the samaccount. Some choose to change the UPN to the mail address.

For better user experience. It’s well recommended to change the UPN and match it with the primary mailaddress. Make it synchronized to have the same identical name in the on-premise environment as in the cloud.

Make it easier for your users:

When logging in in Onedrive, Onenote and almost all Microsoft services you will be asked to fill-in your mail address. But they mean your UPN.

Skype for Business:

When using skype for business, your default ‘login’ will be your SIP Address. So it is unclear for a user which login they should enter. You could update your SIP addresses to have the same identifier as your mail/upn. Or you could choose for a different address and let your business contacts know that you cannot be reached on your mail address but on your dedicated Skype For Business address. So splitting up your mail address and skype address could be chosen.

What about federation:

You could implement Active Directory Federation Services (ADFS) to have Single Sign-on (SSO) features to help your user logging-in in O365 services. Keep in mind that when they are at home they still need to go through the ADFS and authenticate based on Windows Authentication or Forms Authentication.

Bring it all together:

For an end-user perspective, it’ best to explain your employees that since you are moving more and more services to Office 365 to start working with their UserPrincipalname which is their mail address.

Keep it simple: Let your employees login with 1 identifier which is their mail skype and every other Office 365 services address.

And If it requires a change, let’s do it right away. Communicate the change to all your employees. So you could start as soon as possible with their one and only, simple, single identity.

Jasper Bernaers

Hybrid Cloud Infrastructure Consultant @ Spikes

Azure AD: Cloud App Discovery

Christophe Lambrecht — Tue, 27 Dec 2016 13:22:21 +0000

Introduction

Microsoft introduced “Cloud App Discovery” more than a year ago, but not many enterprises benefit or even thought about using this service.

It’s actually very simple, Microsoft explains this very good in its own words:

In modern enterprises, administrators are often not aware of all the SaaS applications that are used by the users to do their work. As a consequence of this, administrators often have concerns in conjunction with unauthorized access to corporate data, possible data leakage and other security risks inherent in the applications. Because they don’t know how many or which apps are used, even getting started building a plan to deal with these risks seems to be daunting.

Benefit

So, what can you expect form this:

discover applications in use and measure usage by:

o volume (traffic)

o number of users

o number of web requests

identify the users that are using an application
export data
easier to practice shadow IT
bring applications under IT control and integrate applications easily to enable

o single sign-on

o user management

What do you need

Cloud App Discovery is part of the Azure AD premium features portfolio of Microsoft.

With the new licenses models of Microsoft, a P1 license is sufficient.

Keep in mind that only the admins that want to access the logs and reports need a license, so you’re users don’t need any kind of license for this, this is the nice part of the service.

There is not much needed to configure it’s an out-of-the box service.

Follow these few steps and you’re good to go:

1) Login to your Azure portal as an Administrator (https://portal.azure.com)

2) Search for “cloud app discovery”

3) Click on “create” and you can start configuring it.

4) Go to settings

For the Agent part, you only have a few options that can be changed.

Notification for the users is the most important part, this is can be a legal issue if you don’t configure it correctly.

Deep Inspection and Automatic Updates can be set/left to “on” nothing special about these things.

On the data collection part, you can select which apps that can be discovered. There are about 1465 apps and 25 categories.

If you want to use the data for your own research, this is possible in the “store data” section.

You can export the data to Azure Blob Storage if you want using the configuration screen above.

Through Manage access, you can add people that can use this service and consult the reporting and/or settings.

Notifications can be set in the last menu item. You don’t have many options here, only on weekly base.

Once you have checked and changed the config, we can start using the service.

How does it work

Collecting data

With cloud app discovery, the data retrieval part is accomplished by agents that run on computers in your environments.

You need to deploy a client agent to the machines/users you want to assess.

This is done using the client that can be downloaded in the portal:

You can also deploy the client using GPO’s or SCCM for large scale deployment:

http://social.technet.microsoft.com/wiki/contents/articles/30965.cloud-app-discovery-group-policy-deployment-guide.aspx

http://social.technet.microsoft.com/wiki/contents/articles/30968.cloud-app-discovery-system-center-deployment-guide.aspx

After installation, you’ll see this in your services:

Uploading data

The app usage information that is captured by the agents is send over a secure, encrypted channel to the cloud app discovery service on the Azure platform.

Analysis

The cloud app discovery service evaluates the data and generates reports you can use to analyse your environment.

You have a few basic reports available on the portal.

The total number (count) of observed apps, the number of unmanaged apps and the number of managed apps. This graph can be modified to show volume or web requests.
The total number of observed users.
The total number of observed agent installations.

If you go to the details, you get the list of managed and unmanaged applications.

You can do the same for “users” and “agents”.

Disadvantages

The only disadvantage is the agent that is needed for the assessment:

Agent is an executable, not an MSI package
Agent is not fail proof with other clients (for example with the Microsoft TMG agent)

Conclusion

Very nice service, can be setup very fast without a lot of additional work (except client deployment).

Data from this tool is also being used for the Azure AD Identity Protection service that Microsoft released a few months ago.

Christophe Lambrecht

Service Area Manager @ Spikes

Securing your Web API

Koen Koninckx — Mon, 26 Dec 2016 19:45:55 +0000

Every SharePoint developer has probably done it: create a web service to access SharePoint data from a provider-hosted add-in and allow the web service to make app-only calls to SharePoint using an AppOnly access token. You forget that the web service doesn’t require any authorization, and doing so, people from outside your organisation – who know the existence of your web service – will be able to access your SharePoint data as well, because by default there isn’t any authorization required to use the web service. You should never forget to only allow authenticated users by enabling Azure Active Directory Authentication for your web service!

In this blogpost I will show you how you can access your SharePoint data in a secure way, without using the AppOnly token. I will not even create a SharePoint add-in.

The three main components that will be used in this demo are:
– Azure AD application
– Azure web app to host your web service
– SharePoint online

Basicaly this means you will need to be global administrator on Azure to complete all of the steps.

Build your Web API in Visual Studio

Create a Visual Studio project

Open Visual Studio and create a new ASP.NET Web Application

Create an empty project. I opted to add folders and references for Web API and to host the web app in the cloud.

Because I selected to host the app in the cloud in the previous step, I can create the app service that will host the API from the same wizard.

Click Create.

Add NuGet packages

We will start to add some NuGet packages to the backend web project. Click Tools > NuGet Package Manager > Package Manager Console. Install the following packages:

Install-Package Microsoft.AspNet.WebApiInstall-Package Microsoft.AspNet.WebApi.OwinInstall-Package Microsoft.Owin.Host.SystemWebInstall-Package Microsoft.Owin.Security.ActiveDirectoryInstall-Package Microsoft.IdentityModel.Clients.ActiveDirectory -Version 2.15.204151539Install-Package SharePointPnPCoreOnline

Add Owin Startup Class

We will start by telling the Owin Framework what class is responsible for the Owin initialization.
Add a new item of type OWIN Startup class to the backend web project.

Add the following code snippet to the Startup class

[assembly: OwinStartup(typeof(Spikes.SecureWebAPIWeb.Startup))]namespace Spikes.OAuthWebAPI{public partial class Startup{public void Configuration(IAppBuilder app){ConfigureAuth(app);HttpConfiguration config = new HttpConfiguration();WebApiConfig.Register(config);app.UseWebApi(config);var jsonFormatter = config.Formatters.OfType<JsonMediaTypeFormatter>().First();jsonFormatter.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver();}public void ConfigureAuth(IAppBuilder app){app.UseWindowsAzureActiveDirectoryBearerAuthentication(new WindowsAzureActiveDirectoryBearerAuthenticationOptions{Tenant = ConfigurationManager.AppSettings["ida:Tenant"],TokenValidationParameters = new TokenValidationParameters{ValidAudience = ConfigurationManager.AppSettings["ida:Audience"]},});}}}

Update WebApiConfig Class

Open the class WebApiConfig located in the App_Start folder and update with the folowing code.

public static class WebApiConfig{public static void Register(HttpConfiguration config){config.MapHttpAttributeRoutes();config.EnableCors();config.Routes.MapHttpRoute(name: "DefaultApi",routeTemplate: "api/{controller}/{id}",defaults: new { id = RouteParameter.Optional });config.Formatters.JsonFormatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("text/html"));}}

Add a Controller to Handle Requests

Create a new Folder named Controllers. Add a new Web API 2 Controller.

Give it a name.

Add the following code to it. The Authorize attribute will make sure that only authorized calls are allowed to access the controller. The GetSharePointAccessToken will get a new token to access SharePoint Online and get the sites’s web title.

[Authorize][RoutePrefix("api/v1/oauth")]public class OAuthController : ApiController{[HttpGet][Route("getwebtitle")]public string GetWebTitle(string sharePointUrl){string accessToken = GetSharePointAccessToken(sharePointUrl, this.Request.Headers.Authorization.Parameter);using (var context = TokenHelper.GetClientContextWithAccessToken(sharePointUrl, accessToken)){Web web = context.Web;context.Load(web);context.ExecuteQuery();return web.Title;}}internal static string GetSharePointAccessToken(string url, string accessToken){string clientID = ConfigurationManager.AppSettings["ida:ClientID"];string clientSecret = ConfigurationManager.AppSettings["ida:ClientSecret"];var appCred = new ClientCredential(clientID, clientSecret);var authContext = new AuthenticationContext("https://login.windows.net/common");AuthenticationResult authResult = authContext.AcquireToken(new Uri(url).GetLeftPart(UriPartial.Authority), appCred, new UserAssertion(accessToken));return authResult.AccessToken;}}

Configure your Azure web app

Log on to your Azure portal and go to the web application you have created earlier. First of all, we will make sure that this web app can only be accessed by athenticated users.

Authentication / Authorization

Open your web app and go to Authentication / Authorizatio settings. Turn on App Service Authentication and select Azure AD as authentication provider.

Choose Express settings > Create New AD App.

After you have clicked Ok, you should save your settings! An Azure AD Application will be created in the background.

CORS settings

To make sure we can access our web API, we also have to update the CORS settings. More information about CORS can be found here. I have allowed all origins here, but of course in real life, you also want to restrict that.

Configure your Azure AD Application

The Azure AD application has been created in the background for us, but still we need to update some settings and grab some information from it to make our solution work.

OAuth 2.0 Authorization Code Grant Flow

Your first step is to generate a client secret (key) in the configuration page of your Azure AD application. Be aware that once your client secret is generated, you will not be able to see it again – so store it safely once you get it. We will need this later.

OAuth 2.0 Implicit Grant Flow

If you’re building a SPA web app you may be in need of the implicit grant flow, as you’ll perform most of your computing on the client-side. Before you can use the implicit grant flow with your Azure AD application – you will need to enable it in your Azure AD application. Go to the manifest of your application and update the setting oauth2AllowImplicitFlow from false to true.

Reply Urls

We also need to update the Reply URLs. Add the url(s) from where you will call the web API. If the location is not listed here, you will get an error when trying to access it. You can also see this as some kind of security.

Permissions

Here we will set the permissions our application will need. If you want to act on behalf of a user, you should pick delegated permissions. In this example we will as the Office 365 SharePoint Online API.

Properties

Now everything is set up, we will need to grab some parameters. We will need those later add them to the web.config of our web application and to our javascript that will call the web API.

TenantId: you can find in the endpoints section. Take any of the endpoints urls. The guid in there corresponds to your tenant ID
ClientId: the Application ID, found in the properties page of your application
Audience: the App ID URI, found in the properties page of your application

Consent

One last step to start using our API, is provide and admin consent to our application. Update the following url with the parameters of your own application and paste it in your browser.

https://login.microsoftonline.com//oauth2/authorize?response_type=code&client_id=&redirect_uri=&prompt=admin_consent

Log in with your admin account. You will be redirected to a content page which provides you an overview of permissions you have granted to your application. Click Accept.

Note that every time, you make changes to the permissions, you need to regrant the application consent.

Configure & publish the web app

Now that everything is set up, we Open the web.config of the web app and add the following parameters:

We are ready to publish our web app to Azure!

Let’s test!

To test the web API, I have created a simple HTML page with a button that will call the web API. The result is printed to the console.

I have added a content editor web part to a SharePoint site in my tenant and referenced this html file.

OAuth Web API test page

Check the browser console – you will find the token and the name of the site!

Now what will happen if we open the same html file from a location that is not defined in our Azure AD application? Outside the SharePoint context?

You will be redirected to the Microsoft online sign in page where you are asked for your credentials. So far, so good.

But you will get an error message because the reply address is not a valid URL..

Sources:

The following source code on PnP was very big help while testing Azure Active Directory Authentication and writing this blog: https://github.com/SharePoint/PnP/tree/master/Samples/AzureAD.WebAPI.SPOnline

Azure AD – Spikes Apps

Troubleshooting your WebAPI authentication

Ping-Pong

Chrome Dev Tools & jwt.io

App Service Editor

Custom Authentication Provider

Diagnostic settings

Summary:

Rob Lempens

Securing an Angular application with Azure AD

Laying the foundations

The basic structure

Keeping order

Routing

Error pages

Authentication

The Azure part

Setting up ADAL

Login / Logout

Securing content

Getting data

The setup

The implementation

Employees

Conclusion

Joren Paps

Senior Developer @ Spikes

Azure AD provider for Horizon

Intro

Creating the provider

The code

Usage

Ruben Biesemans

Analyst Developer @ Spikes

What’s my login again?

Hybrid identity – is it a central identity?

Hybrid identity – cross premises.

“What is a UserPrincipalname, should it change, and if we change it, will we impact all our users?”

Make it easier for your users:

Skype for Business:

What about federation:

Bring it all together:

Jasper Bernaers

Hybrid Cloud Infrastructure Consultant @ Spikes

Azure AD: Cloud App Discovery

Introduction

Benefit

What do you need

How does it work

Collecting data

Uploading data

Analysis

Disadvantages

Conclusion

Christophe Lambrecht

Service Area Manager @ Spikes

Securing your Web API

Build your Web API in Visual Studio

Create a Visual Studio project

Add NuGet packages

Add Owin Startup Class

Update WebApiConfig Class

Add a Controller to Handle Requests

Configure your Azure web app

Authentication / Authorization

CORS settings

Configure your Azure AD Application

OAuth 2.0 Authorization Code Grant Flow

OAuth 2.0 Implicit Grant Flow

Reply Urls

Permissions

Properties

Consent

Configure & publish the web app

Let’s test!

OAuth Web API test page

Koen Koninckx

O365 Developer @ Spikes