SCIM user provisioning setup with manager attribute

Question

SCIM user provisioning setup with manager attribute

Stefan Vuckovic 51

Hello, I am trying to get the correct setup for the 'manager' attribute that comes from the SCIM protocol, enterprise user extension.
According to the SCIM protocol, this is a complex type attribute with 3 sub-attributes: 'value', '$ref', and read-only 'displayName'. But the default setup from Azure AD actually sends manager as a simple attribute:
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager": "user-id".

Is there a way to get the setup that follows the SCIM specification and sends "manager" with "value" and "$ref"?

Regards

Steve Jerman 1 Reputation point

2021-09-02T18:10:30.207+00:00

Has there been any progress on this? The application obviously doesn't comply to the spec. I'm struggling to see a solution that doesn't break other users of my SCIM API.

Ive been trying to hack my way around the issue. How can I add a custom attribute? For example if I can add:

urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:managerId

I can add that parameter to my SCIM schema and just deal with the consequences.

Steve
AV 1 Reputation point

2021-09-02T20:29:54.39+00:00

Is there a known custom expression to set as the custom Azure attribute so we can use urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager.displayName?
@Abhijeet-MSFT
Steve Jerman 1 Reputation point

2021-12-10T11:30:37.873+00:00

Hello. For those coming to this answer again, I ran into a another issue with the manager attribute today. When Azure sends the manager attribute they break the spec as per the discussion above. However, when they read the data back they expect the correct format! ie manager.value.

To reproduce just use the 'Provision on demand' function... run it twice and you will see the issue.

I just wasted a morning on this. Who has different models for serialization and deserialiation?

Steve
FlorianF 21 Reputation points

2022-03-09T17:55:08.603+00:00

@Abhijeet-MSFT is there any progress or roadmap to send e.g. DisplayName of manager - even this is not required by SCIM RFC 4.3.
Matt Slater 1 Reputation point

2022-04-13T17:39:44.497+00:00

@Abhijeet-MSFT Raising this one for attention once again. If there is any progress on this issue, let us know.

As a SaaS software vendor, we are integrating our platform with multiple customer's Identity Providers, including Azure AD, Okta and OneLogin. When integrating with Azure AD we are having to jump through extra unneccessary hoops to get at the manager's details, which isn't necessary with other providers that conform to the RFC spec. I understand the complexities of changing things now, but the longer this takes and the more SCIM is adopted worldwide, the harder it will surely become.

Note: A workaround for us (although far from ideal) is to make an additional API call to the Customer's tenant via Graph API to lookup the manager's details at live time, when we need it.
e.g. GET https://graph.microsoft.com/v1.0/users/{userPrincipalName}/manager
Adrian Corston 6 Reputation points

2022-05-04T04:45:13.72+00:00

Adding my support to this request - I work on a SCIM app provisioning broker service for apps that don't have native SCIM support, and quite a few of them want the Manager's name. It would be nice not to have to source it out-of-band via Graph API calls.
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2022-05-06T14:17:28.86+00:00

EDIT: I mixed up this and another post so this answer is mostly incorrect. Leaving it for context..

The original issue on this post was that Microsoft's generic custom non-gallery SCIM client treats manager as a simple string rather than complex.

String: "manager":"123"
Complex: "manager": { "value":"123" }

The issue that you are highlighting is that aside from the client sending the manager value as the wrong data type, you would like our SCIM client to send the manager's displayName value as well. This isn't something that is on our roadmap, and it will not be added to our roadmap, as the SCIM spec says:

manager
The user's manager. A complex type that optionally allows service
providers to represent organizational hierarchy by referencing the
"id" attribute of another User.

value The "id" of the SCIM resource representing the user's manager. RECOMMENDED.

$ref The URI of the SCIM resource representing the User's manager. RECOMMENDED.

displayName The displayName of the user's manager. This attribute is OPTIONAL, and mutability is "readOnly".

The expectation from both the spec and Microsoft is that the displayName value is optional and only returned by the service provider, not provided by the client. You should already have the manager's displayName attribute present if it has been provisioned separately as another user, and should be able to make calls internal to your application to retrieve that.
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2022-05-06T14:20:35.413+00:00

