您好，Joao

这个问题不错，可以，但是需要更多地了解您的设置，才能确定问题出在哪里。 根据我的经验，需要执行以下操作。 此方案适用于使用OData设置的iOS本地应用程序，因此不完全相同，但希望可以为您提供更多信息。

-分配给应用程序的移动目标需要激活[传播用户名]标志，并且SSO机制需要设置为"应用程序到应用程序SSO"。 代理服务器类型当然是Internet。

-应用程序本身的安全设置应设置为OAuth。 我还设置了[忽略用户名大小写]，以确保没有奇怪的情况发生。

最后，检查您在移动服务中的总体安全设置-尤其是基本身份验证设置。 通常将其设置为"默认身份提供者"-假设这是您要传播的用户。

希望这会有所帮助！ 也许提供一些屏幕截图或设置跟踪，以便您可以查看问题所在。

感谢和亲切问候

菲尔·库利（Phil Cooley）

感谢菲尔的帮助。

设置中还有哪些其他细节会有所帮助？

我们在应用程序中注意到，当我们使用saml身份验证时，移动目标将saml断言xml传递到云连接器。 但是，当我们使用oauth时，会传递带有用户信息的json。 因此我们得出结论，也许云连接器无法理解此json。 应该可以吗？

在您的方案中，在将OData Provisioning传递给Cloud Connector之前，您是否使用OData Provisioning作为代理？ 那么它将为云连接器创建一个saml断言吗？

嗨Joao，

下图应有助于阐明在混合景观体系结构中使用户从一端认证到另一端的过程中的各个部分。 Bi-Modal就像几年前的分析师所说）。

在配置身份验证时 "功能"选项卡下"移动服务"主控室中的机制是您正在配置的上图中的第一个大括号。在这里，欢迎您选择OAuth，并针对您应用程序的所有意图和目的，向用户展示OAuth流程 。 用户通过身份验证后，该用户便位于Cloud Platform租户中的Mobile Services实例范围内。

从这里开始，取决于您要用作数据源的目标类型，该目标类型决定了下一步将发生什么。 就您而言，您正在访问内部部署的数据源，因此您的目的地必定指向Cloud Connector。 在这种情况下，通信（和协议）对用户是不透明的。 这是上图中的第二个大括号。 可以说，维护了用户上下文（是的，这是一个SAML断言）。

最后，旅程的最后一站是将用户身份"传播"到目标后端 X.509用户证书或通过令牌（Kerberos）。 在此阶段，可以操纵身份的表示方式以及将断言的哪一部分用作标识符等...，但是这些都是超出了此答案范围的细节。 如果您有兴趣，请查看我们的主要传播博客。

一切顺利！

Prakalp。

不用担心Joao Franco -我认为您需要进行我之前建议的设置。

-分配给应用程序的移动目标需要激活[传播用户名]标志，并且SSO机制需要设置为"应用程序到应用程序SSO"。 代理类型当然是Internet。

我所讨论的场景是OData设置，因此此处是相同的。

如果您的子帐户的信任设置是通过身份提供程序（例如ADFS）进行的，则此方法成功进行。

您知道针对移动目的地的SSO机制设置是什么吗？

感谢和亲切问候

菲尔·库利