我试过阅读Shibboleth文档，并且很快就成了一个新手。如果专家花半分钟时间说“没有机会，那就行不通”，我真的不想花太多时间来理解它。
我有很多用户群，可以说（现在）群组是不同的公司。
我想做的只是让用户看到其他公司的一些字段。
例如，我是A公司的Alice，我可以看到B公司的Bob有一个电子邮件地址bob@b.com。他可以看到我是alice@a.com
然而，B公司的其他人都可以看到Bob有姓氏和电话号码等。 A公司的其他人都能看到我的详细信息。
为了使这更复杂，让我们说Bob和我成为朋友并决定我们想要分享我们的信息然后我们创建一个“瞬态”组“alice＆amp; bob”。因为我们都是该组的成员，所以我们都可以看到彼此的全部细节。 （但A中没有其他人可以看到鲍勃的细节，除非他们也是朋友，反之亦然）
我可以通过查询所有属性和关系来排序应用程序代码中的所有内容，只显示相关内容，但为了提高安全性，我希望限制从源头上披露信息。
我想我需要使用属性过滤器，但不确定它们是否能够给我这种控制级别。由于能够形成关系的这种灵活性，我是否需要动态构建过滤器文件，然后最终得到Shibboleth开始扼杀的数千个过滤器，因为逻辑很长。 类似于“是组中的请求者”过滤规则： https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeRequesterInEntityGroup
答案 0 :(得分：0)
对于Shibboleth或大多数SAML / SSO提供商而言，这不是一项工作。您所说的属性过滤用于过滤IdP和SP之间的属性...这基本上是说：让服务提供商或“应用程序”B从IdP A中看到以下属性。
一旦您将属性传输到另一端的SP，Shibboleth就不会（实际上不能）为您提供一种机制来阻止应用程序B的用户看到您提供给他们的任何数据......事实上，他们真的不应该看到IdP传输的任何数据，除非你通过你的应用程序以某种方式公开它。
答案 1 :(得分：0)
上面的答案非常好，但我相信非shibboleth用户会觉得它很混乱。
快速回答是你真的不想这样做，有可能这样做，但100％有更好的工具来做。
好的，现在完整版（抱歉我的某些地方太明显了）。 在shibboleth架构中，我们可以区分两个主要组件。
身份提供商 IdP - 其中包含有关特定组织用户的信息。
服务提供商 SP - 通常是一些服务或受保护资源，我们可以为其定义一些访问规则
在您的示例中，Alice和Bob的凭据可以存储在不同的IdP中，因为它们是不同组织/公司的成员，或者（不完全匹配整个模式）您可以为所有用户提供一个IdP，并且“company”只是用户属性之一。 IdP不会为您提供任何类型的api，除了正在进行身份验证的用户之外，它还为您提供访问任何用户的用户属性的机会。
另一方面，您拥有SP，它拥有一些超级秘密资源，您可以为其定义策略。并且您希望为其定义用户信息的策略。
这就解决了问题，在SP方面你无法访问整个用户数据库，这就是Shibboleth的工作方式。您当然可以将所有用户信息视为SP中的资源，但如果您可以清楚地访问应用程序端的所有用户凭据，那么您为什么要使用Shibboleth呢？
如果您将所有用户信息存储在您的服务端，我相信任何设计良好的关系数据库对您的服务进行某种身份验证都会比这项工作更好。
希望有所帮助。