问题标签 [thinktecture-ident-model]

我发现 Microsoft 的Claim-Based Authentication实现并没有真正达到真正的 Claim-Based 设置的预期，而且我似乎ThinkTecture在替换Web API implementation方面做得很好。

我想知道是否有人有指南或博客文章供人们从 AccountController 的 VS2013 的默认 SPA 模板迁移到 ThinkTecture 方法。

我也喜欢默认的 Microsoft Web API AccountController，它将为 AspNetUsers 和 Roles 创建表，但我不确定 ThinkTecture 是否做同样的事情。

我想我对ThinkTecture拥有的所有存储库都有些困惑。是否有人对使用什么、、、或 有可靠IdentityServer的IdentityModel.45指导AuthorizationServer？

我只是想放弃整个 Microsoft 方法并开放以使用正确的真正的基于声明的方法，但EF6 migrations在身份表、要使用的项目或如何放弃整个 AccountController 方法方面我有点需要帮助在 VS2013 的 SPA 模板中。我查看了Dominick 的博客，它似乎非常好，但我还没有找到有助于从 Web API 方法转变为 ThinkTecture 思维方式的帖子。

I have an ASP.NET MVC web app which is utilizing claims-based authorization via WIF and Thinktecture.IdentityModel. However, rather than just intercepting the unauthorized request, I'd like to trim my navigation menus to only display the links accessible to the current user.

My initial thoughts are to accept a list of actions (ActionResult, ActionLink, route value dictionary, not quite sure yet) and execute my custom ClaimsAuthorizationManger.CheckAccess routine. In order to do this, I need to generate an AuthorizationContext, however, I'm not sure if the framework utilities (or preferably abstractions) creating the context are accessible. Anyone know if this possible? Or, if I'm going about this all wrong, what do you suggest?

Thanks and happy holidays!

我们正在使用 ThinkTecture 的 MVC ClaimsAuthorizeAttribute 控制对应用程序资源和操作的访问，并希望能够使用 Moq 包含一些单元测试覆盖率。

理想情况下，我想编写一个测试，请求一个控制器操作，其中包含：

...以便在执行测试期间进入我们的 AuthorizationManager 的 CheckAccess 覆盖方法。

我们的 CheckAccess 覆盖只是从传入的 AuthorizationContext（“operation_x”和“resource_1”）获取操作和资源，并确定 Principal 是否具有资源/操作组合作为声明，如果找到匹配项则返回 true。

测试将根据我们的 CheckAccess 覆盖的结果通过或失败。

我在网上找到的大多数示例都是关于单元测试自定义授权属性或测试控制器操作是否已被 AuthzAttribute 修饰。测试 ThinkTecture 的 ClaimsAuthorize 属性的示例似乎并不多。

甚至有可能实现我所描述的吗？如果有，请指教！

谢谢

我正在寻找一种方法来使已发给消费者的令牌无效或删除。

场景是当用户的密码被更改时，我们要确保所有已发行的令牌都不能再被使用。

我正在使用 Thinktecture IdentityServer 和 WCF 服务设置 SAML2 STS。这个想法是让 Thinktecture 提供随后在 WCF 服务中使用的断言。

现在，我使用 SAML 11 Assertions 运行良好 - urn:oasis:names:tc:SAML:1.0:assertion

断言是这样的：

现在，要求是使用 SAML2，而不是以前的版本。所以在 Thinktecture 中改变 Token 类型很简单，新的 Assertion 可以很好地生成，并且可以很好地被客户端选中。

新的 SAML2 断言：

但是当我们尝试通过传递新的断言来使用 WCF 时，我们得到了异常：

• XmlException：无法从具有 BinarySecretSecurityToken 的“urn:oasis:names:tc:SAML:2.0:assertion”命名空间的“Assertion”元素中读取令牌，并带有“”ValueType。如果此元素预计有效，请确保将安全性配置为使用指定名称、命名空间和值类型的令牌

这是 WCF web.config 的摘录：

那么我们做错了什么？

首先让我说我已经浏览了所有类似的帖子，但没有解决我的问题。我还排除了服务器端没有问题，因为我收到了正确的响应标头，至少如 Fiddler 和 Chrome 开发工具中所示。

我正在使用Thinktecture.IdentityModel并使用 jquery 在客户端进行身份验证，如下所示：

这是我得到的痕迹：

* 预检 CORS 请求 *

预检响应

实际的 AJAX 请求

AJAX 响应

请注意跟踪的最后一行，它来自 Fiddler 选项卡上的 TextView，表明服务器调用成功。我可以确认服务器调用是成功的，因为我调试了服务器端代码并​​且到达了返回该输出的代码并且没有抛出任何错误。任何想法如何使它工作？

（我很抱歉在这里和github上都发布了这个问题，但我真的需要帮助......）

使用 Thinktecture.IdentityModel.45 进行身份验证时，我无法启用 CORS (System.Web.Http.Cors)。

我的令牌端点有问题，我使用的是默认的“/token”。

发生的情况是，当调用 /token（从 javascript 客户端）时，浏览器发出 2 个调用，即“OPTION”调用和“/token”资源的“GET”调用。我正在使用一个简单的 PolicyProviderFactory 只是为了能够检查请求是否获得了正确的 CORS 策略并且它只是返回

第一个 OPTION 调用有效，GetCorsPolicyProvider 被命中。另一个调用有效，但 GetCorsPolicyProvider 没有被命中，结果是服务器返回 200 OK 并包含所有正确的标头等，但是内容响应为空。

我需要在路由配置中为令牌资源添加以下内容，否则我会得到“未找到”。

在所有其他请求上，OPTIONS 和 GET 都会调用 CORS 策略提供程序，并且一切正常。我已经调试了 thinktecture.identitymodel 和正确的响应，返回了正确的令牌。

/token 资源的 GET 方法不会调用 CORS 策略提供程序。但为什么呢？CorsMessageHandler 已加载，但从未被调用。如何判断请求是否会触发 CORS/CorsMessageHandler？

诊断跟踪：

身份验证配置如下所示：

目前，我正在使用 Thinktecture 包为我的 MVC 4 应用程序提供 CORS 支持。在为方法添加输出缓存属性时，CORS 支持将丢失，因为 HTTP 标头可能已被缓存，并且 ORIGIN 未针对请求进行修改。我知道我可以使用内存缓存，但它更乏味。

我有一个 Web 应用程序，其中包含浏览器提供的 javascript 应用程序和 Android 手机应用程序使用的服务。

javascript 应用程序使用 System.IdentityModel.SessionAuthenticationModule cookie 进行身份验证，移动应用程序在 Authentication 标头中使用 JWT 令牌。

我可以将应用程序配置为使用 System.IdentityModel.SessionAuthenticationModule 和 cookie 工作或 thinktecture AuthorizationHandler 和令牌工作，但我不知道如何让它们同时工作？

这个答案Thinktecture IdentityModel AuthenticationConfiguration Mapping for Cookie - how？表明这是不可能的，但它似乎使用的是自定义 cookie 而不是FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(token);

在 WIF 中使用带有会话身份验证模块 (SAM) 和 Thinktecture IdentityModel 的滑动会话时，如brockallen 的博客中所述。颁发并写入 cookie 的会话安全令牌已根据需要扩展“有效”，并相应地设置 cookie。

但是，序列化为当前声明 Identity 的 BootStrapToken 仍然是旧的，带有可能过期的令牌。当出于不同原因（其中可能是实现“穷人”的委托）尝试使用引导上下文令牌时，这会导致问题。

用新发行的令牌更新引导令牌的最佳方法是什么？