PPTX, PDF4,036 views

Azure Active Directory - An Introduction

Azure Active Directory (Azure AD) is Microsoft's cloud-based identity and access management service. It authenticates over 1 trillion times since release and manages identity data for over 5 million organizations, including 86% of Fortune 500 companies using Microsoft Cloud services. Azure AD provides single sign-on, multi-factor authentication, and application access management across devices and platforms.

Technology◦

Azure Active Directory – An
Introduction

1
Trillion
Azure AD
authentications
since the release
of the service
50 M
Office 365 users
active every
month
>1 Billion
authentications
every day on
Azure AD
More than
500 M
objects hosted on
Azure Active
Directory
Azure AD
manages identity
data for
>5 M
organizations
86%
of Fortune 500
companies on
Microsoft Cloud
(Azure, O365, CRM
Online and PowerBI)

AuthenticationContext ctx=
new AuthenticationContext("https://login.windows.net/contoso.onmicrosoft.com");
AuthenticationResult rez = await ctx.AcquireTokenAsync(
"https://outlook.office365.com/",
"5fc4a5a2-78d5-4d94-b890-a6e6b3341081");

Azure Active Directory - An Introduction

1.
Azure Active Directory– An Introduction
2.
What is AzureAD
3.
1 Trillion Azure AD authentications since therelease of the service 50 M Office 365 users active every month >1 Billion authentications every day on Azure AD More than 500 M objects hosted on Azure Active Directory Azure AD manages identity data for >5 M organizations 86% of Fortune 500 companies on Microsoft Cloud (Azure, O365, CRM Online and PowerBI)
17.
OpenID Connect
29.
here
30.
AuthenticationContext ctx= new AuthenticationContext("https://login.windows.net/contoso.onmicrosoft.com"); AuthenticationResultrez = await ctx.AcquireTokenAsync( "https://outlook.office365.com/", "5fc4a5a2-78d5-4d94-b890-a6e6b3341081");
31.
Mobility Azure AD Connect
32.
Azure AD forDevelopers

Editor's Notes

