Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into rolyon-rbac-roles-website-contributor

Author: rolyon

.openpublishing.redirection.json

@@ -46602,6 +46602,11 @@
       "source_path_from_root": "/articles/app-service/web-sites-integrate-with-vnet.md",
       "redirect_url": "/azure/app-service/overview-vnet-integration",
       "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/mariadb/concepts-performance-recommendations.md",
+      "redirect_url": "/azure/mariadb/overview",
+      "redirect_document_id": false
     }
   ]
 }

articles/active-directory/conditional-access/concept-conditional-access-session.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 10/21/2021
+ms.date: 10/25/2021
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -80,6 +80,12 @@ For more information, see the article [Configure authentication session manageme
 - Non-CAE capable clients shouldn't get a regular token for CAE-capable services.
 - Reject when IP seen by resource provider isn't in the allowed range.
 
+## Disable resilience defaults (Preview)
+
+During an outage, Azure AD will extend access to existing sessions while enforcing Conditional Access policies. If a policy cannot be evaluated, access is determined by resilience settings. 
+
+If resilience defaults are disabled, access is denied once existing sessions expire.​ For more information, see the article [Conditional Access: Resilience defaults](resilience-defaults.md).
+
 ## Next steps
 
 - [Conditional Access common policies](concept-conditional-access-policy-common.md)

articles/active-directory/conditional-access/media/concept-conditional-access-session/conditional-access-session.png

@@ -156,6 +156,8 @@
     href: authentication-flows-app-scenarios.md
   - name: Applications and service principals
     href: app-objects-and-service-principals.md
+  - name: Workload identity federation
+    href: workload-identity-federation.md
   - name: Identity platform best practices
     href: identity-platform-integration-checklist.md
   - name: App security
@@ -544,7 +546,11 @@
     - name: Create a service principal using Azure PowerShell
       href: howto-authenticate-service-principal-powershell.md
     - name: Create a service principal using the Azure portal
-      href: howto-create-service-principal-portal.md
+      href: howto-create-service-principal-portal.md   
+    - name: Configure an app to trust a GitHub repo
+      href: workload-identity-federation-create-trust-github.md 
+    - name: Configure an app to trust an external identity provider
+      href: workload-identity-federation-create-trust.md
   - name: Accept sign-ins from multiple tenants
     items:
     - name: Modify accounts supported by an app
@@ -561,7 +567,7 @@
     - name: Add app roles in your application
       href: howto-add-app-roles-in-azure-ad-apps.md
     - name: Implement RBAC in your application
-      href: howto-implement-rbac-for-apps.md
+      href: howto-implement-rbac-for-apps.md      
   - name: Build for resilience
     items:
     - name: Development Overview

articles/active-directory/develop/TOC.yml

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 06/23/2021
+ms.date: 10/18/2021
 ms.author: hirsin
 ms.reviewer: nacanuma, jmprieur
 ms.custom: contperf-fy21q4, aaddev
@@ -20,7 +20,9 @@ ms.custom: contperf-fy21q4, aaddev
 
 The Microsoft identity platform allows an application to use its own credentials for authentication anywhere a client secret could be used, for example, in the OAuth 2.0  [client credentials grant](v2-oauth2-client-creds-grant-flow.md) flow and the [on-behalf-of](v2-oauth2-on-behalf-of-flow.md) (OBO) flow.
 
-One form of credential that an application can use for authentication is a [JSON Web Token](./security-tokens.md#json-web-tokens-and-claims) (JWT) assertion signed with a certificate that the application owns.
+One form of credential that an application can use for authentication is a [JSON Web Token](./security-tokens.md#json-web-tokens-and-claims) (JWT) assertion signed with a certificate that the application owns. This is described in the [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) specification for the `private_key_jwt` client authentication option.
+
+If you're interested in using a JWT issued by another identity provider as a credential for your application, please see [workload identity federation](workload-identity-federation.md) for how to set up a federation policy.
 
 ## Assertion format
 
@@ -38,12 +40,12 @@ To compute the assertion, you can use one of the many JWT libraries in the langu
 
 Claim type | Value | Description
 ---------- | ---------- | ----------
-aud | `https://login.microsoftonline.com/{tenantId}/v2.0` | The "aud" (audience) claim identifies the recipients that the JWT is intended for (here Azure AD) See [RFC 7519, Section 4.1.3](https://tools.ietf.org/html/rfc7519#section-4.1.3).  In this case, that recipient is the login server (login.microsoftonline.com).
-exp | 1601519414 | The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. See [RFC 7519, Section 4.1.4](https://tools.ietf.org/html/rfc7519#section-4.1.4).  This allows the assertion to be used until then, so keep it short - 5-10 minutes after `nbf` at most.  Azure AD does not place restrictions on the `exp` time currently. 
-iss | {ClientID} | The "iss" (issuer) claim identifies the principal that issued the JWT, in this case your client application.  Use the GUID application ID.
-jti | (a Guid) | The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The "jti" value is a case-sensitive string. [RFC 7519, Section 4.1.7](https://tools.ietf.org/html/rfc7519#section-4.1.7)
-nbf | 1601519114 | The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. [RFC 7519, Section 4.1.5](https://tools.ietf.org/html/rfc7519#section-4.1.5).  Using the current time is appropriate. 
-sub | {ClientID} | The "sub" (subject) claim identifies the subject of the JWT, in this case also your application. Use the same value as `iss`. 
+`aud` | `https://login.microsoftonline.com/{tenantId}/v2.0` | The "aud" (audience) claim identifies the recipients that the JWT is intended for (here Azure AD) See [RFC 7519, Section 4.1.3](https://tools.ietf.org/html/rfc7519#section-4.1.3).  In this case, that recipient is the login server (login.microsoftonline.com).
+`exp` | 1601519414 | The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. See [RFC 7519, Section 4.1.4](https://tools.ietf.org/html/rfc7519#section-4.1.4).  This allows the assertion to be used until then, so keep it short - 5-10 minutes after `nbf` at most.  Azure AD does not place restrictions on the `exp` time currently. 
+`iss` | {ClientID} | The "iss" (issuer) claim identifies the principal that issued the JWT, in this case your client application.  Use the GUID application ID.
+`jti` | (a Guid) | The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The "jti" value is a case-sensitive string. [RFC 7519, Section 4.1.7](https://tools.ietf.org/html/rfc7519#section-4.1.7)
+`nbf` | 1601519114 | The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. [RFC 7519, Section 4.1.5](https://tools.ietf.org/html/rfc7519#section-4.1.5).  Using the current time is appropriate. 
+`sub` | {ClientID} | The "sub" (subject) claim identifies the subject of the JWT, in this case also your application. Use the same value as `iss`. 
 
 ### Signature