Office365和Shibboleth

为了提供一点背景信息,我们现有的学生电子邮件服务是由微软的Live@EDU服务完成的。不久前,我们被告知我们将被升级Office365教育版

从功能的角度来看,这一举措的一个重大变化是,将密码从我们的现场Active Directory系统复制到Live@EDU身份的旧方法将不再可用——令人沮丧!然而,我们将能够联合我们的本地身份,而不是使用任何一个微软活动目录联合服务(ADFS)或特殊的习惯.在这两者中,我们的首选是Shibboleth,因为我们已经理解并使用它,而且我们没有任何ADFS基础设施或专业知识。

在试图实现我们本地Shibboleth基础设施之间的联邦关系时(其背后是一个太阳Oracle目录服务器(DSEE)平台和活动目录(Active Directory),我们在前进的道路上遇到了许多障碍。总结一下,微软的实现SAML2似乎是

一些支持团队似乎很好,他们明白ADFS不是唯一的方法,但是他们很难找到!

到目前为止,基于浏览器的SSO可以工作,但ECP (ActiveSync等)不能……SAML断言在这里发出,并在另一端被拒绝。它上周还在工作,然后就不工作了,然后又开始工作了,现在又坏了。支持电话打开…

文档

用于配置Office365域以与现有Shibboleth实例联合的Microsoft文档似乎非常好。他们提供了一页又一页关于技网还发布了正式的白皮书关于这个话题。

可用的文档似乎假设您将在Windows上运行Shibboleth Identity Provider,但从长远来看,这不会有什么不同——毕竟它只是Apache Tomcat中的一个java应用程序……对吧?

目前遇到的问题

在测试实现时,一些相当基本的问题变得很明显:

  1. 发布的SAML2元数据是不完整的
  2. Shibboleth IdP应该使用真正的SSL证书ECP(它扩展了SAML2模型,以允许非基于浏览器的身份验证流程,从而允许使用其他协议,如IMAP和ActiveSync)
  3. 可用的诊断不是很好(在网上)或不存在(对于ECP)
  4. 似乎有一个假设,你的Shibboleth IdP不会被用于其他任何东西(并且将运行在Windows上)

元数据不完整

按照Technet上的说明添加Windows Azure AD元数据一切似乎都很正常。当测试ECP功能时,从已发布的HTTPS端点可用的元数据(https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml)与Technet文章中解释它如何工作的元数据不同——它缺少使ECP工作所需的信息绑定配置。

一个快速的解决方法是不配置IdP从微软下载元数据(正如他们建议的那样),而是像Technet文章中所包含的那样硬编码元数据:

<?XML版本="1.0"编码="utf-8"?> < EntityDescriptor xmlns = " urn: oasis: names: tc: SAML: 2.0:元数据”entityID = " urn:联盟:MicrosoftOnline”> < SPSSODescriptor WantAssertionsSigned = " true " protocolSupportEnumeration = " urn: oasis: names: tc: SAML: 2.0:协议”> < AssertionConsumerService绑定= " urn: oasis: names: tc: SAML: 2.0:绑定:http - post”位置= " https://login.microsoftonline.com/login.srf "指数= " 0 " isDefault = " true " / > < AssertionConsumerService绑定= " urn: oasis: names: tc: SAML: 2.0:绑定:HTTP-POST-SimpleSign”Location="https://login.microsoftonline.com/login.srf" index="1"/>   urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress   urn:mace:shibboleth:1.0:nameIdentifier   urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified  urn:oasis:names:tc:SAML:2.0:nameid-format:transient   urn:oasis:names:tc:SAML:2.0:nameid-format:persistent   

所以我们在rely -party.xml中的当前配置是:

<!——Azure for Office 365——>xmlns="urn:mace:shibboleth:2.0:元数据" metadataFile="/opt/idp/metadata/azure-metadata.xml">  . xmlns="urn:mace:shibboleth:2.0:元数据samlmd:SPSSODescriptor    . samlmd:SPSSODescriptor  

用于ECP的SSL证书

方法配置联合设置时,已显式地告知要信任哪个信任结构证书Set-MsolDomainAuthenticationpowershell命令),Microsoft SP将拒绝与HTTPS端点通信不可信的(或者,在我们的例子中是自签名的)证书。

诊断

当试图诊断浏览器登录问题时,用户通常看到的唯一错误是“您的组织无法将您登录到此服务”。并不完全有用。碰巧,在页面的HTML源代码中隐藏了一个错误代码。关于如何提取它的详细信息是可用的在这里

至于ECP相关的问题,似乎没有诊断问题的方法。的情况下,远程服务只是拒绝验证声明不错,简单的POP3,“未知用户名或错误密码”。

+OK Microsoft Exchange POP3服务准备就绪。USER user@federated.domain +OK PASS password -ERR登录失败:未知用户名或错误密码。

有帮助的。

我认为接下来还会有更多。

对“Office365和Shibboleth

  1. 嗨,马丁,

    是的,我们的IdP(相当)稳定。我们偶尔会有无法解释的晃动,但在大多数情况下,它运行得很好。我们支持使用Web联邦登录以及ActiveSync, IMAP和SMTP通过ECP。

    我们目前没有使用Lync。

    希望有帮助!

  2. 你好,Matthew,你最终是否能够克服这些挑战并实现Shibboleth IdP ECP Profile的稳定部署?移动用户和富桌面客户端用户现在可以使用SSO连接到他们的Office 365电子邮件帐户吗?

留下回复