将第三方身份提供商与 Office 365 结合使用
我们目前正在使用内部 SSO 解决方案，使用 2 因素身份验证，生成 SAML 以允许 SSO 访问 google apps 和 salesforce。我们希望允许对 Office 365 的支持。
我正在查看 Office 365 的所有文档，据我所知，它使用 SAML，但前提是由 ADFS 提供。
是否可以将 Office 365 与纯 SAML 解决方案结合使用？ 或者是否可以将 ADFS 与其他身份提供商（因此不是 Active Directory）一起使用。
我看过 Tivoli IP 的示例，但我不太了解这些角色，如果我理解正确的话，它实际上将实际身份验证从 ADFS 推迟到 Tivoli，但这是正确的吗？如果这是真的，那就太好了 :)
除此之外，从我的 google-expedition 中，我可以看到以下选项来将我们自己的 SSO 解决方案与 Office 365 结合使用：
- 调整 ADFS (aspx) 的登录页面并添加我们的 2fa解决方案在那里。 （来源）
- 使用 Forefront UAG，但不确定具体是什么意味着（来源）
- 使用冒充 ADFS 的服务（source -- 在评论中）
- 使用 SAML 联合身份验证（如果我理解正确的话）（来源）
从3.我得出结论4.是不可能的，但这只是旧信息，现在不再有效了吗？
感谢您提供任何有用的见解:)
we are currently using an inhouse SSO solution, using 2-factor authentication, that generates SAML to allow SSO to google apps and salesforce. We are looking to allow support for Office 365.
I am looking at all the documentation for Office 365 and from what i see, it uses SAML, but only if provided by an ADFS.
Would it be possible to use Office 365 with a pure SAML solution?
Or is it possible to use ADFS with another identity provider (so not an Active Directory).
I have seen a sample with Tivoli IP, but i do not quite understand the roles, if I understand it all correctly, it actually defers the actual authentication from ADFS to Tivoli, but is that correct? If that would be true, that would be nice :)
Aside of that, from my google-expedition I can see the following options to use our own SSO solution with Office 365:
- adapt the login page from ADFS (aspx) and add our 2fa solution there. (source)
- use Forefront UAG, but not sure what that exactly means (source)
- use a service that pretends to behave as ADFS (source --in the comments)
- use SAML to federate the authentication (if I understand correctly) (source)
From 3. i would conclude that 4. is not possible, but is that just old information and now no longer valid?
Thank you for any helpful insights :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从技术上讲，Office 365 不需要 ADFS。 SSO 可以通过任何可以发送正确类型的消息和令牌的联合服务器来完成。 （我知道，因为我已经做到了。）如果您的 SSO 解决方案发出正确类型的数据，您就可以使用它。使用 ADFS 以外的联合服务器可能会出现 Microsoft SLA 和支持问题。首先检查一下。如果您确实想重用现有的联合基础设施并需要帮助，请给我留言。
Technically speaking, there is nothing about Office 365 that requires ADFS. SSO can be done w/ any federation server that can send the right type of messages and tokens. (I know because I've done it.) If your SSO solution emits the proper type of data, you can use it. There might be Microsoft SLA and support issues w/ using a federation server other than ADFS. Check that first. If you do want to reuse your existing federation infrastructure and need help, shoot me a note.
只需确保 SAML 解决方案支持被动和主动配置文件 (ECP)。基于网络的登录需要被动配置文件。需要活动/ECP 来支持 Outlook、Thunderbird 等胖客户端。我们已经让这两个配置文件都可以工作。
Just make sure that the SAML solution supports both passive and active profile (ECP). Passive profile is required for web based sign-in. The active/ECP is required to support thick clients like Outlook, Thunderbird, etc. We've gotten both profiles to work.