Please see my above response to Matt. What you are requesting is not possible due to the SCIM spec defining the manager's displayName sub-attribute as readOnly.
Adrian Corston 6 Reputation points

2022-05-07T00:09:46.257+00:00

Thanks @Anonymous , that makes sense. Sorry I overlooked your previous reply. I'll look into into using the manager reference to extract that info from other provisioned users as you suggest.
Andrew526 16 Reputation points

2022-05-09T07:14:34.273+00:00

@Anonymous

> The issue that you are highlighting is that aside from the client sending the manager value as the wrong data type, you would like our SCIM client to send the manager's displayName value as well.

No. Matt didn't state what we are after, exactly. I can tell you that what we are after is the manager's email address. We don't need the display name.

Does this change things from your perspective?
Andrew526 16 Reputation points

2022-05-09T07:19:43.43+00:00

@Anonymous

Let's not get side-tracked about the manager's displayName issue, which you incorrectly assumed that Matt was after.

The issue here is that Microsoft's SCIM Client implementation re. sending manager is plain wrong, and non-conformant to the SCIM Schema spec. Other SCIM clients we deal with (e.g. Okta) get this right.

If fixing the incorrect behaviour is not on Microsoft's roadmap, can you get it on the roadmap asap please?
Andrew526 16 Reputation points

2022-05-09T07:37:24.367+00:00

@Anonymous

> You should already have the manager's displayName attribute present if it has been provisioned separately as another user

Actually: no. We haven't yet taken the step of on-boarding a user's manager via the manager attribute... precisely because of Microsoft's SCIM Client's non-conformant behaviour in providing it.

Instead we do the Graph API call to get a user's manager's email address (which is all we're really after).

We were hoping for this to be fixed, given that you've known about this issue for about a year and a half.

But we're coming close to the point where we might have to give up on expecting a fix, and have to code our SCIM Service to deal with both correct clients (Okta) and incorrect clients (Microsoft). It's a sad day.

Here's a question...

If the Microsoft SCIM Client provides manager in an incorrect format, does it expect to get the manager data back from the service in the same incorrect format? Or can/does it cope with the Service's response being in the correct format?
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2022-05-09T18:31:04.893+00:00

It changes the question but not the answer. The SCIM spec only provides a vehicle for the client providing the manager's ID value, not anything else.
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2022-05-09T18:33:28.227+00:00

We may be able to fix this by the end of this calendar year, based on the most recent discussions I've had with my colleagues on the engineering team that owns this. I can't give anything more than that on timelines, unfortunately.

On how our client expects the data to be returned, I'm not actually sure. I'll share this thread with one of my colleagues who can check and verify. I believe it can handle the correct complex formatting but am not 100% positive on this so I'll get verification.
Andrew526 16 Reputation points

2022-05-10T08:28:51.5+00:00

@Anonymous

On how our client expects the data to be returned, I'm not actually sure. I'll share this thread with one of my colleagues who can check and verify. I believe it can handle the correct complex formatting but am not 100% positive on this so I'll get verification.

Thanks. This is very important to know!
Owino Akelo - MSFT 76 Reputation points Microsoft Employee

2022-05-11T14:40:28.63+00:00

The system expects the response with the correct formatting.
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2022-05-11T14:57:55.617+00:00

Hi @Andrew526 - I don't think there were any assumptions made. Rereading my response and the question it was in response to, I'm not sure how I got to that point other than crossing information between Matt's question and Adrian's, both of which were outstanding at the time.

As I've said, we're aware that it is nonconformant. My colleague will be responding shortly with details surrounding current behaviors on what our client expects versus what it sends. I apologize for the mistake, but I am human.

On our engineering team, I'm closely tied to and invested in the compliance of our SCIM client, and as soon as we can reasonably and safely make this change (among many others) we will. I can't provide an ETA other than the loose one above (hopefully by end of this year) right now, but when to allocate budget for this is something we're actively discussing.
Andrew526 16 Reputation points

2022-05-11T15:35:47.287+00:00

@Anonymous - no worries, and no apologies necessary.

My colleague will be responding shortly with details surrounding current behaviors on what our client expects versus what it sends.

That's great, thanks. Based on our discussions of the last few days on this page, Matt and I have a much clearer picture about what the state of play is. We are now ready to do the extra work to on-board a user's manager via the manager attribute. If the Azure SCIM client expects manager to come back in the correct format, we have less work to do... if it expects it in the non-conformant format, we have more work to do (such as recording which way manager was specified in the first place, in our database - and acting on that information on egress). So I look forward to hearing the answer to this question.

Thanks for your timely responses of this week, because the silence has been deafening before you got involved.
Andrew526 16 Reputation points

2022-05-12T07:00:21.847+00:00

The system expects the response with the correct formatting.

Excellent news; thank you.
Aran Kaspar 0 Reputation points

2025-04-18T03:56:12.5933333+00:00

Did anyone find an actual work-around that doesn't require an API key to be created for graph? Some apps are doing the mapping on their end (Slack/Zoom). Likely using the ObjectID of the manager since that's what "manager" att. provides.

Any changes here since 2022?

2 answers

Your answer

Steve Jerman 1 Reputation point

2021-09-02T18:10:30.207+00:00

Has there been any progress on this? The application obviously doesn't comply to the spec. I'm struggling to see a solution that doesn't break other users of my SCIM API.

Ive been trying to hack my way around the issue. How can I add a custom attribute? For example if I can add:

urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:managerId

I can add that parameter to my SCIM schema and just deal with the consequences.

Steve
AV 1 Reputation point

2021-09-02T20:29:54.39+00:00

Is there a known custom expression to set as the custom Azure attribute so we can use urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager.displayName?
@Abhijeet-MSFT
Steve Jerman 1 Reputation point

2021-12-10T11:30:37.873+00:00

Hello. For those coming to this answer again, I ran into a another issue with the manager attribute today. When Azure sends the manager attribute they break the spec as per the discussion above. However, when they read the data back they expect the correct format! ie manager.value.

To reproduce just use the 'Provision on demand' function... run it twice and you will see the issue.

I just wasted a morning on this. Who has different models for serialization and deserialiation?

Steve
FlorianF 21 Reputation points

2022-03-09T17:55:08.603+00:00

@Abhijeet-MSFT is there any progress or roadmap to send e.g. DisplayName of manager - even this is not required by SCIM RFC 4.3.
Matt Slater 1 Reputation point

2022-04-13T17:39:44.497+00:00

@Abhijeet-MSFT Raising this one for attention once again. If there is any progress on this issue, let us know.

As a SaaS software vendor, we are integrating our platform with multiple customer's Identity Providers, including Azure AD, Okta and OneLogin. When integrating with Azure AD we are having to jump through extra unneccessary hoops to get at the manager's details, which isn't necessary with other providers that conform to the RFC spec. I understand the complexities of changing things now, but the longer this takes and the more SCIM is adopted worldwide, the harder it will surely become.

Note: A workaround for us (although far from ideal) is to make an additional API call to the Customer's tenant via Graph API to lookup the manager's details at live time, when we need it.
e.g. GET https://graph.microsoft.com/v1.0/users/{userPrincipalName}/manager
Adrian Corston 6 Reputation points

2022-05-04T04:45:13.72+00:00

Adding my support to this request - I work on a SCIM app provisioning broker service for apps that don't have native SCIM support, and quite a few of them want the Manager's name. It would be nice not to have to source it out-of-band via Graph API calls.
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2022-05-06T14:17:28.86+00:00

EDIT: I mixed up this and another post so this answer is mostly incorrect. Leaving it for context..

The original issue on this post was that Microsoft's generic custom non-gallery SCIM client treats manager as a simple string rather than complex.

String: "manager":"123"
Complex: "manager": { "value":"123" }

The issue that you are highlighting is that aside from the client sending the manager value as the wrong data type, you would like our SCIM client to send the manager's displayName value as well. This isn't something that is on our roadmap, and it will not be added to our roadmap, as the SCIM spec says:

manager
The user's manager. A complex type that optionally allows service
providers to represent organizational hierarchy by referencing the
"id" attribute of another User.

value The "id" of the SCIM resource representing the user's manager. RECOMMENDED.

$ref The URI of the SCIM resource representing the User's manager. RECOMMENDED.

displayName The displayName of the user's manager. This attribute is OPTIONAL, and mutability is "readOnly".

The expectation from both the spec and Microsoft is that the displayName value is optional and only returned by the service provider, not provided by the client. You should already have the manager's displayName attribute present if it has been provisioned separately as another user, and should be able to make calls internal to your application to retrieve that.
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2022-05-06T14:20:35.413+00:00

Please see my above response to Matt. What you are requesting is not possible due to the SCIM spec defining the manager's displayName sub-attribute as readOnly.
Adrian Corston 6 Reputation points

2022-05-07T00:09:46.257+00:00

Thanks @Anonymous , that makes sense. Sorry I overlooked your previous reply. I'll look into into using the manager reference to extract that info from other provisioned users as you suggest.
Andrew526 16 Reputation points

2022-05-09T07:14:34.273+00:00

@Anonymous

> The issue that you are highlighting is that aside from the client sending the manager value as the wrong data type, you would like our SCIM client to send the manager's displayName value as well.

No. Matt didn't state what we are after, exactly. I can tell you that what we are after is the manager's email address. We don't need the display name.

Does this change things from your perspective?
Andrew526 16 Reputation points

2022-05-09T07:19:43.43+00:00

@Anonymous

Let's not get side-tracked about the manager's displayName issue, which you incorrectly assumed that Matt was after.

The issue here is that Microsoft's SCIM Client implementation re. sending manager is plain wrong, and non-conformant to the SCIM Schema spec. Other SCIM clients we deal with (e.g. Okta) get this right.

If fixing the incorrect behaviour is not on Microsoft's roadmap, can you get it on the roadmap asap please?
Andrew526 16 Reputation points

2022-05-09T07:37:24.367+00:00

@Anonymous

> You should already have the manager's displayName attribute present if it has been provisioned separately as another user

Actually: no. We haven't yet taken the step of on-boarding a user's manager via the manager attribute... precisely because of Microsoft's SCIM Client's non-conformant behaviour in providing it.

Instead we do the Graph API call to get a user's manager's email address (which is all we're really after).

We were hoping for this to be fixed, given that you've known about this issue for about a year and a half.

But we're coming close to the point where we might have to give up on expecting a fix, and have to code our SCIM Service to deal with both correct clients (Okta) and incorrect clients (Microsoft). It's a sad day.

Here's a question...

If the Microsoft SCIM Client provides manager in an incorrect format, does it expect to get the manager data back from the service in the same incorrect format? Or can/does it cope with the Service's response being in the correct format?
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2022-05-09T18:31:04.893+00:00

It changes the question but not the answer. The SCIM spec only provides a vehicle for the client providing the manager's ID value, not anything else.
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2022-05-09T18:33:28.227+00:00

We may be able to fix this by the end of this calendar year, based on the most recent discussions I've had with my colleagues on the engineering team that owns this. I can't give anything more than that on timelines, unfortunately.

On how our client expects the data to be returned, I'm not actually sure. I'll share this thread with one of my colleagues who can check and verify. I believe it can handle the correct complex formatting but am not 100% positive on this so I'll get verification.
Andrew526 16 Reputation points

2022-05-10T08:28:51.5+00:00

@Anonymous

On how our client expects the data to be returned, I'm not actually sure. I'll share this thread with one of my colleagues who can check and verify. I believe it can handle the correct complex formatting but am not 100% positive on this so I'll get verification.

Thanks. This is very important to know!
Owino Akelo - MSFT 76 Reputation points Microsoft Employee

2022-05-11T14:40:28.63+00:00

The system expects the response with the correct formatting.
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2022-05-11T14:57:55.617+00:00

Hi @Andrew526 - I don't think there were any assumptions made. Rereading my response and the question it was in response to, I'm not sure how I got to that point other than crossing information between Matt's question and Adrian's, both of which were outstanding at the time.

As I've said, we're aware that it is nonconformant. My colleague will be responding shortly with details surrounding current behaviors on what our client expects versus what it sends. I apologize for the mistake, but I am human.

On our engineering team, I'm closely tied to and invested in the compliance of our SCIM client, and as soon as we can reasonably and safely make this change (among many others) we will. I can't provide an ETA other than the loose one above (hopefully by end of this year) right now, but when to allocate budget for this is something we're actively discussing.
Andrew526 16 Reputation points

2022-05-11T15:35:47.287+00:00

@Anonymous - no worries, and no apologies necessary.

My colleague will be responding shortly with details surrounding current behaviors on what our client expects versus what it sends.

That's great, thanks. Based on our discussions of the last few days on this page, Matt and I have a much clearer picture about what the state of play is. We are now ready to do the extra work to on-board a user's manager via the manager attribute. If the Azure SCIM client expects manager to come back in the correct format, we have less work to do... if it expects it in the non-conformant format, we have more work to do (such as recording which way manager was specified in the first place, in our database - and acting on that information on egress). So I look forward to hearing the answer to this question.

Thanks for your timely responses of this week, because the silence has been deafening before you got involved.
Andrew526 16 Reputation points

2022-05-12T07:00:21.847+00:00

The system expects the response with the correct formatting.

Excellent news; thank you.
Aran Kaspar 0 Reputation points

2025-04-18T03:56:12.5933333+00:00

Did anyone find an actual work-around that doesn't require an API key to be created for graph? Some apps are doing the mapping on their end (Slack/Zoom). Likely using the ObjectID of the manager since that's what "manager" att. provides.

Any changes here since 2022?

Answer 1

Abhijeet-MSFT 546 Microsoft Employee

I dont think Azure AD Provisioning allows sending any other attribute for manager except id. Let me confirm and come back on this.

Answer 2

Abhijeet-MSFT 546 Microsoft Employee

Hi @Stefan Vuckovic , The SCIM RFC 4.3 does not require any of these attributes to be mandatory, as such we are only sending ID at the moment. Long term we may have a plan to send manager with value but currently there is no way to achieve it.

David L 31 Reputation points

2021-01-14T20:08:19.617+00:00
Hi @Abhijeet-MSFT ,

If you are only sending the ID, shouldn't it go in the value attribute of the manager object? I mean this:

urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager.value

instead of:

urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager

Because according to the spec manager is a complex type and the ID should go in the value attribute. Currently this is breaking existing implementations and libraries which are expecting a complex type in the manager field and are receiving an ID instead.
Andrew526 16 Reputation points

2021-04-12T11:05:13.883+00:00

@David L - you are entirely correct.

The Azure AD implementation is obviously not adhering to the spec.

@Abhijeet-MSFT : "The SCIM RFC 4.3 does not require any of these attributes to be mandatory, as such we are only sending ID at the moment." - yes, but you are doing so incorrectly. From the spec:-

manager
The user's manager. A complex type that optionally allows service
providers to represent organizational hierarchy by referencing the
"id" attribute of another User.

It's not good for SCIM service providers to have to implement it the correct way for conformant clients, and incorrectly for AD.

Have you or would you please create a ticket for this to be fixed?
Danny Zollner 10,801 Reputation points Microsoft Employee Moderator

2021-09-07T17:02:23.633+00:00

Acknowledging that this is implemented incorrectly by Azure AD's SCIM client. It isn't something that can be fixed overnight however as unfortunately our incorrect implementation has led to some SCIM implementations taking a dependency on this. This is on a list of SCIM client compliance issues that we're hoping to address in the next 3-6 months, at which point we will release another flag similar to aadOptScim062020 (see: https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/application-provisioning-config-problem-scim-compatibility#flags-to-alter-the-scim-behavior).

Today there is not a supported workaround to flow manager as a complex attribute as we don't support customized referential attributes, customized complex attributes or changing behavior for core SCIM/enterprise extension attributes.
Christian Moser 36 Reputation points

2025-06-05T11:48:41.6133333+00:00

@Danny Zollner We also just bumped into this issue. Do you have any update on this?

Share via

SCIM user provisioning setup with manager attribute

2 answers

Your answer