3

我正在使用自定义ClaimsAuthorizationManager在 MVC 中进行授权，但我遇到了问题。

  • 即使我只是在 CheckAccess 方法中返回“true”，所有文件/图像也会被 500 运行时错误阻止，因为：

异常信息：异常类型：NotSupportedException 异常消息：ID1075：如果当前主体 (HttpContext.Current.User) 不是 ClaimsPrincipal，则无法使用 ClaimsAuthorizationModule。在 System.IdentityModel.Services.ClaimsAuthorizationModule.Authorize()

我没有在应用程序的早期更改有关当前校长的任何内容...想法？我被难住了，搜索那个错误什么也没有发现......

<system.webServer>    
    <modules>      
      ...
      <add name="ClaimsAuthorizationModule" type="System.IdentityModel.Services.ClaimsAuthorizationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    </modules>
</system.webServer>


  <system.identityModel>
    <identityConfiguration>
      <claimsAuthorizationManager type="NamespaceFun.CustomAuthorizationManager, NamespaceFun" >
    <policy resource="http://localhost:52606/" action="GET">
    </policy>
      </claimsAuthorizationManager>
      ...
    </identityConfiguration>
   </system.identityModel>


public class CustomAuthorizationManager : ClaimsAuthorizationManager
{      
    public override bool CheckAccess(AuthorizationContext context)
    {   
        return true;            
    }       
}
4

4 回答 4

5

我只是遇到了同样的问题，所以我将我的 web.config 与 WIF 书中的一个进行了比较，结果发现我preCondition="managedHandler"在 add 元素的末尾丢失了，而且您似乎也丢失了它。

MSDN 示例中似乎也缺少它。

正确方法： 

<add name="ClaimsAuthorizationModule" 
     type="System.IdentityModel.Services.ClaimsAuthorizationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" 
     preCondition="managedHandler" />
于 2013-03-18T18:39:36.913 回答
2

它认为我会问一个问题，然后一个小时后自己回答。但这让我困惑了好几天。直到它实际上阻止我完成其他事情，我才不得不深入研究它。

所以无论如何，我所做的很简单。此Microsoft的ClaimsAuthorizationManager示例在提供图像时没有任何问题。 http://code.msdn.microsoft.com/vstudio/Claims-Aware-MVC-523e079b

所以我比较了两个应用程序的 Web.config 文件，发现它们“惊人地”相似。

唯一的区别是我的 Intranet 应用程序在 system.webServer 部分中有这些处理程序：

 <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

我实际上需要弄清楚这些在做什么，但目前，删除它们解决了我原来的问题。

在我看来，WIF 仍然是一个巨大的“黑匣子”。当谷歌搜索错误完全没有返回时，很难采用新技术。

于 2013-03-18T18:06:27.813 回答
1

我实际上认为完全使用索赔授权模块是一个非常糟糕的主意。原因是该模块基于 URL - 但在 MVC 中，所有内容都与路由表或控制器/操作无关。

每当两者不同步时，您的授权策略中可能存在漏洞（加上您已经遇到的静态文件问题）。我实际上更喜欢基于属性的方法——我构建了授权属性（一个用于 MVC，一个用于 Web API）与 ASP.NET 配合得很好：

http://leastprivilege.com/2012/10/26/using-claims-based-authorization-in-mvc-and-web-api/

于 2013-03-19T07:26:52.920 回答
0

就我而言，使用自定义 ClaimsAuthorizationManager 时文件（包括 JavaScript）被阻止的原因是runAllManagedModulesForAllRequests模块标签中的属性：

<modules runAllManagedModulesForAllRequests="true">

这会导致自定义 ClaimsAuthorizationManager 处理所有请求，即使该请求不是针对托管内容的。删除该属性可以解决问题。

于 2015-04-27T03:13:16.803 回答