зеркало из https://github.com/Azure/fta-identity.git
Moved content to central repo
This commit is contained in:
Jelle Druyts
Родитель
757452c282
Коммит
bdf9202b6e
|
|
@ -1,8 +0,0 @@
|
|||
{
|
||||
"markdownlint.config": {
|
||||
"MD028": false,
|
||||
"MD025": {
|
||||
"front_matter_title": ""
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
# Overview of identity offerings
|
||||
|
||||
> **pre | [home](readme.md) | [next](02-azuread.md)**
|
||||
|
||||
In this section, we sketch the landscape of the various identity offerings and how they relate to each other. Step by step you'll see what each offering does and how it integrates with the other offerings in the landscape.
|
||||
|
||||
We will cover:
|
||||
|
||||
- Azure AD
|
||||
- Azure AD B2B Guest User Access
|
||||
- Azure AD Multi-Tenant Apps
|
||||
- Azure AD B2C
|
||||
|
||||
> **prev | [home](readme.md) | [next](02-azuread.md)**
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
# Azure AD
|
||||
|
||||
> **[prev](01-identity-offerings-overview.md) | [home](readme.md) | [next](03-azuread-authz.md)**
|
||||
|
||||
Azure AD is the central identity control plane for an individual organization. The organizational directory holds all your users and controls how they can sign in (that is, perform _authentication_) - including security and governance features like Conditional Access (CA), Multi-Factor Authentication (MFA), Privileged Access Management (PIM), etc.
|
||||
|
||||
Thousands of applications are natively integrated with Azure AD. This includes first party offerings like Microsoft 365 (SharePoint, Exchange, Teams, ...) and Azure, as well as third party offerings like Salesforce, ServiceNow and Box.
|
||||
|
||||
However, Azure AD is an open Identity Provider (IdP), which means you can also integrate your own line-of-business (LOB) applications with Azure AD and let your organizations' users sign in with their existing credentials (and taking full advantage of the governance features mentioned above). By adopting a fully externalized and cloud-scale platform (rather than a library or locally hosted identity solution), **you are no longer responsible for collecting, storing and securing any credentials for your application's users**.
|
||||
|
||||
|
||||
|
||||
> **DEMO - Azure AD single-tenant apps**
|
||||
>
|
||||
> - In Azure AD, **register a new application**.
|
||||
> - Set the **Supported account types** to **Accounts in this organizational directory only** (single-tenant).
|
||||
> - Set the **Redirect URI** to **[https://authr.biz](https://authr.biz)**.
|
||||
> - Once registered, open the **Authentication** page and under **Implicit grant and hybrid flows**, make sure to allow **ID tokens** to be issued by the authorization endpoint.
|
||||
> - In a separate tab, go to **[https://authr.biz](https://authr.biz)** which is a web app to easily test various authentication and authorization scenarios.
|
||||
> - To see the end user sign-in experience of the app you just registered, use this **[direct link](https://authr.biz/?requesttype=OpenIdConnect&scope=openid+profile&responsetype=id_token&responsemode=form_post&additionalparameters=prompt%3dlogin&importtype=AzureAD&tenant=microsoft.onmicrosoft.com&clientid=your-client-id)** and replace the **Client ID** on the form with the correct **Application (client) ID** value from the app registration and ensure to use the right tenant.
|
||||
> - Alternatively, configure the flow manually:
|
||||
> - Set the **Protocol Flow** to **OpenID Connect**.
|
||||
> - Click the **Import** button, select Azure AD, enter `microsoft.com` as the tenant (or use your own) and click **Import** to generate the right endpoints.
|
||||
> - Set the **Client ID** to the correct value from the app registration.
|
||||
> - Optionally, set the **Scope** to `openid profile` (by including `profile`, the token will include more information about the user).
|
||||
> - Optionally, if you want to *force* a login rather than using SSO, set **Additional Parameters** to `prompt=login`.
|
||||
> - Click **Submit** to execute a standard sign-in flow for the single-tenant Azure AD application you just registered.
|
||||
> - After the successful sign-in, the application shows the ID token that was issued by the directory, containing relevant claims about the signed-in user.
|
||||
|
||||
> **[prev](01-identity-offerings-overview.md) | [home](readme.md) | [next](03-azuread-authz.md)**
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
# Azure AD - Authorization
|
||||
|
||||
> **[prev](02-azuread.md) | [home](readme.md) | [next](04-azuread-b2b.md)**
|
||||
|
||||
By using authorization features like [directory groups](https://docs.microsoft.com/azure/active-directory/fundamentals/active-directory-manage-groups), [app roles](https://docs.microsoft.com/azure/architecture/multitenant-identity/app-roles) and other types of Role Based Access Control (for example, Azure RBAC), you can define exactly who has access to which applications and with which permissions.
|
||||
|
||||
> **DEMO - Authorization with App Roles**
|
||||
>
|
||||
> - On the Azure AD app registration, open the **App roles** page and create a new app role. For example, set the **Display name** to `Expense Approvers`, **Allowed member types** to **Users/Groups**, **Value** to `Expenses.Approve` and **Description** to `Can approve expenses`.
|
||||
> - Back on the **Overview** page, click through to the **Managed application in local directory** (or navigate to the **Enterprise applications** page in Azure AD and find the app), go to the **Users and groups** page and assign the user that you've signed in with to the app role you just created.
|
||||
> - Go back to **Authr**, go to **New Request** (which keeps all existing parameters) and click **Submit** again. You should now see a `roles` claim in the token containing the app role assigned to the user and which the application can use for authorization purposes.
|
||||
|
||||
> **[prev](02-azuread.md) | [home](readme.md) | [next](04-azuread-b2b.md)**
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
# Azure AD B2B Guest User Access
|
||||
|
||||
> **[prev](03-azuread-authz.md) | [home](readme.md) | [next](05-azuread-multitenant.md)**
|
||||
|
||||
Allowing your own users to access these applications is great, but often you'll want to collaborate with external users as well. For example, you may want to grant a consultant access to your Azure subscriptions, or collaborate with a business partner by sharing files in a SharePoint library.
|
||||
|
||||
Rather than creating "fake" user accounts for those users in your own directory (and thereby making yourself responsible for managing the credentials and the user lifecycle of these external users), you can use Azure AD B2B features to invite them as guests into your own directory. This means a "shadow" account (indicated with a dotted box in the diagram) is created in your directory, but it will not hold any credentials. As a result, these **guest users still *authenticate* in their home directory (where their own policies like MFA are still applied), but you control *authorization* to your apps in your own directory**.
|
||||
|
||||
|
||||
|
||||
Typically, you don't need to do anything special in your own applications to work with [B2B guest users](https://docs.microsoft.com/azure/active-directory/external-identities/user-properties). If you want to know whether a user is a direct member or a guest, you can see this in the directory where the `UserType` property will be set to `Guest`.
|
||||
|
||||
Note that B2B guest user invitations work for any external IdP that supports [SAML or WS-Federation](https://docs.microsoft.com/azure/active-directory/external-identities/direct-federation), as well as Google, Facebook, Microsoft Accounts or (as an escape-hatch) any email address using [Email OTP](https://docs.microsoft.com/azure/active-directory/external-identities/one-time-passcode).
|
||||
|
||||
> **DEMO - Azure AD B2B guest users**
|
||||
>
|
||||
> - In Azure AD, **invite a new guest user**. You can invite a personal email address to the directory for example to see what the user experience looks like. Open the email that you should have received and accept the invitation.
|
||||
> - Go back through the exact same flow in **[Authr](https://authr.biz)** as before but now sign in with the guest user account (especially here it can be useful to set **Additional Parameters** to `prompt=login` to avoid SSO with your main account).
|
||||
> - **Inspect the ID token** and note that there are a few differences for guest users; for example that the issuer (`iss`) claim is different from the identity provider (`idp`) claim: the first one reflecting the directory where the app was registered and where the token was issued from, the second one being the (external) service which authenticated the user.
|
||||
> - Note that the same features as before (like groups or app roles) also work fine with B2B guest users.
|
||||
|
||||
> **[prev](03-azuread-authz.md) | [home](readme.md) | [next](05-azuread-multitenant.md)**
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# Azure AD Multi-Tenant Apps
|
||||
|
||||
> **[prev](04-azuread-b2b.md) | [home](readme.md) | [next](06-azuread-b2c.md)**
|
||||
|
||||
If your app isn't a traditional LOB app intended for a single organization (optionally including any guest users in that organization's directory), but rather an app that can be used directly by many organizations, or even a **Software-as-a-Service (SaaS) app for which you want to maximize the reach to the millions of organizations using Azure AD**, you can register it as a [multi-tenant app in Azure AD](https://docs.microsoft.com/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant). Depending on your configuration, this can even include personal Microsoft accounts that are used to sign in to services like Xbox and Skype.
|
||||
|
||||
|
||||
|
||||
Your app can still use the same authorization features like groups and roles, and each organization using your app can manage its permissions separately because of the [distinction](https://docs.microsoft.com/azure/active-directory/develop/app-objects-and-service-principals) between the *app registration* (the central "blueprint" of the app definition as configured in *your* directory) and the *service principal* (the "instance" of the app in the *customer's* directory) on which permissions are defined.
|
||||
|
||||
> **DEMO - Azure AD multi-tenant apps**
|
||||
>
|
||||
> - In Azure AD, go back to the **Authentication** page of the app registration and change the **Supported account types** to **Accounts in any organizational directory** (multi-tenant).
|
||||
> - Go back to **[Authr](https://authr.biz)** with this **[direct link](https://authr.biz/?requesttype=OpenIdConnect&scope=openid+profile&responsetype=id_token&responsemode=form_post&additionalparameters=prompt%3dlogin&importtype=AzureAD&tenant=common&clientid=your-client-id)** (again, make sure to replace the **Client ID** and tenant) or continue with the last request parameters but replace the tenant name in the Identity Service endpoints with `common` (for example, `https://login.microsoftonline.com/common/oauth2/v2.0/authorize`).
|
||||
> - **Perform a new authentication** and note that you are now able to log in with *any* account in *any* directory.
|
||||
|
||||
> **[prev](04-azuread-b2b.md) | [home](readme.md) | [next](06-azuread-b2c.md)**
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
# Azure AD B2C
|
||||
|
||||
> **[prev](05-azuread-multitenant.md) | [home](readme.md) | [next](07-azuread-b2c-social.md)**
|
||||
|
||||
The offerings discussed up to now have all been anchored on Azure AD, which targets organizations and provides collaboration features between them. If your app is intended to be used by external users not necessarily defined in Azure AD, but instead targets **individual consumers, customers or citizens**, you can use Azure AD B2C. This is internally still built upon the global cloud-scale Azure AD platform but enables unique features to provide your apps with Customer Identity Access Management (CIAM) capabilities.
|
||||
|
||||
Azure AD B2C is a logically separate environment, allowing you to keep your consumer users separated from your organizational directory. Your apps integrate with Azure AD B2C through user journeys ("user flows" or "policies") that can be fully customized to fit with your app or company branding. Different apps can use different policies for various reasons, and a single app can even use multiple policies for scenarios like sign-up or sign-in, profile editing, password reset, progressive user profiling, etc.
|
||||
|
||||
|
||||
|
||||
> **[prev](05-azuread-multitenant.md) | [home](readme.md) | [next](07-azuread-b2c-social.md)**
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
# Azure AD B2C - Social Identities
|
||||
|
||||
> **[prev](06-azuread-b2c.md) | [home](readme.md) | [next](08-azuread-b2c-enterprise.md)**
|
||||
|
||||
By default, consumer users can create an account within the directory itself (commonly referred to as "local accounts"). However, you can also **allow users to sign in with an identity they already have from social providers** such as Facebook, Google, Microsoft, and *many* others supported natively by Azure AD B2C.
|
||||
|
||||
Somewhat similar to B2B guest users, this means a "shadow" account is created in the directory so that authentication happens with the social provider, but the directory doesn't hold the user's credentials and your app doesn't need be aware of all the possible providers that are added - it only asks the directory to authenticate users through a certain policy which is managed outside of the app itself.
|
||||
|
||||
|
||||
|
||||
> **[prev](06-azuread-b2c.md) | [home](readme.md) | [next](08-azuread-b2c-enterprise.md)**
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
# Azure AD B2C - Enterprise Identities
|
||||
|
||||
> **[prev](07-azuread-b2c-social.md) | [home](readme.md) | [next](09-azuread-b2c-azuread.md)**
|
||||
|
||||
In certain cases, you may also want to **allow users from external organizations** to sign in. This can be done by setting up federation towards an enterprise Identity Provider such as AD FS, Salesforce, or any IdP which supports OAuth, OpenID Connect or SAML. This can be useful for B2B-type scenarios where your business partners may not have Azure AD themselves or where the Azure AD B2B guest user access features aren't suitable.
|
||||
|
||||
|
||||
|
||||
> **[prev](07-azuread-b2c-social.md) | [home](readme.md) | [next](09-azuread-b2c-azuread.md)**
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
# Azure AD B2C - Azure AD Identities
|
||||
|
||||
> **[prev](08-azuread-b2c-enterprise.md) | [home](readme.md) | [next](10-identity-offerings-choice.md)**
|
||||
|
||||
As a special case of the previous federation option, it's quite common that your consumer facing app may want to **allow users *from your own organization* to sign in** (for example, for administration tasks within the app itself). This can be easily achieved by [setting up federation towards your Azure AD tenant](https://docs.microsoft.com/azure/active-directory-b2c/identity-provider-azure-ad-single-tenant).
|
||||
|
||||
|
||||
|
||||
Similarly, you may want to **allow access to your app to *all (or multiple) Azure AD organizations***, in which case you can set up [federation towards multi-tenant Azure AD](https://docs.microsoft.com/azure/active-directory-b2c/identity-provider-azure-ad-multi-tenant) as well.
|
||||
|
||||
|
||||
|
||||
> **[prev](08-azuread-b2c-enterprise.md) | [home](readme.md) | [next](10-identity-offerings-choice.md)**
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
# Choosing the appropriate offering
|
||||
|
||||
> **[prev](09-azuread-b2c-azuread.md) | [home](readme.md) | [next](11-external-identities-scenario.md)**
|
||||
|
||||
The choice between the various flavors of Azure AD mostly comes down to which types of external identities you want to allow, and what kind of app you are building. The official documentation has good [comparison information between Azure AD B2B and B2C as well as a note on multi-tenant applications](https://docs.microsoft.com/azure/active-directory/external-identities/compare-with-b2c), but to help decide we've also published guidance in the form of an [external identities decision tree](https://github.com/Azure/fta-identity/blob/master/identity-applications/aad-external-identities-decision-tree.md).
|
||||
|
||||
|
||||
|
||||
> **DEMO - External Identities Decision Tree**
|
||||
>
|
||||
> - Walk through the content and main decision criteria on the [Azure AD External Identities Decision Tree](https://github.com/Azure/fta-identity/blob/master/identity-applications/aad-external-identities-decision-tree.md) page.
|
||||
|
||||
> **[prev](09-azuread-b2c-azuread.md) | [home](readme.md) | [next](11-external-identities-scenario.md)**
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
# Real-world scenario with external identities
|
||||
|
||||
> **[prev](10-identity-offerings-choice.md) | [home](readme.md) | [next](12-ciam-b2c.md)**
|
||||
|
||||
If possible, an application should only have to trust a single Identity Provider so that the complexity of authentication and authorization is externalized and the required configuration in the application remains relatively simple. However, real-world use cases may involve multiple integrations where Azure AD is used for the organization's own employees, B2B guest users in the same directory are used for business partners, Azure AD B2C with local or social accounts are used for end customers, and the same Azure AD B2C with enterprise federation is used for business customers.
|
||||
|
||||
> **DEMO - Woodgrove External Identities**
|
||||
>
|
||||
> - Open the **[Woodgrove CIAM demo](https://aka.ms/CIAMDemo)** web application. Optionally, use the [configuration page](https://aka.ms/CIAMDemoConfig) to change the industry or other options.
|
||||
> - Go to the **Sign In** page and note the various ways this application is able to sign in users:
|
||||
> - **Individual customers**: This uses Azure AD B2C for a fully branded experience that looks like an integral part of the web app; depending on [configuration](https://aka.ms/CIAMDemoConfig) users can sign in with "local" (using an email address or phone number) or "social" accounts.
|
||||
> - **Business customers**: This still uses Azure AD B2C (as it is for *end customers that happen to belong to an organization*) which is set up with federation towards multi-tenant Azure AD; this allows business customers to sign in with their existing work account.
|
||||
> - **Partners**: This uses the Woodgrove organizational Azure AD directory (not the Azure AD B2C directory used above) to allow Woodgrove employees to sign in, as well as collaboration partners to sign up and sign in using Azure AD B2B guest user access.
|
||||
> - **Open the sign-up or sign-in experience for each of these options**, but there's no need to actually go through it fully. The point is that a single web app can have a range of options for end users to sign up and/or in, and these can all be delivered through Azure AD and Azure AD B2C.
|
||||
|
||||
> **[prev](10-identity-offerings-choice.md) | [home](readme.md) | [next](12-ciam-b2c.md)**
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
# Customer Identity Access Management with Azure AD B2C
|
||||
|
||||
> **[prev](11-external-identities-scenario.md) | [home](readme.md) | next**
|
||||
|
||||
Since most people will likely be at least somewhat familiar with Azure AD, let's focus a bit more on Azure AD B2C specifically. An Azure AD B2C directory is completely separate from your organizational Azure AD directory (but built on the same underlying global platform). There are several high-level concepts that are important in an Azure AD B2C deployment, as you can see in the most important pages in the Azure Portal experience:
|
||||
|
||||
- **App registrations**: Similar to Azure AD, you have to register your applications in order for the directory to issue tokens to them.
|
||||
- **Identity providers**: You can select which external IdP's a user can sign in with (social and enterprise identities) and which authentication methods can be used for "local" accounts (username, email or phone number).
|
||||
- **User attributes**: You can define additional information about users that you want to store within the directory itself; note that B2C isn't intended to be used as a CRM system but can store important identity-related information which users can be allowed to modify (through a profile editing policy).
|
||||
- **User flows**: Azure AD B2C provides pre-built policies called *user flows* which allow you to easily configure sign-up, sign-in, profile editing and password reset capabilities.
|
||||
- **API Connectors**: Built-in user flows expose certain extensibility points which allow you to inject custom logic as a REST API call.
|
||||
- **Identity Experience Framework**: When the built-in user flows don't do exactly what you need, you can create *custom policies* which puts you in complete control of the user journey.
|
||||
|
||||
> **DEMO - Azure AD B2C**
|
||||
>
|
||||
> - Navigate to your Azure AD B2C directory in the Azure Portal and **walk through the top-level pages** mentioned above (feel free to skip API Connectors and Identity Experience Framework though as these are more advanced).
|
||||
> - Create a **new combined sign-up and sign-in user flow**.
|
||||
> - Open the **Properties** page where you can easily enable Multi-Factor Authentication (and even Conditional Access).
|
||||
> - Open the **Identity providers** page where you can configure different user flows with different IdP's, for example to allow social identities for some scenarios but not for others.
|
||||
> - Open the **User attributes** page where you define which information is captured from a user during sign-up.
|
||||
> - Open the **Application claims** page where you select the attributes that will be emitted into the token that gets sent towards the application.
|
||||
> - Open the **Page layouts** page where you can completely customize the HTML, CSS and JavaScript for each page.
|
||||
> - Click **Run user flow** to easily try out any changes to the user flow directly from the Azure Portal, even without building any application (for example, by using [https://jwt.ms](https://jwt.ms) or [https://authr.biz](https://authr.biz) so that you see the claims issued in the token).
|
||||
|
||||
In real-world scenarios there are likely requirements that cannot be met with out-of-the-box functionality in Azure AD B2C, which is why it's important to know that there are a few levels of customization such as *HTML, CSS and JavaScript* to customize what happens on the actual pages hosted by Azure AD B2C, *API Connectors* to call external REST API's to influence user flows, and finally *custom policies* to take full control (at the cost of considerable complexity).
|
||||
|
||||
- One very common requirement is to **allow only pre-identified users to sign up**, which is demonstrated in the [Delegated User Management sample](https://github.com/azure-ad-b2c/api-connector-samples/tree/main/InvitationCodeDelegatedUserManagement).
|
||||
- Another typical scenario (as it's built-in with Azure AD but not in Azure AD B2C) is to use B2C not only for authentication but also for **authorization**, which is demonstrated in the [App Roles sample](https://github.com/azure-ad-b2c/api-connector-samples/tree/main/Authorization-AppRoles) (with extensive guidance on alternative approaches).
|
||||
- Finally, it's worth calling out that there is a large collection of **[custom policy samples](https://github.com/azure-ad-b2c/samples)** which covers many other requirements that real-world implementations may require.
|
||||
|
||||
> **[prev](11-external-identities-scenario.md) | [home](readme.md) | next**
|
||||
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 113 KiB |
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 236 KiB |
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 299 KiB |
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 467 KiB |
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 581 KiB |
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 660 KiB |
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 697 KiB |
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 738 KiB |
|
|
@ -1,74 +1,3 @@
|
|||
# Microsoft Identity Platform
|
||||
|
||||
## Overview
|
||||
|
||||
In this session you will learn about the different offerings available in the Microsoft Identity Platform to help you integrate your solutions with a modern cloud-scale identity platform. We will discuss **Azure AD** (for both single-tenant and multi-tenant apps), **Azure AD B2B** for guest user access and **Azure AD B2C** for Customer Identity Access Management (CIAM). We will discuss how they are similar, where they are different, and when to choose which.
|
||||
|
||||
### Agenda
|
||||
|
||||
- [Overview of identity offerings](01-identity-offerings-overview.md)
|
||||
- [Azure AD](02-azuread.md)
|
||||
- [Azure AD B2B Guest User Access](04-azuread-b2b.md)
|
||||
- [Azure AD Multi-Tenant Apps](05-azuread-multitenant.md)
|
||||
- [Azure AD B2C](06-azuread-b2c.md)
|
||||
- [Choosing the appropriate offering](10-identity-offerings-choice.md)
|
||||
- [Real-world scenario with external identities](11-external-identities-scenario.md)
|
||||
- [Customer Identity Access Management with Azure AD B2C](12-ciam-b2c.md)
|
||||
|
||||
### Audience
|
||||
|
||||
This session is mostly useful for identity architects and developers who want to integrate their solutions with the Microsoft Identity Platform to allow organizational users as well as external identities to sign in to their custom developed applications.
|
||||
|
||||
### Goals
|
||||
|
||||
In this session you will learn how to:
|
||||
|
||||
- Compare the different identity offerings.
|
||||
- Choose which identity offering is most appropriate for your requirements.
|
||||
- Integrate your applications with Azure AD and Azure AD B2C.
|
||||
|
||||
## Resources
|
||||
|
||||
Please find the most relevant resources below to continue your learning after this session.
|
||||
|
||||
### Help Me Choose
|
||||
|
||||
- [What is Azure Active Directory?](https://docs.microsoft.com/azure/active-directory/fundamentals/active-directory-whatis)
|
||||
- [What are External Identities in Azure Active Directory?](https://docs.microsoft.com/azure/active-directory/external-identities/compare-with-b2c)
|
||||
- [What is guest user access in Azure Active Directory B2B?](https://docs.microsoft.com/azure/active-directory/external-identities/what-is-b2b)
|
||||
- [What is Azure Active Directory B2C?](https://docs.microsoft.com/azure/active-directory-b2c/active-directory-b2c-overview)
|
||||
- [Azure Active Directory External Identities Decision Tree](https://github.com/Azure/fta-identity/blob/master/identity-applications/aad-external-identities-decision-tree.md)
|
||||
- [Azure Active Directory pricing](https://azure.microsoft.com/pricing/details/active-directory/)
|
||||
- [Azure Active Directory External Identities pricing](https://azure.microsoft.com/pricing/details/active-directory/external-identities/)
|
||||
- [Compare self-managed Active Directory Domain Services, Azure Active Directory, and managed Azure Active Directory Domain Services](https://docs.microsoft.com/azure/active-directory-domain-services/compare-identity-solutions)
|
||||
|
||||
### Help Me Architect
|
||||
|
||||
Azure AD:
|
||||
|
||||
- [What is the Microsoft identity platform?](https://docs.microsoft.com/azure/active-directory/develop/v2-overview)
|
||||
- [Tenancy in Azure Active Directory](https://docs.microsoft.com/azure/active-directory/develop/single-and-multi-tenant-apps)
|
||||
- [Enhance security with the principle of least privilege](https://docs.microsoft.com/azure/active-directory/develop/secure-least-privileged-access)
|
||||
- [Azure AD App Roles](https://docs.microsoft.com/azure/architecture/multitenant-identity/app-roles)
|
||||
- [Building resilience into identity and access management with Azure Active Directory](https://aka.ms/AzureADresilience)
|
||||
- [Security Controls: Identity Management](https://docs.microsoft.com/security/benchmark/azure/security-controls-v2-identity-management)
|
||||
|
||||
Azure AD multi-tenant applications:
|
||||
|
||||
- [Sign in any Azure Active Directory user using the multi-tenant application pattern](https://docs.microsoft.com/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant)
|
||||
- [Identity management in multi-tenant applications](https://docs.microsoft.com/azure/architecture/multitenant-identity/)
|
||||
|
||||
Azure AD B2C:
|
||||
|
||||
- [Woodgrove Groceries demo environment](https://aka.ms/CIAMDemo)
|
||||
- [Sample custom policies](https://github.com/azure-ad-b2c/samples)
|
||||
- [Sample API connectors](https://github.com/azure-ad-b2c/api-connector-samples)
|
||||
- [Authorization in Azure AD B2C](https://github.com/azure-ad-b2c/api-connector-samples/tree/main/Authorization-AppRoles)
|
||||
- [Solutions and Training for Azure Active Directory B2C](https://aka.ms/aadb2csolutions)
|
||||
|
||||
### Help Me Deploy
|
||||
|
||||
- [Microsoft identity platform code samples](https://docs.microsoft.com/azure/active-directory/develop/sample-v2-code)
|
||||
- [Microsoft identity platform best practices and recommendations](https://docs.microsoft.com/azure/active-directory/develop/identity-platform-integration-checklist)
|
||||
- [Azure AD application registration security best practices](https://docs.microsoft.com/azure/active-directory/develop/security-best-practices-for-app-registration)
|
||||
- [Graph API for Azure AD](https://docs.microsoft.com/graph/azuread-identity-access-management-concept-overview)
|
||||
Content has moved to [https://aka.ms/ftalive-identity](https://aka.ms/ftalive-identity). Please update your bookmarks!
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче