Question

我们有一个Identity Provider User注册表和一个SOAP Web Service，供应用程序读/写用户配置文件。现在我们计划添加一个SCIM接口。

我们发现Core User架构涵盖了基本的属性集，但是我们现有的系统对相同的属性有不同的命名约定。

例如，请说USERTELEPHONENUMBER，USERSTREETADDR1等。

考虑到已经使用此命名约定的大量应用程序，我们希望继续使用SCIM 2.0。

鉴于我们可以扩展核心用户架构，

1）我们可以选择不使用Core架构中的任何属性吗？如果有效负载包含这些属性，我们是否可以在服务器端忽略它们，并仅处理自定义模式属性？

示例用户文档 -

    {
        "schemas":    [ "urn:scim:schemas:core:2.0:User",
                     urn:scim:schemas:extension:customattrs:2.0:User"], 
        "id": "2819c223-7f76-453a-919d-413861904646",

        "urn:scim:schemas:extension:customattrs:2.0:User": {
            "USERFIRSTNAME": "fname",
            "USERLASTNAME": "lname",
         "USERTELEPHONENUMBER": "1231231234
     }
    }

2）我们可以自己定义一个新资源并定义一个新的核心模式。

这些选项中哪一个更清洁？

Answer 1

如果您不打算使用核心模式，为什么要使用SCIM？

SCIM强烈建议不要让多个属性表示同样的事情。

我建议您在属性和SCIM核心（以及企业扩展）属性之间创建映射。如果有任何内容未映射到这两个模式，则应创建扩展。

Answer 2

我认为您需要的是scim核心架构属性与现有系统属性之间的映射。正如您所说，scim核心架构和现有系统属性具有相同的含义，您不应该在扩展中重新定义这些属性。 scim规范强烈建议不要这样做。（https://tools.ietf.org/html/rfc7643#section-3.3）

架构扩展应避免重新定义中定义的任何属性本规范和SHOULD应遵循此中定义的约定说明书

但是，如果您在现有系统中有其他属性，则可以在扩展名中定义它们。

如果您有像WSO2 Charon（https://docs.wso2.com/display/IS450/Implementing+SCIM+with+Charon）这样的解耦scim实现，我建议您在scim实现层下面使用单独的图层，以便在将属性用于任何业务逻辑之前对其进行必要的映射。但这基本上取决于您的实施。

SCIM 2.0的架构扩展

2 个答案: