Question

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

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

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

我没有在应用程序的早期更改有关Current Principal的任何内容......想法？我很难过，并且正在寻找那个没有发现任何错误的错误......

<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;            
    }       
}

Answer 1

我遇到了同样的问题，所以我将我的web.config与WIF书中的一个进行了比较，结果发现我从add元素的末尾开始缺少preCondition="managedHandler"，看起来你似乎是也错过了。

MSDN example似乎也没有。

正确的方式：

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

Answer 2

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

所以无论如何，我所做的很简单。 Microsoft的 ClaimsAuthorizationManager 示例 Not 在提供图像方面有任何问题。 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仍然是一个巨大的“黑匣子”。谷歌搜索错误时很难采用新技术。

Answer 3

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

每当两者不同步时，您的授权策略可能会漏洞（加上您已经遇到的静态文件的问题）。我实际上更喜欢基于属性的方法 - 我构建用于授权属性（一个用于MVC，一个用于Web API），它与ASP.NET一起使用：

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

Answer 4

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

<modules runAllManagedModulesForAllRequests="true">

这导致处理自定义ClaimsAuthorizationManager even if the request was not for managed content的所有请求。删除该属性可解决问题。

ClaimsAuthorizationManager问题

4 个答案: