1. Azure AD Line Of Business Application Integration
TechReady 18
11/9/2018
Azure AD Line Of Business Application Integration
EMS Partner Bootcamp
© 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

2. Integrate an app with Azure AD
Create an Application to AuthN against Azure AD
Web Apps | WS-Fed
SOAP Clients | WS-Trust spec | RST/RSTR
Desktop Apps | OAuth
RESTful Apps | HTTP Methods | Stateless
Graph API
Programmatic access to AAD through REST API Endpoint
Apps use to perform CRUD operations on Directory data and objects
To call on directory must register APP with AAD
RBAC – Security Groups used to perform RBAC in Graph API
EXAMPLES
Create New User, Get Properties, Disable
Check Group Membership, update, delete, etc
Click to watch
Integrate an app with Azure AD
Web apps (WS-federation); desktop apps (OAuth); graph API
REVIEW ADAL too!
…using the OAuth 2.0 Client Credential flow to authenticate the application. Before accessing the Graph API endpoint, the application must first acquire a valid token from Azure AD’s authentication endpoint -- it does this by presenting valid application credentials (client ID and secret). If the credentials are validated, a signed token is returned to the application. Thereafter, the application includes the token in the Authorization header of its calls to the Graph API. The Graph API service validates the token against the incoming request, and if it passes, an authorization check occurs next.
GRAPH API
The Azure Active Directory Graph API provides programmatic access to Azure AD through REST API endpoints. Applications can use the Graph API to perform create, read, update, and delete (CRUD) operations on directory data and objects. For example, the Graph API supports the following common operations for a user object:
Create a new user in a directory
Get a user’s detailed properties, such as their groups
Update a user’s properties, such as their location and phone number, or change their password
Check a user’s group membership for role-based access
Disable a user’s account or delete it entirely
In addition to user objects, you can perform similar operations on other objects such as groups and applications. To call the Graph API on a directory, the application must be registered with Azure AD and be configured to allow access to the directory. This is normally achieved through a user or admin consent flow. For more information, see Accessing the Graph API in the Adding, Updating, and Removing an Application topic.
Query an Azure AD directory using the Graph API

3. Azure Security Tokens SAML Assertion JSON Web Token 11/9/2018
Azure AD emits two types of security tokens. Both of these are also supported with On-premises AD FS as well.
SAML Assertion
Yada yada
XML based. Very heavy format. Chatty and big.
WS-Fed and SAML protocols will use a SAML token.
JSON Web Token
Java Script Object Notation
Doesn’t mean that it has Java Script inside, but that the data format is a popular way that Java Script represents complex data structures in a human readable and easy to parse format. Starts and ends with a curly brace. With the attributes in Name/Value pairs. Therefore it can communicate much more information is a smaller format in comparison to the SAML token. And it is just as secure. Can Sign it, hash it, replay detections….everything you can do with a SAML token in AD FS. Newer protocols like Open ID Connect will use JWTs
© 2015 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

4. Include Claims in Token
Directory
Request Token
Authenticate
Authentication Service
Web App T
There are two ways that we can give an application identity data. This first method is like the traditional method of grabbing claims from a token as shown in the previous slide.
3 dots equal attributes.

5. Authentication Service
11/9/2018
Query the Directory
Request Attributes
Graph API
Directory
Authentication Service
Authenticate
Request Token
Web App T
The second approach is to do a Directory Query
The user authenticates to the app, gets a token – but the authentication service may only provide 2 of the attributes, which will be passed to the application as claims.
If the third attribute is need for the web application apart from the default claims, the then the Graph API is the way that additional attributes can be pulled from Azure AD to be consumed by the application. This is exactly how Azure Active Directory works. In Azure AD you cannot configure the claims as it sends a static list of claims. If you want additional claims, then you have to use the Graph API.
© 2015 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

6. Setting Application Permissions
No User Context
Client Credentials
Now the application needs permissions to access the directory either on an all app basis or a per user basis.
Inside of the application there is a permissions dialog. There are two types of permission. Application and Delegation permissions. The permissions noted will apply to the entire tenant’s directory. This is a very powerful permission!
The second method is on a per user basis aka delegated access. By default, the permissions granted is as is shown in the picture. (read it). What this means, is when the user accesses the application, I will get an access token along with the identity and go back to Azure AD to pull down data for that user and only that user.
Has User Context
Authorization Code

7. Types of Client Applications
SMSG Readiness
11/9/2018
Types of Client Applications
If we have client applications, we can integrate these applications with Azure AD and authenticate to Azure AD to access these apps. By client applications we mean anything that runs on a device.
Desktop
Phone
Tablet
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

8. Register and Grant Permission
Relationships
Client App
Web Service
Web Service
Register with Azure AD
Use the Windows Azure OWIN module to handle bearer token authentication from Azure AD
Client App
Register with Azure AD as a Native Client Application
Grant permission to use the web service
Use ADAL to handle OAuth flow
Register and Grant Permission
Register
John
Azure AD

9. Implementing OAuth at the Client
Most clients have native libraries for the OAuth flows
.NET uses the Active Directory Authentication Library (ADAL)
Used for both Azure AD and AD FS
Single library for Windows Store apps and desktop apps
Also available for other platforms
Active Directory Authentication Librry. ADAL is used by clients for getting access tokens for accessing web services, not for front-end web authentication.
This is the same library used for both AD FS and Azure AD. It is a single library used for integrating Windows Store apps, Windows phone apps, and Desktop apps. The beauty of this is that a developer does not have to have different code bases to work with.
For using ADAL, there is a GitHub repository that the Product Group updates. Just send the customer to the AzureADSamples for examples of how to integrate several types of apps.
Not only does it support .Net, but also iOS, Android, Objective C, Xamarin Library (enables C# code on various devices), PHP, Ruby and several other platforms.

10. Azure AD App Development
Developers Guide
How To’s
Sample Apps for WebApps (Node.js, Javascript, .Net), navitve Apps( iOS, Android, .NET)
Resources
Videos

11. Videos for more information
TechReady 18
11/9/2018
Videos for more information
Develop Modern Web Applications with Azure Active Directory
Develop Modern Native Applications with Azure Active Directory
© 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.