SCIM user provisioning setup with manager attribute

Stefan Vuckovic 31

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

8 answers

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.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment
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
Please sign in to rate this answer.
Danny Zollner 9,521 Reputation points Microsoft Employee

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.

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: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 9,521 Reputation points Microsoft Employee

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 9,521 Reputation points Microsoft Employee

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.

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.
Sign in to comment
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.
Please sign in to rate this answer.
Danny Zollner 9,521 Reputation points Microsoft Employee

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: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?

Danny Zollner 9,521 Reputation points Microsoft Employee

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.
Sign in to comment