Merge pull request #229898 from MicrosoftDocs/main

Publish to Live Wednesday 4AM PST, 03/08

Author: PMEds28

.openpublishing.redirection.healthcare-apis.json

@@ -665,13 +665,17 @@
           "redirect_url": "/azure/healthcare-apis/iot/how-to-use-mapping-debugger",
           "redirect_document_id": false
       },
+      {   "source_path_from_root": "/articles/healthcare-apis/iot/how-to-use-monitoring-tab.md",
+          "redirect_url": "/azure/healthcare-apis/iot/how-to-use-monitoring-and-health-checks-tabs",
+          "redirect_document_id": false
+      },
       {   "source_path_from_root": "/articles/healthcare-apis/events/events-display-metrics.md",
           "redirect_url": "/azure/healthcare-apis/events/events-use-metrics",
           "redirect_document_id": false
       },
       {    "source_path_from_root": "/articles/healthcare-apis/events/events-export-logs-metrics.md",
           "redirect_url": "/azure/healthcare-apis/events/events-enable-diagnostic-settings",
-          "redirect_document_id": true
+          "redirect_document_id": false
       }
     ]
   }

articles/active-directory/develop/TOC.yml

@@ -69,6 +69,13 @@
           href: active-directory-how-applications-are-added.md
         - name: Single-tenant and multi-tenant apps
           href: single-and-multi-tenant-apps.md
+    - name: Custom Authentication Extensions
+      displayName: Custom Authentication Extensions
+      items:
+        - name: Overview
+          href: custom-extension-overview.md
+        - name: Custom claims provider
+          href: custom-claims-provider-overview.md
     - name: Security best practices
       displayName: least privilege, secure app configuration, conditional access
       items:
@@ -135,6 +142,16 @@
             - name: SAML app multi-instancing
               displayName: Configure SAML app multi-instancing for an application
               href: reference-app-multi-instancing.md
+        - name: Custom claims provider
+          items:
+            - name: Token issuance start event
+              items:
+                - name: Create and register a custom claims provider API
+                  href: custom-extension-get-started.md
+                - name: Configure a SAML app to call a custom claims provider
+                  href: custom-extension-configure-saml-app.md
+                - name: Troubleshoot your custom claims provider API
+                  href: custom-extension-troubleshoot.md
         - name: Handle browser cookie restrictions
           items:
             - name: Handle ITP in Safari
@@ -826,6 +843,8 @@
       href: authentication-national-cloud.md
     - name: Microsoft Graph API reference (identity operations)
       href: /graph/api/resources/azure-ad-overview
+    - name: Custom claims provider reference
+      href: custom-claims-provider-reference.md
 - name: Resources
   items:
     - name: Help and support options
@@ -835,7 +854,7 @@
       href: reference-breaking-changes.md
     - name: Video learning
       href: identity-videos.md
-    - name: "Blog: M365 Developer - Microsoft identity platform"
+    - name: "Blog: Microsoft 365 Developer - Microsoft identity platform"
       href: https://devblogs.microsoft.com/microsoft365dev/category/microsoft-identity-platform/
     - name: "Blog: Azure AD - Identity"
       href: https://techcommunity.microsoft.com/t5/azure-active-directory-identity/bg-p/Identity

articles/active-directory/develop/active-directory-configurable-token-lifetimes.md

@@ -9,18 +9,18 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 09/07/2022
+ms.date: 03/07/2023
 ms.author: ryanwi
 ms.custom: aaddev, identityplatformtop40, contperf-fy21q1
 ms.reviewer: ludwignick, sreyanthmora, marsma
 ---
 # Configurable token lifetimes in the Microsoft identity platform (preview)
 
-You can specify the lifetime of a access, ID, or SAML token issued by the Microsoft identity platform. You can set token lifetimes for all apps in your organization, for a multi-tenant (multi-organization) application, or for a specific service principal in your organization. However, we currently do not support configuring the token lifetimes for [managed identity service principals](../managed-identities-azure-resources/overview.md).
+You can specify the lifetime of an access, ID, or SAML token issued by the Microsoft identity platform. You can set token lifetimes for all apps in your organization, for a multi-tenant (multi-organization) application, or for a specific service principal in your organization. However, we currently don't support configuring the token lifetimes for [managed identity service principals](../managed-identities-azure-resources/overview.md).
 
-In Azure AD, a policy object represents a set of rules that are enforced on individual applications or on all applications in an organization. Each policy type has a unique structure, with a set of properties that are applied to objects to which they are assigned.
+In Azure AD, a policy object represents a set of rules that are enforced on individual applications or on all applications in an organization. Each policy type has a unique structure, with a set of properties that are applied to objects to which they're assigned.
 
-You can designate a policy as the default policy for your organization. The policy is applied to any application in the organization, as long as it is not overridden by a policy with a higher priority. You also can assign a policy to specific applications. The order of priority varies by policy type.
+You can designate a policy as the default policy for your organization. The policy is applied to any application in the organization, as long as it isn't overridden by a policy with a higher priority. You also can assign a policy to specific applications. The order of priority varies by policy type.
 
 For examples, read [examples of how to configure token lifetimes](configure-token-lifetimes.md).
 
