问题标签 [federation]

我的团队开发环境基于本地数据库 (SQL Server)，现在我需要将我们的应用程序迁移到基于 SQL Azure 联合。有什么方法可以在本地环境中“模拟”SQL Azure 联合？或者我们的开发环境应该改变吗？

我有一个 WinForms 应用程序，其中包含从使用 WS2007FederationHttpBinding 的 WCF 服务生成的服务参考。我不明白为什么以下不起作用。

我的 WinForms 应用程序正在调用使用 Thinktecture.IdentityServer 的 WCF 服务，该服务设置为处理 BearerKey 类型令牌。

从我的客户那里，我只需获取一个有效的访问令牌，然后进行以下调用：

以下是服务参考的 winforms 客户端 app.config：

当我尝试执行服务调用 (svcRef.GetClaims()) 时，我收到此错误：

“未指定安全令牌颁发者的地址。必须在目标' https://identity.MyCo.com/issue/wsfed '的绑定中指定明确的颁发者地址，或者必须在凭据中配置本地颁发者地址。”

这个错误很蹩脚，而且令人困惑，似乎在配置中指定了一个发行者！

最后，我知道 WCF 服务和身份服务是有效的，因为这一切都可以使用自定义 ChannelFactory 正常工作，也使用完全相同的方法来应用令牌：

var channel = factory.CreateChannelWithIssuedToken(token);

但我的要求是使用生成的ServiceReference。:(

我知道这tenantid需要在您想要在 SQL Azure 联合中联合的所有表中。但是您真的需要将外键约束本身更改为具有tenantid+actualPrimaryKey吗？或者你可以只保留actualPrimaryKey实际外键约束中的唯一字段吗？

我读到“除此之外，任何包含引用联合表的外键约束的表也需要TenantId添加并成为联合表。例如，假设我们有一个 Orders 表，我们决定制作一个联合表”在这篇博文中。

我正在使用基于 WIF (.NET 4.0) 的自定义 STS，目前仅用于 SharePoint 应用程序。我在按预期工作的 HTTP 模块中设置了滑动到期代码，但安全令牌的生命周期为 10 小时（默认生命周期）。

最初，我认为这可以由 SPSecurityTokenServiceManager 设置。然而，这并没有改变什么。（PowerShell 片段）

我无法设置 SessionSecurityTokenHandler.DefaultLifetime，因为它是只读的并设置为 10 小时。

SecurityToken.ValidTo 只有一个 getter 而不是一个 setter。

我还注意到，在ValidTo 中FederatedAuthentication.SessionAuthenticationModule.CreateSessionSecurityToken，默认的 ValidTo 属性设置为 ValidFrom + 默认令牌生命周期。我可以看到设置 SecurityToken.ValidTo 的唯一方法是创建安全令牌时。这是否意味着我需要实现一个自定义 SecurityToken 类，或者在 WIF 堆栈中的某个地方我可以拦截令牌的创建？到目前为止，我似乎只找到了以下事件处理程序，FederatedAuthentication.SessionAuthenticationModule.SessionSecurityTokenCreated但此时令牌已经创建，我可以在其中访问令牌，但正如预期的那样，该SecurityToken.ValidTo属性只是一个 getter。

<microsoft.identityModel />配置部分似乎也没有为此设置。有一个 persistenLifeTime 设置，但这仅适用于写入磁盘的 cookie。

此外，为了使加密/解密与服务器无关，加密使用证书。为此，我以编程方式将会话安全令牌处理程序添加到我的联合提供程序的 Global.asax 中。我只提到这一点是因为我想知道，如果我需要自定义SecurityToken.ValidTo，我是否可能需要创建一个自定义安全令牌处理程序类，或者我目前在 Global.asax 中是如何做到这一点的，我需要看看其他地方解决SecurityToken.ValidTo问题？

如果我创建一个自定义 securityTokenHandler，我看到我可以指定一个生命周期，但这看起来就像我在上面的 Global.asax 中尝试的那样， sessionHandler.TokenLifetime = ...

我只能假设我错过了一些明显的设置，或者是我唯一的行动方案来定制以获得SecurityToken.ValidTo我需要的？

假设一个表有一个类型为or的主键 ( CustId) 。我们想根据是奇数还是偶数将该表分片成一个联合表。IEintlongintOrderId

联合“主键”= (Fed_key, CustId)whereOrderId是类型int或=如果 CustId==偶数，longint如果CustId==奇数。Fed_key01

例如：

这基本上给了我们 2 个联邦成员（又名分区）。稍后我们可能会将 Fed_key 分组为 (1,3,5)、(2,4,6) 和 (7,8,9,0) 以用于其他分区。我们认为我们不需要超过 5 个分区。

问题：如何将上述逻辑表达到 Azure SQL？我想这需要在联合创建或联合表创建期间完成。

我正在使用 MVC4 c# 并合并了一个本地安全令牌服务 (STS)。用户调用实际的网址，他们被被动地重定向到 STS 登录。当他们成功进行身份验证时，他们会被重定向到他们应该去的地方，这些都在重定向到 sts 的 URL 中进行了 urlencoded。

注销后，我们调用：

在我们的应用程序的桌面版本上，一切似乎都运行良好。用户返回 STS 登录页面，URL 显示 wlogin1（以及许多其他内容），并允许用户再次登录而不会出现问题。该 url 与它们第一次被重定向到 STS 时完全相同。完美，这就是我想要的。

现在，当在移动设备上使用完全相同的域/控制器/方法时，它只使用 jQueryMobile 和不同的局部视图，注销似乎工作并且用户被带回 STS 登录。然而，这一次，URL 只显示了从用于注销的移动 actionLink 实际调用的域/控制器/方法。当用户再次尝试登录时，登录总是不成功，因为此链接不适用于 sts 登录。

关于如何解决这个问题的想法，或者有什么问题？如果您需要任何澄清，请告诉我。谢谢！

我有 Sharepoint，它使用 adfs 配置了基于声明的身份验证。ADFS 配置为使用第三方声明提供程序信任。因此，当用户访问共享点时，他会通过 adfs 重定向到第三方身份提供者登录页面。此身份提供者 (IdP) 将 saml2 令牌返回给 adfs，然后 adfs 将用户重定向到共享点。

问题是第三方 IdP 被配置为仅返回特定的 saml 属性（声明）。我需要配置 ADFS 以了解此特定属性。

自定义 saml 属性如下所示：

如何在 ADFS 中使用此声明，然后将其发送到共享点？

谢谢。

我使用 Azure SQL 联合来存储用户。正如我在本文中所读到的，生成分布式联合密钥的最佳方法是使用 GUID。我认为向用户显示 GUID 对人类不友好，所以我希望用户也有 1、2、3、4、5 等 ID。现在我计划在联邦根数据库中有一个表来存储顺序 ID 和联邦密钥。还是有更好的方法来实现这一目标？

我正在考虑开发一个使用 REST 公开服务的应用程序。这些服务将通过浏览器和非浏览器客户端访问。我预计会有许多由不同团体拥有和管理的软件安装。我想让一个系统的用户能够访问另一个系统上的服务。它们不会共享相同的身份存储。我希望用户可以对其实例进行身份验证，然后使用令牌向其实例和远程实例发出请求。这似乎是 JSON Web Tokens (JWT) 的一个很好的用途。每个系统都需要配置为相互信任由证书签名的令牌。

我已经读到这可以使用带有 JWT Bearer 令牌的 OAuth 来完成，但这似乎比需要的开销更大。为什么将不记名令牌交换为访问令牌而不是仅使用不记名令牌？我质疑 OAuth 是否合适，因为它不是控制系统是否可以访问用户的数据，就像网络上的许多示例一样，而是用户是否可以访问存储在系统中的数据。

问题的下一部分是确定如何创建这些 JWT 令牌，看起来像 WS-Trust STS 这样的东西是合适的。我还没有看到任何简单的，只是验证用户并返回令牌。可能还支持延长令牌的到期时间和令牌的验证是否有用？

过去，我能够使用带有 WS-Security 和 SAML Assertions 的 SOAP 来启用这种类型的功能。我想看看是否可以使用 REST 和 JWT 令牌来完成相同的操作。网上有很多帖子建议不要使用自己的安全框架，所以我有点犹豫要不要继续前进。我看到微软添加了处理程序来保护使用 JWT 令牌的服务，所以他们似乎看到了这种方法的一些价值。

有没有人了解以符合标准且简单的方式为 REST 服务完成这种身份联合的方法？

这种情况与 Wiktor Zychla 提出的问题非常相似，请参阅如何在与 ADFS 2.0 联合时正确设置超时

我们遇到了相同的行为，ADFS 愉快地将用户重定向回 Sharepoint 站点并重新创建 FedAuth cookie，即使 ADFS 应该提示输入凭据 - 我们希望用户在一段时间的空闲时间后重新进行身份验证。基本上看起来会话总是在滑动。

我们已禁用持久性 cookie，因此当会话通过关闭浏览器结束时会删除 FedAuth cookie，因此在关闭所有浏览器窗口并启动新会话后，用户被迫重新进行身份验证，这样才能正常工作。

据我了解，ADFS 管理单元中的 Web SSO 生命周期设置控制用户需要在 AD FS 上重新进行身份验证的时间（再次输入他的凭据）。Tokenlifetime 和 LogonTokenCacheExpirationWindow 一起控制，Sharepoint 何时应重定向回 AD FS 以更新 FedAuth cookie。

以下是来自http://msdn.microsoft.com/en-us/library/hh446526.aspx的引用：

要强制用户在重定向回 ADFS 时重新输入其凭据，您应该将 ADFS 中的 Web SSO 生命周期设置为小于或等于 SAMLtokenlifetime 减去 LogonTokenCacheExpirationWindow 的值。

所以，我们做了以下工作：

1. 设置 SAML 令牌的生命周期

2.设置LogonTokenCacheExpirationWindow（并禁用持久cookie）

3. 调整后的 Web SSO 生命周期：在 AD FS 2.0 管理控制台管理单元中为 5 分钟（在 Powershell 中运行 Get-ADFSProperties 正确返回 SsoLifetime：5）

因此预期的结果是：

1. 用户开始一个新的会话，请求网站
2. 浏览器重定向到 AD FS，用户输入凭据，浏览器重定向回 Sharepoint 站点，生成 FedAuth cookie
3. 用户保持空闲 10 分钟（以确保会话滑动期已过）
4. 用户在 Sharepoint 中请求另一个页面，浏览器被重定向到 AD FS
5. 由于 Web SSO 生命周期为 5 分钟，并且如 msdn 文档中所述，小于 SAMLtokenlifetime 减去 LogonTokenCacheExpirationWindow 的值（SAMLtokenlifetime - LogontokenCacheExpirationWindow = 6 分钟），AD FS 提示用户输入凭据，用户输入凭据，并且浏览器是重定向到请求的 Sharepoint 页面并重新创建 FedAuth cookie。

当前实际行为（步骤 1-4 类似）：

(5.) AD FS 不提示输入凭据，浏览器被重定向到 Sharepoint 页面并重新创建 FedAuth cookie。

所以 - 对我们来说，无论我们做什么，AD FS 会话似乎都不会过期。如果我们创建了将 LogonTokenCacheExpirationWindow 值设置为高于 SAMLtokenlifetime 的错误配置（例如，LogonTokecacheExpirationWindow = 8 和 SAMLtokenlifetime = 7），我们会得到 Sharepoint 和 AD FS 之间循环的预期行为。

如果用户在一段时间内保持空闲状态，我们正在拼命寻找解决方案来正确终止会话。

我们还尝试了以下配置更改（根据http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/802b1bb6-cda3-4470-a0d1-ee709d5c4b7c/上的指南）：

尚未对 Global.asax 进行任何更改。

据我了解，我们已经根据文档配置了所有内容，但是我们不能强制用户重新进行身份验证。任何指出配置错误的帮助表示赞赏。