#3 Azure AD is full suite of identity management capabilities Provides the following support: Multi factor auth Device registration Self service password management Role based access control Security monitoring and alerting Azure AD is used by Office 365, Dynamics CRM & Windows Server
#5 Support Azure AD as a way to Sign into your application: Reduce sign in friction and reduce support costs Simplify sign up for your application Browse for Users, Manage User provisioning and Control access to your application Browse for users in your directory using Graph Api – browse the organization hierarchy Re use Active directory groups and distribution lists your customer is already managing – Use Azure AD to control who has access to your application – Authorization – Access to specific resource for a given user Use Azure AD for role based access control – Assign roles and the token contains the roles Get Access to User profile, Calendar, Email, Contacts.. 1. Azure AD is the authorization server for Office 365 and other Microsoft business services. If you support Azure AD for sign in to your application or support linking your current user accounts to Azure AD user accounts using OAuth 2.0, you can request read and write access to a user's profile, calendar, email, contacts, files, and other information. You can seamlessly write events to user's calendar, and read or write files to their OneDrive Secure Device-to-Service and Service-to-Service communication 1. Using Azure AD for identity management of services and devices reduces the code you need to write and enables IT to manage access. Services and devices can get tokens from Azure AD using OAuth and use those tokens to access web APIs. Using Azure AD you can avoid writing complex authentication code. Since the identities of the services and devices are stored in Azure AD, IT can manage keys and revocation in one place instead of having to do this separately in your application
#6 Multi-factor authentication. Azure AD provides native multi-factor authentication. IT administrators can require multi-factor authentication to access your application, so that you do not have to code this support yourself. Learn more about Multi-Factor Authentication. Conditional access. In addition to multi-factor authentication, administrators can require specific conditions be met before users can sign-in to your application. Conditions that can be set include the IP address range of client devices, membership in specified groups, and the state of the device being used for access. Learn more about Azure Active Directory conditional access. Industry standard protocols. Microsoft is committed to supporting industry standards. Azure AD supports the SAML 2.0, OpenID Connect 1.0, OAuth 2.0, and WS-Federation 1.2 authentication protocols. The Graph API is OData 4.0 compliant.
#9 Cloud-based identity technologies can be used to solve a variety of problems. Azure Active Directory can give an organization's users single sign-on to multiple SaaS applications, for example. But identity technologies in the cloud can also be used in other ways. https://docs.microsoft.com/en-us/azure/active-directory/fundamentals-identity But while every identity provider issues some kind of token, those tokens aren't standard - each IdP has its own format. Furthermore, the information in those tokens also isn't standard. An application that wishes to accept tokens issued by, say, Facebook, Google, and Microsoft is faced with the challenge of writing unique code to handle each of these different formats.+ But why do this? Why not instead create an intermediary that can generate a single token format with a common representation of identity information? This approach would make life simpler for the developers who create applications, since they now need to handle only one kind of token. Azure Active Directory Access Control does exactly this, providing an intermediary in the cloud for working with diverse tokens. Figure 4shows how it works These rules let each application's administrator define how tokens from various IdPs should be transformed into an Access Control token. For example, if different IdPs use different types for representing usernames, Access Control rules can transform all of these into a common username type. Access Control then sends this new token back to the browser (step 4), which submits it to the application (step 5). Once it has the Access Control token, the application verifies that this token really was issued by Access Control, then uses the information it contains (step 6).+ And even though Access Control is part of the Azure Active Directory family, you can think of it as an entirely distinct service from what was described in the previous section. While both technologies work with identity, they address quite different problems (although Microsoft has said that it expects to integrate the two at some point).+
#10 Users and administrators of one Azure AD directory cannot accidentally or maliciously access data in another directory.
#12 Authorization Code – Authorization code is obtained by using an authorization server as intermediary between the client and the resource owner. Instead of requesting the authorization directly from the resource owner the client redirects to an authorization server which in turn redirects back to the client with the authorization code. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client. Implicit Grant - The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly (as the result of the resource owner authorization). The grant type is implicit, as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token). When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be verified via the redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent. 2. Resource Owner Password Credentials – Resource owner password credentials is directly as an authorization grant to get an access token. The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code). You could also use this to get an long lived access token or refresh token. 3. Client Credentials - The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server. Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.
#15 http://nat.sakimura.org/2012/01/20/openid-connect-nutshell/
#16 OpenID Connect extends the OAuth 2.0 authorization protocol to use as an authentication protocol, so that you can perform single sign-on using OAuth. OpenID Connect introduces the concept of an ID token, which is a security token that allows the client to verify the identity of the user. The ID token also gets basic profile information about the user. Because OpenID Connect extends OAuth 2.0, apps can securely acquire access tokens, which can be used to access resources that are secured by an authorization server. We recommend that you use OpenID Connect if you are building a web application that is hosted on a server and accessed via a browser.
#18 A bearer token is a lightweight security token that grants the “bearer” access to a protected resource. In this sense, the “bearer” is any party that can present the token. Though authentication with Azure AD is required in order to receive a bearer token, steps must be taken to secure the token, to prevent interception by an unintended party. Because bearer tokens do not have a built-in mechanism to prevent unauthorized parties from using them, they must be transported in a secure channel such as transport layer security (HTTPS).
#19 Reference here - https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims
#20 Application ID URI: The identifier for an application. This value is sent to Azure AD during authentication to indicate which application the caller wants a token for. Additionally, this value is included in the token so that the application knows it was the intended target. Reply URL and Redirect URI: In the case of a web API or web application, the Reply URL is the location to which Azure AD will send the authentication response, including a token if authentication was successful. In the case of a native application, the Redirect URI is a unique identifier to which Azure AD will redirect the user-agent in an OAuth 2.0 request.
#21 Single tenant application: A single tenant application is intended for use in one organization. These are typically line-of-business (LoB) applications written by an enterprise developer. A single tenant application only needs to be accessed by users in one directory, and as a result, it only needs to be provisioned in one directory. These applications are typically registered by a developer in the organization. Multi-tenant application: A multi-tenant application is intended for use in many organizations, not just one organization. These are typically software-as-a-service (SaaS) applications written by an independent software vendor (ISV). Multi-tenant applications need to be provisioned in each directory where they will be used, which requires user or administrator consent to register them. This consent process starts when an application has been registered in the directory and is given access to the Graph API or perhaps another web API. When a user or administrator from a different organization signs up to use the application, they are presented with a dialog that displays the permissions the application requires. The user or administrator can then consent to the application, which gives the application access to the stated data, and finally registers the application in their directory. For more information, see Overview of the Consent Framework. https://login.microsoftonline.com/common
#22 Five types of application scenarios: From web browser to the web application Single Page application – SPA Apps Native Application to Web API – Native application that runs on a mobile client, phone, tablet etc that needs to authenticate a user to get resources from a web API that is protected using Azure AD. Web Application to Web API that is protected using Azure AD. Daemon or Server application to Web API – with no user experience needs to get resources from the Web API that is secured by Azure AD.
#23 The application validates the token by using a public signing key and issuer information available at the federation metadata document for Azure AD. After the application validates the token, Azure AD starts a new session with the user. This session allows the user to access the application until it expires. SHOW THE DEMO: https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
#24 https://github.com/Azure-Samples/active-directory-angularjs-singlepageapp
#25 https://github.com/Azure-Samples/active-directory-dotnet-native-desktop
#26 https://github.com/Azure-Samples/active-directory-dotnet-webapp-webapi-oauth2-appidentity In this scenario there is a web application that needs to get resources from Web Api. There are two possible way to authenticate in this flow: Application Identity: When using an application identity, the web API can only detect that the web application is calling it, as the web API does not receive any information about the user. – OAuth 2.0 Client Credentials Grant Delegated user identity: This scenario can be accomplished in two ways: OpenID Connect, and OAuth 2.0 authorization code grant with a confidential client. The web application obtains an access token for the user, which proves to the web API that the user successfully authenticated to the web application and that the web application was able to obtain a delegated user identity to call the web API. This access token is sent in the request to the web API, which authorizes the user and returns the desired resource. – Open ID Connect Application Identity – Trusted Sub System https://github.com/Azure-Samples/active-directory-dotnet-webapp-webapi-oauth2-appidentity
#27 A daemon that needs to call a web API, built on OAuth 2.0 client credentials grant type; and a server application (such as a web API) that needs to call a web API, built on OAuth 2.0 On-Behalf-Of draft specification. For the scenario when a daemon application needs to call a web API, it’s important to understand a few things. First, user interaction is not possible with a daemon application, which requires the application to have its own identity. An example of a daemon application is a batch job, or an operating system service running in the background. This type of application requests an access token by using its application identity and presenting its client ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API. For the scenario when a server application needs to call a web API, it’s helpful to use an example. Imagine that a user has authenticated on a native application, and this native application needs to call a web API. Azure AD issues a JWT access token to call the web API. If the web API needs to call another downstream web API, it can use the on-behalf-of flow to delegate the user’s identity and authenticate to the second-tier web API. Talk about Application Identity flow or Client Credentials and also Delegated user identity using Oauth On Behalf Of flow.
#29 You can use the Graph API to create a new user, view or update user’s properties, change user’s password, check group membership for role-based access, disable or delete the user Browse the metadata here - https://graph.windows.net/venknarTest.OnMicrosoft.com/$metadata?api-version=1.6 https://graph.windows.net/venknarTest.OnMicrosoft.com/$metadata?api-version=1.6 Graph Explorer - https://graphexplorer.cloudapp.net/ Show demo with https://graphexplorer.azurewebsites.net/#
#30 Users – CRUD users. You can also query and modify a user's relationships to other directory entities. For example, you can assign the user's manager, query the user's direct reports, manage group memberships, app roles, and devices assigned to the user, and much more. Groups - Graph API, you can create, read, update, and delete groups. You can also query members of a group, add and delete members from a group, check a group's membership in other groups, assign app roles to a group, and much more. Contact - topic discusses how to perform operations on organizational contacts using the Azure Active Directory (AD) Graph API. Organizational contacts typically represent users who are external to your company or organization. Directory Role operations - topic discusses how to perform operations on Azure AD directory roles using the Azure Active Directory (AD) Graph API. Directory roles (DirectoryRole) carry specific sets of rights within the directory. Azure AD grants the users and service principals that are members of a directory role the rights associated with that role. Policy Operations - Policies are custom rules that can be enforced on applications, service principals, groups, or the entire organization they are assigned to. There is currently only one type of policy available. Token Lifetime Policy: specifies the lifetime duration of tokens issued for applications and service principals
#31 Scenarios for ADAL1. Authenticating Users of a Client Application to a Remote Resource 2. Authenticating a Server Application to a Remote Resource 3. Authenticating a Server Application on Behalf of a User to Access a Remote Resource Authentication Context Constructor -> Authority who issues the token AcquireTokenAsync takes the resource for which the token has to be issued.
#32 1. Azure AD Application Proxy helps you support remote workers by publishing on-premises applications to be accessed over the internet. 2. Conditional Access: Require multi-factor authentication per application Require multi-factor authentication only when users are not at work Block users from accessing the application when they are not at work 3. Azure AD connect – Hybrid connectivity simple 4. Azure AD Application Directory - listing of applications that are known to support a form of single sign-on with Azure Active Directory. Azure AD supports automatic provisioning and de-provisioning for all “Featured” apps in the Azure Active Directory Application Gallery. A list of federated applications that specifically support federated single sign-on using a protocol such as SAML, WS-Federation, or OpenID Connect can be found here.

Azure Active Directory - An Introduction

More Related Content

What's hot

More from Venkatesh Narayanan

Recently uploaded

Azure Active Directory - An Introduction

Editor's Notes