From a4dc1875684cad180995d1d0fabef3d96ee0b160 Mon Sep 17 00:00:00 2001 From: Alex Buck Date: Wed, 15 Nov 2023 16:43:15 -0500 Subject: [PATCH] [BULK] - DocuTune - Rebranding of Azure Active Dir --- msal-python-conceptual/TOC.yml | 4 ++-- msal-python-conceptual/advanced/aad-b2c.md | 6 +++--- msal-python-conceptual/advanced/best-practices.md | 2 +- msal-python-conceptual/advanced/client-capabilities.md | 10 +++++----- msal-python-conceptual/advanced/client-credentials.md | 6 +++--- .../advanced/migrate-python-adal-msal.md | 4 ++-- .../advanced/msal-error-handling-python.md | 2 +- .../advanced/msal-python-adfs-support.md | 8 ++++---- .../advanced/username-password-authentication.md | 4 ++-- .../getting-started/acquiring-tokens.md | 4 ++-- .../getting-started/client-applications.md | 4 ++-- msal-python-conceptual/index.md | 6 +++--- 12 files changed, 30 insertions(+), 30 deletions(-) diff --git a/msal-python-conceptual/TOC.yml b/msal-python-conceptual/TOC.yml index ac36c72..387a658 100644 --- a/msal-python-conceptual/TOC.yml +++ b/msal-python-conceptual/TOC.yml @@ -1,7 +1,7 @@ - name: Getting started href: index.md items: - - name: Register your app with Azure AD + - name: Register your app with Microsoft Entra ID href: /azure/active-directory/develop/active-directory-integrating-applications - name: Client applications href: getting-started/client-applications.md @@ -45,7 +45,7 @@ items: - name: Releases href: https://github.com/AzureAD/microsoft-authentication-library-for-python/releases - - name: Azure AD Developer Guide + - name: Microsoft Entra Developer Guide href: https://aka.ms/aaddevv2 - name: Code samples href: /azure/active-directory/develop/sample-v2-code diff --git a/msal-python-conceptual/advanced/aad-b2c.md b/msal-python-conceptual/advanced/aad-b2c.md index 630d995..85be5c9 100644 --- a/msal-python-conceptual/advanced/aad-b2c.md +++ b/msal-python-conceptual/advanced/aad-b2c.md @@ -9,7 +9,7 @@ description: "You can use MSAL Python to sign-in users with social identities, a You can use MSAL Python to sign-in users with social identities, acquire tokens, and customize the sign-in experience by using [Azure AD B2C](https://aka.ms/aadb2c). -AAD B2C is built around the notion of [User Flows](/azure/active-directory-b2c/active-directory-b2c-reference-policies) (formerly known as policies). In MSAL Python, specifying a user flow translates to providing an authority. +Azure AD B2C is built around the notion of [User Flows](/azure/active-directory-b2c/active-directory-b2c-reference-policies) (formerly known as policies). In MSAL Python, specifying a user flow translates to providing an authority. * When you instantiate the client application, you need to specify the user flow in authority as `https://{tenant_name}.b2clogin.com/{tenant_name}.onmicrosoft.com/{user_flow}`. @@ -62,7 +62,7 @@ app.acquire_token_by_xyz(...) # Same as in non-B2C scenarios > There is no need to filter accounts by user flow, as long as you are following a pattern of -"create different msal app for different user flow" +"create different MSAL app for different user flow" (because the B2C user flow is designed to behave like an isolated authority). In practice, you will still typically reuse same MSAL app and its token cache for the SignIn user flow, and only create new one-time MSAL app when invoking EditProfile or ResetPassword user flows, @@ -97,7 +97,7 @@ The following content serves as a mini-tutorial. * In your AzureAD B2C tenant, create a new user flow and select **Sign in using ROPC**. This will enable the ROPC user flow for your tenant. See [Configure the resource owner password credentials flow](/azure/active-directory-b2c/configure-ropc) for more details. -* Once you create the msal instance with the authority which contains the ROPC user flow, +* Once you create the MSAL instance with the authority which contains the ROPC user flow, the [`acquire_token_by_username_password(...)`](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.acquire_token_by_username_password) would work as usual. * Limitations: This **only works for local accounts** (where you register with B2C using an email or username). This flow does not work if federating to any of the IdPs supported by B2C (Facebook, Google, etc...). diff --git a/msal-python-conceptual/advanced/best-practices.md b/msal-python-conceptual/advanced/best-practices.md index f9c7ab1..980d68b 100644 --- a/msal-python-conceptual/advanced/best-practices.md +++ b/msal-python-conceptual/advanced/best-practices.md @@ -9,6 +9,6 @@ You've seen that with MSAL Python you can quite simply acquire a token for a pro However, to build robust, enterprise ready applications, you will need to do a bit more. For instance you'll want to: -* [Handle exceptions](/azure/active-directory/develop/msal-handling-exceptions?tabs=python), both when you acquire a token, but also when you call the protected Web API. In particular, if your application runs in an Azure AD tenant where the tenant admins have set [Conditional Access](https://github.com/AzureAD/microsoft-authentication-library-for-python/wiki/Conditional-Access-and-Claims-Challenges) policies to enforce Multiple Factor Authentication (MFA), you will need to handle a Claim challenge. +* [Handle exceptions](/azure/active-directory/develop/msal-handling-exceptions?tabs=python), both when you acquire a token, but also when you call the protected Web API. In particular, if your application runs in a Microsoft Entra tenant where the tenant admins have set [Conditional Access](https://github.com/AzureAD/microsoft-authentication-library-for-python/wiki/Conditional-Access-and-Claims-Challenges) policies to enforce Multiple Factor Authentication (MFA), you will need to handle a Claim challenge. * You might want to enable [Logging](/azure/active-directory/develop/msal-logging?tabs=python) to troubleshoot your application and help your users, while respecting their privacy and being compliant with GDPR. diff --git a/msal-python-conceptual/advanced/client-capabilities.md b/msal-python-conceptual/advanced/client-capabilities.md index 6b39096..9d0b6f2 100644 --- a/msal-python-conceptual/advanced/client-capabilities.md +++ b/msal-python-conceptual/advanced/client-capabilities.md @@ -1,15 +1,15 @@ --- title: Client capabilities -description: "The Azure AD service provides features and policies which are applicable in certain scenarios, such as conditional access policies." +description: "The Microsoft Entra service provides features and policies which are applicable in certain scenarios, such as conditional access policies." --- # Client capabilities -The Azure AD service provides features and policies which are applicable in certain scenarios, such as [conditional access](./conditional-access.md) policies. The Azure AD service needs to determine if a client application is participating in the feature or capable of handling the policy, for the end to end scenario to work. +The Microsoft Entra service provides features and policies which are applicable in certain scenarios, such as [conditional access](./conditional-access.md) policies. The Microsoft Entra service needs to determine if a client application is participating in the feature or capable of handling the policy, for the end to end scenario to work. -- The **client capabilities** parameter in the application object allows client applications to indicate their compliance with a scenario and readiness to handle the policies or features, so that Azure AD can apply them for the client. +- The **client capabilities** parameter in the application object allows client applications to indicate their compliance with a scenario and readiness to handle the policies or features, so that Microsoft Entra ID can apply them for the client. - For example, in the context of conditional access scenario, adding client capability `CP1` will mean that the client is capable of handling a `claims challenge` from the resource provider(ex: MS Graph). Thus, Azure AD STS (Security token service) will emit claims in the access token that may lead to claims challenge from a resource provider (ex: MS Graph). + For example, in the context of conditional access scenario, adding client capability `CP1` will mean that the client is capable of handling a `claims challenge` from the resource provider(ex: MS Graph). Thus, Microsoft Entra STS (Security token service) will emit claims in the access token that may lead to claims challenge from a resource provider (ex: MS Graph). - These capabilities are set when creating the application object using the `client_capabilities` parameter which is a list of client capability strings. @@ -17,6 +17,6 @@ The Azure AD service provides features and policies which are applicable in cert app = msal.PublicClientApplication(client_id="client_id", authority="your_authority", client_capabilities = ["CP1"]) ``` -- Once these are set at the application level, they will be sent in all the requests to the Azure AD authorize and token endpoints. +- Once these are set at the application level, they will be sent in all the requests to the Microsoft Entra authorize and token endpoints. - When setting a capability, the client application should make sure that the policy or feature is handled in the application. - In the above example, when such a capability(`CP1`) is set on the application object, the client application should make sure that a claims challenge from the resource provider(ex: MS Graph) is handled in the application. You can read more details about it in [handling the claims challenge ](./conditional-access.md#handling-claim-challenge-in-msal-python). diff --git a/msal-python-conceptual/advanced/client-credentials.md b/msal-python-conceptual/advanced/client-credentials.md index 6f10099..f88100f 100644 --- a/msal-python-conceptual/advanced/client-credentials.md +++ b/msal-python-conceptual/advanced/client-credentials.md @@ -12,7 +12,7 @@ There are two types of client credentials in MSAL Python: ## Client Credentials with application secret -During the registration of a confidential client application with Azure AD, a client secret is generated (a kind of application password). +During the registration of a confidential client application with Microsoft Entra ID, a client secret is generated (a kind of application password). ### Registering client secrets using the application registration portal @@ -20,7 +20,7 @@ The management of client credentials happens in the **certificates & secrets** p ![image](https://user-images.githubusercontent.com/13203188/49435190-4f385300-f7b6-11e8-8a83-7e468e5fd124.png) -- the application secret (also named client secret) is generated by Azure AD during the registration of the confidential client application when you select **New client secret**. At that point, you must copy the secret string in the clipboard for use in your app, before selecting **Save**. This string won't be presented to you again in the future. +- the application secret (also named client secret) is generated by Microsoft Entra ID during the registration of the confidential client application when you select **New client secret**. At that point, you must copy the secret string in the clipboard for use in your app, before selecting **Save**. This string won't be presented to you again in the future. ### Using client secrets @@ -28,7 +28,7 @@ In MSAL Python client credentials are similar to what they are in ADAL Python, e ## Client Credentials with certificate -When the application is registered with Azure AD, it uploads the public key of a certificate. At application construction, `thumbprint` and `private_key_file` is passed as the client credential. When it wants to acquire a token, the client application will need to call the `acquire_token_for_client` method by passing the scope as parameter. +When the application is registered with Microsoft Entra ID, it uploads the public key of a certificate. At application construction, `thumbprint` and `private_key_file` is passed as the client credential. When it wants to acquire a token, the client application will need to call the `acquire_token_for_client` method by passing the scope as parameter. Steps to generate certificate and private key to be used when implementing the client credential flow are as follows: diff --git a/msal-python-conceptual/advanced/migrate-python-adal-msal.md b/msal-python-conceptual/advanced/migrate-python-adal-msal.md index 61f1d02..a9822f7 100644 --- a/msal-python-conceptual/advanced/migrate-python-adal-msal.md +++ b/msal-python-conceptual/advanced/migrate-python-adal-msal.md @@ -15,7 +15,7 @@ ADAL works with the Azure Active Directory (Azure AD) v1.0 endpoint. The Microso Supports: -- Work and school accounts (Azure AD provisioned accounts) +- Work and school accounts (Microsoft Entra ID provisioned accounts) - Personal accounts (such as Outlook.com or Hotmail.com) - Your customers who bring their own email or social identity (such as LinkedIn, Facebook, Google) via the Azure AD B2C offering @@ -105,4 +105,4 @@ for old_rt, scopes in get_preexisting_rt_and_their_scopes_from_elsewhere(): print("Discarding unsuccessful RT. Error: ", json.dumps(result, indent=2)) print("Migration completed") -``` \ No newline at end of file +``` diff --git a/msal-python-conceptual/advanced/msal-error-handling-python.md b/msal-python-conceptual/advanced/msal-error-handling-python.md index 18fbaaa..ff1cfe8 100644 --- a/msal-python-conceptual/advanced/msal-error-handling-python.md +++ b/msal-python-conceptual/advanced/msal-error-handling-python.md @@ -50,7 +50,7 @@ In certain cases when calling an API requiring Conditional Access, you can recei ## Retrying after errors and exceptions -MSAL makes HTTP calls to the Azure AD service, and occasionally failures can occur. +MSAL makes HTTP calls to the Microsoft Entra service, and occasionally failures can occur. For example the network can go down or the server is overloaded. MSAL Python 1.11+ automatically performs one retry attempt for you. diff --git a/msal-python-conceptual/advanced/msal-python-adfs-support.md b/msal-python-conceptual/advanced/msal-python-adfs-support.md index 87b7c58..1a12f9f 100644 --- a/msal-python-conceptual/advanced/msal-python-adfs-support.md +++ b/msal-python-conceptual/advanced/msal-python-adfs-support.md @@ -9,7 +9,7 @@ Active Directory Federation Services (AD FS) in Windows Server enables you to ad There are usually two ways of authenticating against AD FS: -- MSAL Python talks to Azure Active Directory, which itself is federated with other identity providers. The federation happens through AD FS. MSAL Python connects to Azure AD, which signs in users that are managed in Azure AD (managed users) or users managed by another identity provider such as AD FS (federated users). MSAL Python doesn't know that a user is federated. It simply talks to Azure AD. The [authority](/azure/active-directory/develop/msal-client-application-configuration#authority) you use in this case is the usual authority (authority host name + tenant, common, or organizations). +- MSAL Python talks to Microsoft Entra ID, which itself is federated with other identity providers. The federation happens through AD FS. MSAL Python connects to Microsoft Entra ID, which signs in users that are managed in Microsoft Entra ID (managed users) or users managed by another identity provider such as AD FS (federated users). MSAL Python doesn't know that a user is federated. It simply talks to Microsoft Entra ID. The [authority](/azure/active-directory/develop/msal-client-application-configuration#authority) you use in this case is the usual authority (authority host name + tenant, common, or organizations). - MSAL Python talks directly to an AD FS authority. This is only supported by AD FS 2019 and later. ## Connect to Active Directory federated with AD FS @@ -21,7 +21,7 @@ The following applies whether you connect directly to Active Directory Federatio When you call `acquire_token_by_authorization_code` or `acquire_token_by_device_flow`, the user experience is typically as follows: 1. The user enters their account ID. -2. Azure AD displays briefly the message "Taking you to your organization's page" and the user is redirected to the sign-in page of the identity provider. The sign-in page is usually customized with the logo of the organization. +2. Microsoft Entra ID displays briefly the message "Taking you to your organization's page" and the user is redirected to the sign-in page of the identity provider. The sign-in page is usually customized with the logo of the organization. The supported AD FS versions in this federated scenario are: - Active Directory Federation Services FS v2 @@ -32,10 +32,10 @@ The supported AD FS versions in this federated scenario are: The following applies whether you connect directly to Active Directory Federation Services (AD FS) or through Active Directory. -When you acquire a token using `acquire_token_by_username_password`, MSAL Python gets the identity provider to contact based on the username. MSAL Python gets a [SAML 1.1 token](/azure/active-directory/develop/reference-saml-tokens) from the identity provider, which it then provides to Azure AD which returns the JSON Web Token (JWT). +When you acquire a token using `acquire_token_by_username_password`, MSAL Python gets the identity provider to contact based on the username. MSAL Python gets a [SAML 1.1 token](/azure/active-directory/develop/reference-saml-tokens) from the identity provider, which it then provides to Microsoft Entra which returns the JSON Web Token (JWT). ## Connecting directly to AD FS When you connect directory to AD FS, the authority you'll want to use to build your application will be something like `https://somesite.contoso.com/adfs/` -MSAL Python supports ADFS 2019, but does not support a direct connection to ADFS 2016 or ADFS v2. Once you have upgraded your on-premises system to ADFS 2019, you can use MSAL Python. \ No newline at end of file +MSAL Python supports ADFS 2019, but does not support a direct connection to ADFS 2016 or ADFS v2. Once you have upgraded your on-premises system to ADFS 2019, you can use MSAL Python. diff --git a/msal-python-conceptual/advanced/username-password-authentication.md b/msal-python-conceptual/advanced/username-password-authentication.md index 6c701fd..c36c58c 100644 --- a/msal-python-conceptual/advanced/username-password-authentication.md +++ b/msal-python-conceptual/advanced/username-password-authentication.md @@ -16,8 +16,8 @@ In general Microsoft does not advise customers to use it as it's less secure tha * By design and policy, the username/password authentication works only for Work and school accounts, but not for Microsoft Accounts (MSA). See the [definition of these 2 types of accounts here](/azure/active-directory/fundamentals/sign-up-organization). * The Username/Password authentication is not compatible with conditional access and multi-factor authentication, - because this is not an interactive flow, the Microsoft Identity platform does not have an opportunity to present a web-based dialog for the end user to interact. - As a consequence, if your app runs in an Azure AD tenant where the tenant admin requires multi-factor authentication (many organizations do that), this flow will not work. + because this is not an interactive flow, the Microsoft identity platform does not have an opportunity to present a web-based dialog for the end user to interact. + As a consequence, if your app runs in a Microsoft Entra tenant where the tenant admin requires multi-factor authentication (many organizations do that), this flow will not work. * Because Username Password Authentication is a non-interactive flow: - the user of your application must have previously consented to use the application - or the tenant admin must have previously consented to all users in the tenant to use the application. diff --git a/msal-python-conceptual/getting-started/acquiring-tokens.md b/msal-python-conceptual/getting-started/acquiring-tokens.md index 7b57fed..360c08d 100644 --- a/msal-python-conceptual/getting-started/acquiring-tokens.md +++ b/msal-python-conceptual/getting-started/acquiring-tokens.md @@ -21,7 +21,7 @@ Public client applications cannot securely store a secret and can _only_ authent - Acquire tokens **as the user** with the help of an [interactive flow](/azure/active-directory/develop/scenario-desktop-acquire-token?tabs=python#acquiring-a-token-interactively) after letting the user sign-in through the authorization request URL. - It's also possible (but not recommended) to get a token with a [username and password](/azure/active-directory/develop/scenario-desktop-acquire-token?tabs=python#username--password). -- For applications running on devices which don't have a web browser, it's possible to acquire a token through the [device code flow](/azure/active-directory/develop/scenario-desktop-acquire-token?tabs=python#command-line-tool-without-web-browser), which provides the user with a URL and a code. The user goes to a web browser on another device, enters the code and signs in. On successful authentication, Azure AD will return a token to the browser-less device. +- For applications running on devices which don't have a web browser, it's possible to acquire a token through the [device code flow](/azure/active-directory/develop/scenario-desktop-acquire-token?tabs=python#command-line-tool-without-web-browser), which provides the user with a URL and a code. The user goes to a web browser on another device, enters the code and signs in. On successful authentication, Microsoft Entra ID will return a token to the browser-less device. ### Confidential client applications @@ -29,7 +29,7 @@ Confidential client applications can securely store a secret and can authenticat - Acquire token **as the application itself** using [client credentials](/azure/active-directory/develop/scenario-daemon-acquire-token?tabs=python#acquiretokenforclient-api), and not for a user. For example, this can be used in applications which process users in batches and not one particular user, such as syncing tools. - In the case of web Apps or web APIs **calling another downstream Web API in the name of the user**, use the [On Behalf Of flow](/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow) to acquire a token based on a user assertion (e.g., SAML, JWT). -- **For Web apps authenticating in the name of a user**, acquire tokens through [authorization code](/azure/active-directory/develop/scenario-web-app-call-api-acquire-token?tabs=python) after letting the user sign-in through the authorization request URL. This is typically the mechanism used by an application which lets the user sign-in using Open ID Connect but then wants to access Web APIs for this particular user. +- **For Web apps authenticating in the name of a user**, acquire tokens through [authorization code](/azure/active-directory/develop/scenario-web-app-call-api-acquire-token?tabs=python) after letting the user sign-in through the authorization request URL. This is typically the mechanism used by an application which lets the user sign-in using OpenID Connect but then wants to access Web APIs for this particular user. ## MSAL Python token caching diff --git a/msal-python-conceptual/getting-started/client-applications.md b/msal-python-conceptual/getting-started/client-applications.md index bf37c77..ba12f92 100644 --- a/msal-python-conceptual/getting-started/client-applications.md +++ b/msal-python-conceptual/getting-started/client-applications.md @@ -12,12 +12,12 @@ description: "How to instantiate client applications in MSAL Python." Before instantiating your app with MSAL Python: 1. Understand the types of client applications available - [Public Client and Confidential Client applications](/azure/active-directory/develop/msal-client-applications). -1. You'll need to [register the application](/azure/active-directory/develop/quickstart-register-app) with Azure AD. From the registration page, you will need: +1. You'll need to [register the application](/azure/active-directory/develop/quickstart-register-app) with Microsoft Entra ID. From the registration page, you will need: - The application client identifier (a string in the form of a GUID) - The identity provider URL (the instance) and the sign-in audience for your application. These two parameters are collectively known as the **authority**. - If necessary, the tenant identifier (also a GUID) in case you are writing a line of business application scoped to just your organization (also known as a single-tenant application). - If you are building a confidential client app, you will need to create an application secret in the form of a string or certificate. - - For web applications, you'll have also set the redirect URL that Azure AD will use to return the code. For desktop applications you will need to add `http://localhost` if you're not relying on authentication brokers. + - For web applications, you'll have also set the redirect URL that Microsoft Entra ID will use to return the code. For desktop applications you will need to add `http://localhost` if you're not relying on authentication brokers. ### Instantiating a public client application diff --git a/msal-python-conceptual/index.md b/msal-python-conceptual/index.md index e4febb5..d55c5f9 100644 --- a/msal-python-conceptual/index.md +++ b/msal-python-conceptual/index.md @@ -5,7 +5,7 @@ description: "Get started with the Microsoft Authentication Library for Python t # Microsoft Authentication Library (MSAL) for Python -Get started with the Microsoft Authentication Library for Python to sign in users or apps with Microsoft identities ([Azure AD](https://azure.microsoft.com/services/active-directory/), [Microsoft Accounts](https://account.microsoft.com), and [Azure AD B2C](https://azure.microsoft.com/services/active-directory-b2c/) accounts) and obtain tokens to call Microsoft APIs such as [Microsoft Graph](https://graph.microsoft.io/) or your own APIs. +Get started with the Microsoft Authentication Library for Python to sign in users or apps with Microsoft identities ([Microsoft Entra ID](https://azure.microsoft.com/services/active-directory/), [Microsoft Accounts](https://account.microsoft.com), and [Azure AD B2C](https://azure.microsoft.com/services/active-directory-b2c/) accounts) and obtain tokens to call Microsoft APIs such as [Microsoft Graph](https://graph.microsoft.io/) or your own APIs. ## Prerequisites @@ -71,7 +71,7 @@ Acquiring tokens with MSAL Python follows a three-step pattern. There will be so result = app.acquire_token_silent(["User.Read"], account=chosen) ``` -3. If there is no suitable token in the cache or you've chosen to skip the previous step, send a request to Azure AD to get a token. There are different methods based on your client type and scenario, but for the purposes of the example we're showing how to use [`acquire_token_interactive`](xref:msal.application.PublicClientApplication.acquire_token_interactive) which will prompt the user to provide their credentials. +3. If there is no suitable token in the cache or you've chosen to skip the previous step, send a request to Microsoft Entra ID to get a token. There are different methods based on your client type and scenario, but for the purposes of the example we're showing how to use [`acquire_token_interactive`](xref:msal.application.PublicClientApplication.acquire_token_interactive) which will prompt the user to provide their credentials. ```python if not result: @@ -102,7 +102,7 @@ Once the authentication is completed and you closed the browser, you should be a MSAL Python can be used by applications to acquire tokens to access protected APIs. Tokens can be acquired by different **application types**: desktop applications, web applications, web APIs, and applications running on devices that don't have a browser (such as IoT devices). In MSAL Python, applications are categorized as follows: - **Public client applications (desktop and mobile)**. These types of apps cannot store app secrets securely. -- **Confidential client applications (web apps, web APIs, and daemon applications)**. These type of apps securely store a secret registered with Azure AD. +- **Confidential client applications (web apps, web APIs, and daemon applications)**. These type of apps securely store a secret registered with Microsoft Entra ID. Learn more about instantiating and configuring the above in the [Client applications](./getting-started/client-applications.md) topic.