From 4f41fbb7a796e21f7ec1d40f446b68522edd523f Mon Sep 17 00:00:00 2001 From: "tina-cloud-app[bot]" <58178390+tina-cloud-app[bot]@users.noreply.github.com> Date: Wed, 10 Sep 2025 05:34:05 +0000 Subject: [PATCH 01/10] TinaCMS content update --- ...Attributes-and-API-Driven-Provisioning.mdx | 128 ++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx diff --git a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx new file mode 100644 index 0000000..cbcef73 --- /dev/null +++ b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx @@ -0,0 +1,128 @@ +--- +title: Extension Attributes and API Driven Provisioning +category: Identity +excerpt: > + Learn how to extend the user schema in Microsoft Entra ID to support + API-driven provisioning, using custom attributes to enrich identity flows and + align with HR or business system requirements. +author: content/authors/warwick.md +date: 2025-09-14T14:00:00.000Z +--- + +Modern identity systems often require more than just first name, last name, and job title. With API-driven provisioning in Microsoft Entra ID, you can ingest enriched identity data—like cost centres, manager aliases, or internal classification codes—by mapping them to **extension attributes**. + +This post explores: + +\- What extension attributes are + +\- How to register and use them + +\- How to map them in an API-driven provisioning workflow + +*** + +## What Are Extension Attributes? + +Microsoft Entra ID supports schema extensions to hold custom identity metadata beyond the default directory attributes. + +There are two main types: + +\- **Directory extension attributes **(e.g., \`extensionAttribute1–15\`, often synced from on-prem AD) + +\- **Custom schema extensions** (e.g., \`extension\_{appId}\_{attributeName}\`) + +In API-driven provisioning, you can use either type—but custom schema extensions are preferred for cloud-native HR-to-Entra scenarios. + +*** + +## Registering Schema Extensions + +To register a schema extension: + +```xml +POST https://graph.microsoft.com/v1.0/schemaExtensions +Content-Type: application/json + + +{ + "id": "contosoIdentity", + "description": "Contoso's HR identity extensions", + "targetTypes": ["User"], + "properties": [ + { + "name": "employeeRegion", + "type": "String" + }, + { + "name": "costCentreCode", + "type": "String" + } + ] +} + +``` + +```nginx +extension_contosoIdentity_employeeRegion +extension_contosoIdentity_costCentreCode +``` + +These can now be used in user objects, filtered in Graph queries, and mapped in API-based provisioning. + +## API-Driven Provisioning and Attribute Mapping + +In your Entra API-driven inbound provisioning setup: + +Extension attributes from your source system (e.g. Workday, Aurion, SAP) can be passed in the payload + +These values are mapped into Entra ID using attribute mappings like: + +```json +{ + "sourceAttributeName": "region", + "targetAttributeName": "extension_contosoIdentity_employeeRegion" +} + +``` + +This lets you: + +* Enrich the user profile with business context +* Drive access policy decisions (e.g., Access Packages or Conditional Access) +* Use these values in dynamic group rules + +Tips for Working with Extension Attributes + +🔒 Schema extensions are immutable once published (property names and types can’t be changed) + +⚠️ Avoid using extensionAttribute1–15 for new apps unless bridging with on-prem AD + +You can patch values in users using Graph API after provisioning if needed + +### Example Use Case: HR System Sends Division + Cost Centre + +Imagine your HR system sends: + +```json +{ + "userPrincipalName": "jane.doe@contoso.com", + "division": "APAC", + "costCentre": "IT045" +} + +``` + +You map these to: + +* extension\_contosoIdentity\_division +* extension\_contosoIdentity\_costCentre + +Now, you can: + +* Add users to dynamic groups by division +* Assign licenses by cost centre +* Create audit reports from Entra ID profiles alone + +Wrapping Up + +Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. From 096ca51eb1006a521f1d66f8da0fa599a6e4a333 Mon Sep 17 00:00:00 2001 From: Warwick Leahy <58454534+leahy268@users.noreply.github.com> Date: Wed, 10 Sep 2025 15:38:13 +1000 Subject: [PATCH 02/10] Update Extension-Attributes-and-API-Driven-Provisioning.mdx --- ...Attributes-and-API-Driven-Provisioning.mdx | 255 +++++++++--------- 1 file changed, 128 insertions(+), 127 deletions(-) diff --git a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx index cbcef73..2851f84 100644 --- a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx +++ b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx @@ -1,128 +1,129 @@ ---- -title: Extension Attributes and API Driven Provisioning -category: Identity -excerpt: > - Learn how to extend the user schema in Microsoft Entra ID to support - API-driven provisioning, using custom attributes to enrich identity flows and - align with HR or business system requirements. -author: content/authors/warwick.md -date: 2025-09-14T14:00:00.000Z ---- - -Modern identity systems often require more than just first name, last name, and job title. With API-driven provisioning in Microsoft Entra ID, you can ingest enriched identity data—like cost centres, manager aliases, or internal classification codes—by mapping them to **extension attributes**. - -This post explores: - -\- What extension attributes are - -\- How to register and use them - -\- How to map them in an API-driven provisioning workflow - -*** - -## What Are Extension Attributes? - -Microsoft Entra ID supports schema extensions to hold custom identity metadata beyond the default directory attributes. - -There are two main types: - -\- **Directory extension attributes **(e.g., \`extensionAttribute1–15\`, often synced from on-prem AD) - -\- **Custom schema extensions** (e.g., \`extension\_{appId}\_{attributeName}\`) - -In API-driven provisioning, you can use either type—but custom schema extensions are preferred for cloud-native HR-to-Entra scenarios. - -*** - -## Registering Schema Extensions - -To register a schema extension: - -```xml -POST https://graph.microsoft.com/v1.0/schemaExtensions -Content-Type: application/json - - -{ - "id": "contosoIdentity", - "description": "Contoso's HR identity extensions", - "targetTypes": ["User"], - "properties": [ - { - "name": "employeeRegion", - "type": "String" - }, - { - "name": "costCentreCode", - "type": "String" - } - ] -} - -``` - -```nginx +--- +title: Extension Attributes and API Driven Provisioning +category: Identity +excerpt: > + Learn how to extend the user schema in Microsoft Entra ID to support + API-driven provisioning, using custom attributes to enrich identity flows and + align with HR or business system requirements. +author: content/authors/warwick.md +date: 2025-09-14T14:00:00.000Z +--- + +Modern identity systems often require more than just first name, last name, and job title. With API-driven provisioning in Microsoft Entra ID, you can ingest enriched identity data—like cost centres, manager aliases, or internal classification codes—by mapping them to **extension attributes**. + +This post explores: + +- What extension attributes are + +- How to register and use them + +- How to map them in an API-driven provisioning workflow + +*** + +## What Are Extension Attributes? + +Microsoft Entra ID supports schema extensions to hold custom identity metadata beyond the default directory attributes. + +There are two main types: + +- **Directory extension attributes **(e.g., \`extensionAttribute1–15\`, often synced from on-prem AD) + +- **Custom schema extensions** (e.g., \`extension\_{appId}\_{attributeName}\`) + +In API-driven provisioning, you can use either type—but custom schema extensions are preferred for cloud-native HR-to-Entra scenarios. + +*** + +## Registering Schema Extensions + +To register a schema extension: + +```xml +POST https://graph.microsoft.com/v1.0/schemaExtensions +Content-Type: application/json + + +{ + "id": "contosoIdentity", + "description": "Contoso's HR identity extensions", + "targetTypes": ["User"], + "properties": [ + { + "name": "employeeRegion", + "type": "String" + }, + { + "name": "costCentreCode", + "type": "String" + } + ] +} + +``` + +```nginx extension_contosoIdentity_employeeRegion -extension_contosoIdentity_costCentreCode -``` - -These can now be used in user objects, filtered in Graph queries, and mapped in API-based provisioning. - -## API-Driven Provisioning and Attribute Mapping - -In your Entra API-driven inbound provisioning setup: - -Extension attributes from your source system (e.g. Workday, Aurion, SAP) can be passed in the payload - -These values are mapped into Entra ID using attribute mappings like: - -```json -{ - "sourceAttributeName": "region", - "targetAttributeName": "extension_contosoIdentity_employeeRegion" -} - -``` - -This lets you: - -* Enrich the user profile with business context -* Drive access policy decisions (e.g., Access Packages or Conditional Access) -* Use these values in dynamic group rules - -Tips for Working with Extension Attributes - -🔒 Schema extensions are immutable once published (property names and types can’t be changed) - -⚠️ Avoid using extensionAttribute1–15 for new apps unless bridging with on-prem AD - -You can patch values in users using Graph API after provisioning if needed - -### Example Use Case: HR System Sends Division + Cost Centre - -Imagine your HR system sends: - -```json -{ - "userPrincipalName": "jane.doe@contoso.com", - "division": "APAC", - "costCentre": "IT045" -} - -``` - -You map these to: - -* extension\_contosoIdentity\_division -* extension\_contosoIdentity\_costCentre - -Now, you can: - -* Add users to dynamic groups by division -* Assign licenses by cost centre -* Create audit reports from Entra ID profiles alone - -Wrapping Up - -Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. + +extension_contosoIdentity_costCentreCode +``` + +These can now be used in user objects, filtered in Graph queries, and mapped in API-based provisioning. + +## API-Driven Provisioning and Attribute Mapping + +In your Entra API-driven inbound provisioning setup: + +Extension attributes from your source system (e.g. Workday, Aurion, SAP) can be passed in the payload + +These values are mapped into Entra ID using attribute mappings like: + +```json +{ + "sourceAttributeName": "region", + "targetAttributeName": "extension_contosoIdentity_employeeRegion" +} + +``` + +This lets you: + +* Enrich the user profile with business context +* Drive access policy decisions (e.g., Access Packages or Conditional Access) +* Use these values in dynamic group rules + +Tips for Working with Extension Attributes + +🔒 Schema extensions are immutable once published (property names and types can’t be changed) + +⚠️ Avoid using extensionAttribute1–15 for new apps unless bridging with on-prem AD + +You can patch values in users using Graph API after provisioning if needed + +### Example Use Case: HR System Sends Division + Cost Centre + +Imagine your HR system sends: + +```json +{ + "userPrincipalName": "jane.doe@contoso.com", + "division": "APAC", + "costCentre": "IT045" +} + +``` + +You map these to: + +* extension\_contosoIdentity\_division +* extension\_contosoIdentity\_costCentre + +Now, you can: + +* Add users to dynamic groups by division +* Assign licenses by cost centre +* Create audit reports from Entra ID profiles alone + +Wrapping Up + +Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. From f74d0338bb08f3dcc630acdece72ce7c61bead67 Mon Sep 17 00:00:00 2001 From: Warwick Leahy <58454534+leahy268@users.noreply.github.com> Date: Wed, 10 Sep 2025 15:41:00 +1000 Subject: [PATCH 03/10] Update Extension-Attributes-and-API-Driven-Provisioning.mdx --- ...n-Attributes-and-API-Driven-Provisioning.mdx | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx index 2851f84..f56c03d 100644 --- a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx +++ b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx @@ -13,11 +13,9 @@ Modern identity systems often require more than just first name, last name, and This post explores: -- What extension attributes are - -- How to register and use them - -- How to map them in an API-driven provisioning workflow +* What extension attributes are +* How to register and use them +* How to map them in an API-driven provisioning workflow *** @@ -27,9 +25,8 @@ Microsoft Entra ID supports schema extensions to hold custom identity metadata b There are two main types: -- **Directory extension attributes **(e.g., \`extensionAttribute1–15\`, often synced from on-prem AD) - -- **Custom schema extensions** (e.g., \`extension\_{appId}\_{attributeName}\`) +* **Directory extension attributes **(e.g., \`extensionAttribute1–15\`, often synced from on-prem AD) +* **Custom schema extensions** (e.g., \`extension\_{appId}\_{attributeName}\`) In API-driven provisioning, you can use either type—but custom schema extensions are preferred for cloud-native HR-to-Entra scenarios. @@ -43,7 +40,6 @@ To register a schema extension: POST https://graph.microsoft.com/v1.0/schemaExtensions Content-Type: application/json - { "id": "contosoIdentity", "description": "Contoso's HR identity extensions", @@ -59,12 +55,10 @@ Content-Type: application/json } ] } - ``` ```nginx extension_contosoIdentity_employeeRegion - extension_contosoIdentity_costCentreCode ``` @@ -127,3 +121,4 @@ Now, you can: Wrapping Up Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. + From ecf8d620564860c3e1828a95857d56bc6ae3e516 Mon Sep 17 00:00:00 2001 From: Warwick Leahy <58454534+leahy268@users.noreply.github.com> Date: Wed, 10 Sep 2025 15:43:36 +1000 Subject: [PATCH 04/10] Update Extension-Attributes-and-API-Driven-Provisioning.mdx --- .../Extension-Attributes-and-API-Driven-Provisioning.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx index f56c03d..49b2a41 100644 --- a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx +++ b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx @@ -1,12 +1,13 @@ --- title: Extension Attributes and API Driven Provisioning category: Identity +heroImg: /uploads/Blogs/API-Driven-Provisioning.png excerpt: > Learn how to extend the user schema in Microsoft Entra ID to support API-driven provisioning, using custom attributes to enrich identity flows and align with HR or business system requirements. author: content/authors/warwick.md -date: 2025-09-14T14:00:00.000Z +date: 2025-09-14 --- Modern identity systems often require more than just first name, last name, and job title. With API-driven provisioning in Microsoft Entra ID, you can ingest enriched identity data—like cost centres, manager aliases, or internal classification codes—by mapping them to **extension attributes**. @@ -17,7 +18,6 @@ This post explores: * How to register and use them * How to map them in an API-driven provisioning workflow -*** ## What Are Extension Attributes? @@ -30,7 +30,6 @@ There are two main types: In API-driven provisioning, you can use either type—but custom schema extensions are preferred for cloud-native HR-to-Entra scenarios. -*** ## Registering Schema Extensions @@ -122,3 +121,4 @@ Wrapping Up Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. + From f20ea62d4bf71f9d77abb99bbd683c9d843cd2f9 Mon Sep 17 00:00:00 2001 From: Warwick Leahy <58454534+leahy268@users.noreply.github.com> Date: Wed, 10 Sep 2025 15:46:00 +1000 Subject: [PATCH 05/10] Update Extension-Attributes-and-API-Driven-Provisioning.mdx --- .../Extension-Attributes-and-API-Driven-Provisioning.mdx | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx index 49b2a41..4fd5a3e 100644 --- a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx +++ b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx @@ -31,7 +31,7 @@ There are two main types: In API-driven provisioning, you can use either type—but custom schema extensions are preferred for cloud-native HR-to-Entra scenarios. -## Registering Schema Extensions +## Registering Schema Extensions To register a schema extension: @@ -87,9 +87,9 @@ This lets you: Tips for Working with Extension Attributes -🔒 Schema extensions are immutable once published (property names and types can’t be changed) +Schema extensions are immutable once published (property names and types can’t be changed) -⚠️ Avoid using extensionAttribute1–15 for new apps unless bridging with on-prem AD +Avoid using extensionAttribute1–15 for new apps unless bridging with on-prem AD You can patch values in users using Graph API after provisioning if needed @@ -120,5 +120,3 @@ Now, you can: Wrapping Up Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. - - From 831a627f8e725f7fdc16a7991e19ac9d08aae6c8 Mon Sep 17 00:00:00 2001 From: Warwick Leahy <58454534+leahy268@users.noreply.github.com> Date: Wed, 10 Sep 2025 15:49:11 +1000 Subject: [PATCH 06/10] Update Extension-Attributes-and-API-Driven-Provisioning.mdx --- .../Extension-Attributes-and-API-Driven-Provisioning.mdx | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx index 4fd5a3e..ad0b46d 100644 --- a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx +++ b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx @@ -10,7 +10,7 @@ author: content/authors/warwick.md date: 2025-09-14 --- -Modern identity systems often require more than just first name, last name, and job title. With API-driven provisioning in Microsoft Entra ID, you can ingest enriched identity data—like cost centres, manager aliases, or internal classification codes—by mapping them to **extension attributes**. +Modern identity systems often require more than just first name, last name, and job title. With API-driven provisioning in Microsoft Entra ID, you can ingest enriched identity data—like cost centres, manager aliases, or internal classification codes—by mapping them to extension attributes. This post explores: @@ -25,8 +25,8 @@ Microsoft Entra ID supports schema extensions to hold custom identity metadata b There are two main types: -* **Directory extension attributes **(e.g., \`extensionAttribute1–15\`, often synced from on-prem AD) -* **Custom schema extensions** (e.g., \`extension\_{appId}\_{attributeName}\`) +* **Directory extension attributes **(e.g., extensionAttribute1–15, often synced from on-prem AD) +* **Custom schema extensions** (e.g., extension\_{appId}\_{attributeName}) In API-driven provisioning, you can use either type—but custom schema extensions are preferred for cloud-native HR-to-Entra scenarios. @@ -120,3 +120,4 @@ Now, you can: Wrapping Up Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. + From 963edb682136c073f50015e1ff57bafd6babdaf0 Mon Sep 17 00:00:00 2001 From: Warwick Leahy <58454534+leahy268@users.noreply.github.com> Date: Wed, 10 Sep 2025 15:50:44 +1000 Subject: [PATCH 07/10] Update Extension-Attributes-and-API-Driven-Provisioning.mdx --- .../Extension-Attributes-and-API-Driven-Provisioning.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx index ad0b46d..c5d504d 100644 --- a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx +++ b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx @@ -25,8 +25,8 @@ Microsoft Entra ID supports schema extensions to hold custom identity metadata b There are two main types: -* **Directory extension attributes **(e.g., extensionAttribute1–15, often synced from on-prem AD) -* **Custom schema extensions** (e.g., extension\_{appId}\_{attributeName}) +* Directory extension attributes (e.g., extensionAttribute1–15, often synced from on-prem AD) +* Custom schema extensions (e.g., extension\_{appId}\_{attributeName}) In API-driven provisioning, you can use either type—but custom schema extensions are preferred for cloud-native HR-to-Entra scenarios. @@ -121,3 +121,4 @@ Wrapping Up Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. + From 5eb785f5843794881146201308ef301d729b8a6b Mon Sep 17 00:00:00 2001 From: Warwick Leahy <58454534+leahy268@users.noreply.github.com> Date: Wed, 10 Sep 2025 15:57:40 +1000 Subject: [PATCH 08/10] Update Extension-Attributes-and-API-Driven-Provisioning.mdx --- ...tension-Attributes-and-API-Driven-Provisioning.mdx | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx index c5d504d..00dd7de 100644 --- a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx +++ b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx @@ -35,7 +35,6 @@ In API-driven provisioning, you can use either type—but custom schema extensio To register a schema extension: -```xml POST https://graph.microsoft.com/v1.0/schemaExtensions Content-Type: application/json @@ -54,12 +53,10 @@ Content-Type: application/json } ] } -``` -```nginx extension_contosoIdentity_employeeRegion extension_contosoIdentity_costCentreCode -``` + These can now be used in user objects, filtered in Graph queries, and mapped in API-based provisioning. @@ -71,13 +68,11 @@ Extension attributes from your source system (e.g. Workday, Aurion, SAP) can be These values are mapped into Entra ID using attribute mappings like: -```json { "sourceAttributeName": "region", "targetAttributeName": "extension_contosoIdentity_employeeRegion" } -``` This lets you: @@ -97,14 +92,13 @@ You can patch values in users using Graph API after provisioning if needed Imagine your HR system sends: -```json + { "userPrincipalName": "jane.doe@contoso.com", "division": "APAC", "costCentre": "IT045" } -``` You map these to: @@ -122,3 +116,4 @@ Wrapping Up Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. + From b78b5eb385028d785876b0ee7fd97ade7f14e594 Mon Sep 17 00:00:00 2001 From: Warwick Leahy <58454534+leahy268@users.noreply.github.com> Date: Wed, 10 Sep 2025 16:01:12 +1000 Subject: [PATCH 09/10] Update Extension-Attributes-and-API-Driven-Provisioning.mdx --- ...Attributes-and-API-Driven-Provisioning.mdx | 74 +++++++++++-------- 1 file changed, 42 insertions(+), 32 deletions(-) diff --git a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx index 00dd7de..b92338d 100644 --- a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx +++ b/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx @@ -14,10 +14,11 @@ Modern identity systems often require more than just first name, last name, and This post explores: -* What extension attributes are -* How to register and use them -* How to map them in an API-driven provisioning workflow +- What extension attributes are +- How to register and use them +- How to map them in an API-driven provisioning workflow +--- ## What Are Extension Attributes? @@ -25,19 +26,23 @@ Microsoft Entra ID supports schema extensions to hold custom identity metadata b There are two main types: -* Directory extension attributes (e.g., extensionAttribute1–15, often synced from on-prem AD) -* Custom schema extensions (e.g., extension\_{appId}\_{attributeName}) +- **Directory extension attributes** (e.g., `extensionAttribute1–15`, often synced from on-prem AD) +- **Custom schema extensions** (e.g., `extension_{appId}_{attributeName}`) -In API-driven provisioning, you can use either type—but custom schema extensions are preferred for cloud-native HR-to-Entra scenarios. +In API-driven provisioning, you can use either type—but custom schema extensions are **preferred for cloud-native HR-to-Entra scenarios**. +--- ## Registering Schema Extensions To register a schema extension: +```http POST https://graph.microsoft.com/v1.0/schemaExtensions Content-Type: application/json +``` +```json { "id": "contosoIdentity", "description": "Contoso's HR identity extensions", @@ -53,67 +58,72 @@ Content-Type: application/json } ] } +``` -extension_contosoIdentity_employeeRegion -extension_contosoIdentity_costCentreCode +After registration, your attributes will appear as: +- `extension_contosoIdentity_employeeRegion` +- `extension_contosoIdentity_costCentreCode` These can now be used in user objects, filtered in Graph queries, and mapped in API-based provisioning. -## API-Driven Provisioning and Attribute Mapping +--- -In your Entra API-driven inbound provisioning setup: +## API-Driven Provisioning and Attribute Mapping -Extension attributes from your source system (e.g. Workday, Aurion, SAP) can be passed in the payload +In your Entra **API-driven inbound provisioning** setup: -These values are mapped into Entra ID using attribute mappings like: +- Extension attributes from your source system (e.g., Workday, Aurion, SAP) can be passed in the payload +- These values are mapped into Entra ID using attribute mappings like: +```json { "sourceAttributeName": "region", "targetAttributeName": "extension_contosoIdentity_employeeRegion" } - +``` This lets you: -* Enrich the user profile with business context -* Drive access policy decisions (e.g., Access Packages or Conditional Access) -* Use these values in dynamic group rules +- Enrich the user profile with business context +- Drive access policy decisions (e.g., Access Packages or Conditional Access) +- Use these values in dynamic group rules -Tips for Working with Extension Attributes +--- -Schema extensions are immutable once published (property names and types can’t be changed) +## Tips for Working with Extension Attributes -Avoid using extensionAttribute1–15 for new apps unless bridging with on-prem AD +- 🔒 `schemaExtensions` are **immutable** once published (you can't rename or change property types) +- ⚠️ Avoid using `extensionAttribute1–15` for new apps unless bridging with on-prem AD +- 🔄 You can still **patch user values** using Graph API after provisioning -You can patch values in users using Graph API after provisioning if needed +--- -### Example Use Case: HR System Sends Division + Cost Centre +## Example Use Case: HR System Sends Division + Cost Centre Imagine your HR system sends: - +```json { "userPrincipalName": "jane.doe@contoso.com", "division": "APAC", "costCentre": "IT045" } - +``` You map these to: -* extension\_contosoIdentity\_division -* extension\_contosoIdentity\_costCentre +- `extension_contosoIdentity_division` +- `extension_contosoIdentity_costCentre` Now, you can: -* Add users to dynamic groups by division -* Assign licenses by cost centre -* Create audit reports from Entra ID profiles alone - -Wrapping Up - -Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. +- Add users to dynamic groups by division +- Assign licenses by cost centre +- Create audit reports from Entra ID profiles alone +--- +## Wrapping Up +Extension attributes enable true identity enrichment in Microsoft Entra ID, especially when combined with API-driven provisioning. They allow IT and HR to meet in the middle—passing meaningful business context into the cloud directory, powering automation, access decisions, and governance. From 26f5ca677d5b945ce2cd036366a91a04b9e0b79e Mon Sep 17 00:00:00 2001 From: Warwick Leahy <58454534+leahy268@users.noreply.github.com> Date: Wed, 10 Sep 2025 16:01:40 +1000 Subject: [PATCH 10/10] Update and rename Extension-Attributes-and-API-Driven-Provisioning.mdx to extension-attributes-and-api-driven-provisioning.mdx --- ...g.mdx => extension-attributes-and-api-driven-provisioning.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/posts/2025/{Extension-Attributes-and-API-Driven-Provisioning.mdx => extension-attributes-and-api-driven-provisioning.mdx} (100%) diff --git a/content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx b/content/posts/2025/extension-attributes-and-api-driven-provisioning.mdx similarity index 100% rename from content/posts/2025/Extension-Attributes-and-API-Driven-Provisioning.mdx rename to content/posts/2025/extension-attributes-and-api-driven-provisioning.mdx