question

StefanVuckovic-7419 avatar image
4 Votes"
StefanVuckovic-7419 asked Andrew526-4914 commented

SCIM user provisioning setup with manager attribute

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

azure-ad-user-provisioning
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

AbhijeetSinghKohli-MSFT avatar image
0 Votes"
AbhijeetSinghKohli-MSFT answered AbhijeetSinghKohli-MSFT edited

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

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

AbhijeetSinghKohli-MSFT avatar image
0 Votes"
AbhijeetSinghKohli-MSFT answered ZollnerD commented

Hi @StefanVuckovic-7419, 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.

· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hi @AbhijeetSinghKohli-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.

5 Votes 5 ·

@DavidL-3745 - you are entirely correct.

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

@AbhijeetSinghKohli-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?



2 Votes 2 ·

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://docs.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.

1 Vote 1 ·
SteveJerman-4666 avatar image
0 Votes"
SteveJerman-4666 answered

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


5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

AV-2928 avatar image
0 Votes"
AV-2928 answered AV-2928 edited

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?
@AbhijeetSinghKohli-MSFT

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SteveJerman-4666 avatar image
0 Votes"
SteveJerman-4666 answered

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

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

FlorianF avatar image
0 Votes"
FlorianF answered

@AbhijeetSinghKohli-MSFT is there any progress or roadmap to send e.g. DisplayName of manager - even this is not required by SCIM RFC 4.3.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

MattSlater-8355 avatar image
0 Votes"
MattSlater-8355 answered Andrew526-4914 commented

@AbhijeetSinghKohli-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


· 8
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

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.






0 Votes 0 ·

@ZollnerD

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



0 Votes 0 ·
ZollnerD avatar image ZollnerD Andrew526-4914 ·

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.

0 Votes 0 ·

@ZollnerD

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











0 Votes 0 ·
ZollnerD avatar image ZollnerD Andrew526-4914 ·

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.

1 Vote 1 ·
Show more comments
AdrianCorston-1592 avatar image
0 Votes"
AdrianCorston-1592 answered Andrew526-4914 commented

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.

· 5
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

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.

0 Votes 0 ·

Thanks @ZollnerD, 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.

0 Votes 0 ·

@ZollnerD

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?

0 Votes 0 ·
ZollnerD avatar image ZollnerD Andrew526-4914 ·

Hi @Andrew526-4914 - 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.

0 Votes 0 ·
Show more comments