集成WSO2 API管理器、Identity Server和Shibboleth的建议

当前推荐的设置WSO2 API管理器以针对Shibboleth IDP使用SSO的方法是什么

我们的组织有一个围绕Shibboleth的IDP构建的现有SSO基础设施，我们希望将其集成到API Manager安装中。理想用例：

• 用户导航到API管理器存储
• 用户被重定向到Shibboleth IDP登录页面
• 如果不存在API管理器帐户，则会创建一个API管理器帐户并将其分配给订阅服务器角色
• 用户返回API管理器并登录。“登录身份：”表示合理的用户名（即不是GUID）

我知道API管理器中包含一个SAML2验证器组件，但它的功能有限，特别是它不处理加密断言，使用用户名/显示名的特定属性和自动用户创建

我知道我们可以编写一个自定义验证器，但是我们宁愿避免创建另一个需要维护且没有社区支持的代码库。如果无法确定更简单的解决方案，那么我们很可能会这样做

我目前正在调查的是将API管理器的所有用户管理委托给WSO2身份服务器。它将在返回AM之前将身份验证委托给Shibboleth和auto provision用户。IS似乎可以解决上述所有问题

首先，这是一个合适的策略吗？如果是，建议如何配置AM和

IS和AM应该都指向同一个JDBC数据库，还是AM应该指向IS的LDAP服务器

关于指向is的AM验证器，我应该使用SAML还是OAuth，还是有更好/更简单的

Shibboleth IDP v2.4–首选具有属性推送的SAML2。
WSO2 API管理器v1.6.0

---

WSO2 Identity Server v5.0.0

以下是我的研究结果，供感兴趣的人参考：

1） 这是一个适当的战略。Identity Server 5.0版本中的新功能主要围绕此场景。AM的1.7版本还包括一些功能，以方便此设置。最后，我从开发人员那里听说，他们打算在接下来的几个版本中进一步推动这种集成

2） 从AM 1.6开始，出现了一个bug，几乎需要共享同一个主要JDBC用户存储。从1.7开始，它应该更加开放。
WSO2的人似乎不喜欢LDAP和JDBC（除了默认的H2 DB不是为生产环境设计的），但是如果您选择安装DB还是为此而打开LDAP，LDAP服务器似乎更适合您的选择

3） 当目标是向用户展示UN/PW屏幕时，最好使用SAML在两者之间进行通信。当目标是使用预先发布的令牌登录时，则使用OAuth。API管理器和应用程序在幕后使用这两种协议，但这个特定问题的答案似乎是SAML。

---

未来，WSO2计划扩展其产品的“受信任的IDP”功能，这将简化此过程（并在幕后使用SAML）。

由于有人刚刚将此标记为有用，请允许我提供一个更新。我们已经推进了API管理器->身份服务器->Shibboleth的战略。这一策略行之有效。API管理器通过SAML与IS对话，并从共享LDAP读取用户数据。IS收集返回的（加密的）断言，并在翻译后创建一个供API使用的用户。在2014年旧金山WSO2大会上，我还与Prabath Siriwardena（WSO2安全总监）进行了交谈，并参加了他的一些会谈。他们希望将这一想法进一步推广，现在正在推广IS作为一种“身份服务总线”，能够在身份消费者和提供者之间进行转换。我们正在调查其他不懂shibboleth但会说话的产品，例如，oauth使用IS作为翻译。我们已经使用此设置一段时间了。流程是：1）用户转到APIM 2）用户重定向到is 3）用户重定向到shibbolet IDP 4）用户登录并向is提供saml断言5）is创建一个包含SSO详细信息的帐户作为声明，然后向APIM发送一个新的saml断言6）APIM将用户记录到新创建（或更新）的is/APIM帐户中。使用这种方法，我们实现了整个SSO集成，用户的详细信息甚至包含在JWT中。