@@ -99,14 +99,14 @@ Refresh and session token configuration are affected by the following properties
 |Single-Factor Session Token Max Age  |MaxAgeSessionSingleFactor |Session tokens (persistent and nonpersistent)  |Until-revoked |
 |Multi-Factor Session Token Max Age  |MaxAgeSessionMultiFactor  |Session tokens (persistent and nonpersistent)  |Until-revoked |
 
-Non-persistent session tokens have a Max Inactive Time of 24 hours whereas persistent session tokens have a Max Inactive Time of 90 days. Any time the SSO session token is used within its validity period, the validity period is extended another 24 hours or 90 days. If the SSO session token is not used within its Max Inactive Time period, it is considered expired and will no longer be accepted. Any changes to this default periods should be change using [Conditional Access](../conditional-access/howto-conditional-access-session-lifetime.md).
+Non-persistent session tokens have a Max Inactive Time of 24 hours whereas persistent session tokens have a Max Inactive Time of 90 days. Anytime the SSO session token is used within its validity period, the validity period is extended another 24 hours or 90 days. If the SSO session token isn't used within its Max Inactive Time period, it's considered expired and will no longer be accepted. Any changes to this default periods should be change using [Conditional Access](../conditional-access/howto-conditional-access-session-lifetime.md).
 
 You can use PowerShell to find the policies that will be affected by the retirement.  Use the [PowerShell cmdlets](configure-token-lifetimes.md#get-started) to see the all policies created in your organization, or to find which apps and service principals are linked to a specific policy.
 
 ## Policy evaluation and prioritization
 You can create and then assign a token lifetime policy to a specific application, to your organization, and to service principals. Multiple policies might apply to a specific application. The token lifetime policy that takes effect follows these rules:
 
-* If a policy is explicitly assigned to the service principal, it is enforced.
+* If a policy is explicitly assigned to the service principal, it's enforced.
 * If no policy is explicitly assigned to the service principal, a policy explicitly assigned to the parent organization of the service principal is enforced.
 * If no policy is explicitly assigned to the service principal or to the organization, the policy assigned to the application is enforced.
 * If no policy has been assigned to the service principal, the organization, or the application object, the default values are enforced. (See the table in [Configurable token lifetime properties](#configurable-token-lifetime-properties).)

articles/active-directory/develop/custom-claims-provider-overview.md

@@ -0,0 +1,41 @@
+---
+title: Custom claims provider overview
+titleSuffix: Microsoft identity platform
+description: Conceptual article describing the custom claims provider as part of the custom authentication extension framework.
+services: active-directory
+author: yoelhor
+manager: CelesteDG
+
+ms.service: active-directory
+ms.subservice: develop
+ms.workload: identity
+ms.topic: conceptual
+ms.date: 03/06/2023
+ms.author: davidmu
+ms.reviewer: JasSuri
+ms.custom: aaddev 
+#Customer intent: As a developer, I want to learn about custom claims provider so that I can augment tokens with claims from an external identity system or role management system.
+---
+
+# Custom claims provider (preview)
+
+This article provides an overview to the Azure Active Directory (Azure AD) custom claims provider. 
+When a user authenticates to an application, a custom claims provider can be used to add  claims into the token. A custom claims provider is made up of a custom extension that calls an external REST API, to fetch claims from external systems. A custom claims provider can be assigned to one or many applications in your directory.
+
+Key data about a user is often stored in systems external to Azure AD. For example, secondary email, billing tier, or sensitive information. Some applications may rely on these attributes for the application to function as designed. For example, the application may block access to certain features based on a claim in the token.
+
+Use a custom claims provider for the following scenarios:
+
+- **Migration of legacy systems** - You may have legacy identity systems such as Active Directory Federation Services (AD FS) or data stores (such as LDAP directory) that hold information about users. You'd like to migrate these applications, but can't fully migrate the identity data into Azure AD. Your apps may depend on certain information on the token, and can't be rearchitected.
+- **Integration with other data stores that can't be synced to the directory** - You may have third-party systems, or your own systems that store user data. Ideally this information could be consolidated, either through [synchronization](../cloud-sync/what-is-cloud-sync.md) or direct migration, in the Azure AD directory. However, that isn't always feasible. The restriction may be because of data residency, regulations, or other requirements.
+
+## Token issuance start event listener
+
+An event listener is a procedure that waits for an event to occur. The custom extension uses the **token issuance start** event listener. The  event is triggered when a token is about to be issued to your application. When the event is triggered the custom extension REST API is called to fetch attributes from external systems.
+
+For an example using a custom claims provider with the **token issuance start** event listener, check out the [get started with custom claims providers](custom-extension-get-started.md) article.
+
+## Next steps
+
+- Learn how to [create and register a custom claims provider](custom-extension-get-started.md) with a sample Open ID Connect application.
+- If you already have a custom claims provider registered, you can configure a [SAML application](custom-extension-configure-saml-app.md) to receive tokens with claims sourced from an external store.