CODEWITHSUNDEEP
asp.net-mvcauthorizationwif
Steve
Steve

Reputation: 1798

ClaimsAuthorizationManager issues

I am using a custom ClaimsAuthorizationManager to do Authorization in MVC, but I am running into an issue.

Exception information: Exception type: NotSupportedException Exception message: ID1075: The ClaimsAuthorizationModule cannot be used without the current principal (HttpContext.Current.User) being a ClaimsPrincipal. at System.IdentityModel.Services.ClaimsAuthorizationModule.Authorize()

I am not changing anything regarding the Current Principal earlier in the application... Thoughts? I am stumped and searching for that error reveals nothing... 

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

Upvotes: 3

Views: 4252

Answers (4)

Gani
Gani

Reputation: 1

In my case, the reason why files (including JavaScript) were being blocked when using custom ClaimsAuthorizationManager was because of the runAllManagedModulesForAllRequests attribute in modules tag:

<modules runAllManagedModulesForAllRequests="true">

This results in processing all requests by the custom ClaimsAuthorizationManager even if the request was not for managed content. Removing that attribute solves the issue.

Upvotes: 0

Shahin Dohan
Shahin Dohan

Reputation: 6882

I just had the same problem, so I compared my web.config to one in the WIF book, and it turns out I was missing preCondition="managedHandler" from the end of the add element, and it seems you're missing it too.

It also seems to be missing from the MSDN example.

Correct way: 

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

Upvotes: 5

leastprivilege
leastprivilege

Reputation: 18482

I actually think it is a really bad idea to use the claims authorization module at all. The reason is that the module is based off URLs - but in MVC everything is keyed off the routing table or controllers/actions.

Whenever the two get out of sync you might have holes in your authorization policy (plus the issue with static files that you already encountered). I actually prefer the attribute based approach - I built to authorize attributes (one for MVC, one for Web API) that play nice with ASP.NET:

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

Upvotes: 1

Steve
Steve

Reputation: 1798

It figures I would ask a question and then answer it myself an hour later. But this had me perplexed for multiple days. It wasn't until it was actually blocking me from getting other stuff done that I had to dig into it.

So anyway, what I did was pretty simple. This example of the ClaimsAuthorizationManager from Microsoft does Not have any issues serving up Images. http://code.msdn.microsoft.com/vstudio/Claims-Aware-MVC-523e079b

So I compared the Web.config files from both applications and found out they were 'amazingly' similar.

The only difference is that my intranet application had these handlers in the system.webServer section:

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

I actually need to figure out what these are doing, but at the moment, removing them solves my original issue.

WIF is still a giant 'black box' in my opinion. Its hard to adopt a new technology when Googling for errors returns absolutely nothing.

Upvotes: 2

Related Questions