SCIM (System for Cross-domain Identity Management) 核心支持属性
SCIM (System for Cross-domain Identity Management) core supported attributes
我们正在为用户、组和一些自定义资源实施 SCIM 资源提供程序。
SCIM 核心架构 RFC 7643 定义用户资源，因此只有 userName 和核心属性（id、schemas）是 必需的 。此外，它还定义了 可选 属性，例如名称、profileUrl 等
某些 可选 属性在我们的上下文中没有意义（例如 ims）或不受支持或支持非常昂贵。
另一方面，其他 optional 属性如 name 应该是 "required" 并且应该返回 "always".
推荐的表达方式是什么，以便客户知道应该提供哪些属性？
就我对 rfc 的理解而言，我们应该在 /Schemas 端点上提供核心用户模式的调整版本。这是正确的方法吗？
它会让我们的提供商 "none SCIM compliant"?
已在 scim 邮件列表上开始讨论。以下是 rfc 作者之一 Phil Hunt 的回答：
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.
完整的讨论可以在 https://www.ietf.org/mail-archive/web/scim/current/msg02851.html
上找到
我们正在为用户、组和一些自定义资源实施 SCIM 资源提供程序。
SCIM 核心架构 RFC 7643 定义用户资源，因此只有 userName 和核心属性（id、schemas）是 必需的 。此外，它还定义了 可选 属性，例如名称、profileUrl 等
某些 可选 属性在我们的上下文中没有意义（例如 ims）或不受支持或支持非常昂贵。
另一方面，其他 optional 属性如 name 应该是 "required" 并且应该返回 "always".
推荐的表达方式是什么，以便客户知道应该提供哪些属性？ 就我对 rfc 的理解而言，我们应该在 /Schemas 端点上提供核心用户模式的调整版本。这是正确的方法吗？ 它会让我们的提供商 "none SCIM compliant"?
已在 scim 邮件列表上开始讨论。以下是 rfc 作者之一 Phil Hunt 的回答：
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.
完整的讨论可以在 https://www.ietf.org/mail-archive/web/scim/current/msg02851.html
上找到