1

We are implementing SCIM Resource Provider for Users, Groups and a couple of custom resources. SCIM Core Schema RFC 7643 defines User resource so, that only userName and core attributes (id, schemas) are required. Plus it defines optional attributes like name, profileUrl, etc.

Some optional attributes do not make sense in our context (e.g. ims) or are not supported or very expensive to be supported. From the other hand, other optional attributes like name should be "required" and should be returned "always".

What is the recommended way to express this, so that the clients would know what attributes should be provided? As much I understand rfc, we should provide the adjusted, tweaked version of core User schema on /Schemas endpoint. Is it correct way? Would it make our Provider "none SCIM compliant"?

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
AC.
  • 714
  • 8
  • 27

1 Answers1

2

Discussion has been started on scim mailing list. Here is the answer from Phil Hunt, one of rfc authors:

This happens a lot particularly when adapting SCIM protocol on top of applications (e.g. payroll, HCM, CRM, etc). Each app has data they care about that is a sub-set of what is seen in IDM systems. The point of 7643 is really to define standard attribute names, types, syntax, and handling that developers can count on.

IMO, you do not have to implement the schema exactly as published in 7643. It is quite common practice to omit attributes (e.g. such as an app that doesn’t care about ims). Note that renaming standard attributes or changing their formats will produce interop concerns.

Use the extension mechanism to define your own app specific attributes (see section 3.3 of 7643 and 4.3 for the EnterpriseUser example).

You are free to omit unused attributes from your schema. You document what your server actually supports in the /Schemas endpoint.

The full discussion can be found on https://www.ietf.org/mail-archive/web/scim/current/msg02851.html

Community
  • 1
  • 1
AC.
  • 714
  • 8
  • 27