I'm facing a weird issue with the WIF ClaimsAuthenticationManager. I have registered the custom implementatin of the ClaimsAuthenticationManager in the web.config file:
<identityConfiguration>
<claimsAuthenticationManager type="<namespace>.CustomClaimsTransformer,<assembly>" />
<claimsAuthorizationManager type="<namespace>.CustomAuthorisationManager,<assembly>" />
....
When i run the application in the IISExpress the authenticate method of the ClaimsAuthenticationManager gets invoked. However, it's not being invoked ever since i deployed the application on IIS 7.5.
Is there any configuration that needs to be done?
In the system.webserver part of your web.config do you have the ClaimsAuthorizationModule set,
eg
<add name="ClaimsAuthorizationModule" type="Microsoft.IdentityModel.Web.ClaimsAuthorizationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
For .NET 4.5 you have to add this:
<add name="ClaimsAuthorizationModule" type="System.IdentityModel.Services.ClaimsAuthorizationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
ClaimsAuthenticationManager is not invoked automatically. One needs a plumbing code for that unless they are using WS-Federation.
You can do it in an PostAuthenticateRequest event handler for the HttpApplication.
A good example is located in the http://github.com/thinktecture/Thinktecture.IdentityModel.45 project. Search for ClaimsAuthenticationHttpModule.cs which invokes it.
Related
We are running an ASP.NET 4.6 application with ADFS 2.0. The configuration of the web.config ADFS part was created via FedUtil.exe.
We now have the problem that a second instance of the web application still thinks that the user is not authenticated.
auth on server 1 works only on server 1
auth on server 2 works only on server 2
but..
auth on server 1 cannot be recognized on server 2 and vise versa
In our scenario only a sticky session would work in a load balanced environment. I think it is because of the SessionModule which is required:
<modules>
<add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" />
<add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" />
</modules>
Am I right that the SessionModule stores any data of the auth* into a session, so a shared session would not be possible and we are forced to use sticky sessions?
Would IdentityServer3 or IdentityServer4 solve this issue?
It seems to be that the Microsoft.Identity does not provide SAML Tokens without Sticky Sessions: https://leastprivilege.com/2012/07/12/machinekey-based-session-protection-for-wif/
I created an ASP.NET MVC WebPages application. Works perfectly local. Works perfectly on the server when I install it as a website. However when it is installed as an IIS application (level below another website, using the same application pool) all it does is throwing this exception:
Could not load file or assembly
'System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its
dependencies. The system cannot find the file specified.
Apparently something related to WCF RIA services, which is not used. All I use is Linq to SQL. How is this possible?
Server: Windows Server 2008 R2 with IIS 7.5
Check the web.config of your application if it contains an entry like:
<httpModules>
<add name="DomainServiceModule"
type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</httpModules>
It is located in the <system.web> section.
Theres is also another entry like:
<modules runAllManagedModulesForAllRequests="true">
<add name="DomainServiceModule"
preCondition="managedHandler"
type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</modules>
in the <system.webserver> section.
Remove the entries, then you should not get the exception.
I know it too late, but may be my answer will be useful for some people.
I had similar problem, but no corresponded to IIS.
So, I had web app based on RIA services. This app used separate dll (DAL) which contained some classes attributed by RIA attributes (of course, it had reference to RIA dll). The dll (DAL) was referenced by another app which did not use RIA and raised same error as you mentioned (but only with System.ServiceModel.DomainServices.Server).
This error was raised only during WCF channel creation (ChannelFactory<>). So I suppose WCF should know about all referenced dlls during analyzing of attributes of contract's classes. But I did not found any explanation why WCF don't used only own attributes whithout analizing all of them.
I have an IIS6 running on Windows Server 2003 (x86) and have written a custom handler (Not a handler for 404 errors).
When I try to access the handler by opening in a browser http://localhost/Priority1.Sync/Transfer.p1s, I get error 404 (404 0 in log file). Other pages in the web application work, e.g. http://localhost/priority1.sync/syncservice.asmx
The handler works fine on my IIS7 dev machine.
web.config is setup as follows:
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="GET,HEAD" path="ScriptResource.axd" validate="false" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="*" path="*.p1s" type="MCS.Priority1.Sync.WebServices.TransferHandler, SyncService" />
</httpHandlers>
I have set an application extension for "*.p1s" (Default Web Site>Properties>Home Directory>Configuration>Mappings>Add).
Am I missing something else?
Thanks,
Andy
Do you have the "Verify that file exists" option in your custom handler IIS configuration checked or not?
IIS6 expects a physical file to exist by default. If there isn't one, it won't pass the request on to your handler at all. You need to disable this check, so it will send the request to your handler as expected.
IIS6 and IIS7 are fundamentally different beasts. IIS7's managed pipeline means every request hits your registered handlers, in IIS6 only things mapped to ASPNET_ISAPI.DLL (typically *.aspx and *.ashx and other default ASP.NET extensions) get processed.
You can make your IIS7 dev box behave this way by using the "classic" pipeline for your development app pool for this project.
Another trick to making it work how you expect is to map 404 errors to an ASP.NET page and then you can at least get into your handler.
In all honesty I would look towards upgrading production to IIS7 as it is so vastly more capable it isn't even funny.
If you are registering handlers for IIS 6 then do remember they should be placed in the
<httpHandlers> element of <system.web> section of the web.config not the <system.webServer> section that IIS7 uses.
I have a web service file in my project having a web method which is used for AutoCompleteExtender and which works fine when I debug it from VS.
But when I publish and host it on IIS, it's not working properly.
However, I tested the webservice method directly by typing the URL and it gave the desired output.
Is their a special setting needs to be done in IIS to make it working or any property of AutoCompleteExtender need to be set?
I had this issue as I moved a site from cassini to IIS7.5. After a lot of digging had to add the follwoing to the web.config in the system.webServer section. Hope it helps.
<modules runAllManagedModulesForAllRequests="true">
<remove name="ScriptModule" />
<add name="ScriptModule" preCondition="managedHandler" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</modules>
<handlers>
<remove name="ScriptHandlerFactory"/>
<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</handlers>
After a upgrade from ASP.NET 3.5 to 4.0 I have the same problem and can't get the extender to work. From firefox and firebug I recive a 500 Internal Server Error with the message
System.InvalidOperationException: Request format is invalid: application/json; charset=utf-8.
at System.Web.Services.Protocols.HttpServerProtocol.ReadParameters()
at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
I have tested with the web.config settings suggested by http://msdn.microsoft.com/en-us/library/bb763183.aspx but recive configuration errors.
Try changing the order of the handlers (remove then add). In this example I have removed all but the AJAX/script handler.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<remove name="WebServiceHandlerFactory-Integrated"/>
<remove name="WebServiceHandlerFactory-ISAPI-2.0"/>
<remove name="WebServiceHandlerFactory-ISAPI-2.0-64"/>
<remove name="WebServiceHandlerFactory-ISAPI-4.0_32bit"/>
<remove name="WebServiceHandlerFactory-ISAPI-4.0_64bit"/>
<!--<add name="WebServiceHandlerFactory-Integrated-4.0" ...</handlers>
Its not the problem of IIS or ath. Its a bug actually (I think). In your function in webservice to return the string array please check the parameter names or arguments to the function.
The name of the string parameter must be prefixText and that of int field should be count.
And there must be these two parameters for your functions in the webservice.
like this
[WebMethod]
public string[] getCountry(string prefixText, int count)
{
......
....
return ...
}
I was facing the same problem. AutoCompleteExtender was not working after hosting in IIS 7 Windows Server 2008 R2.
By changing the "Managed Pipeline Mode" of Application Pool from "integrated" to "Classic" worked for me.
This setting can be taken by selecting the application pool -> select Basic setting.
Thank you.
Try...this
go to start>run>inetmgr>
In the connections sidepane..select application pools
select the application pool that u hav assigned when deployed that project into iis(to check that go to sites>in connections pane...and right click on website that u have deployed and select manage website >advanced settings then at the top u wil able to see application pool)
then comeback and select that particular application pool in application pools in connections pane
right click on that particular application pool and select advanced settings..find out process model in that and select identity and browse through it and goto built in account and select local system.......then click ok...and get out of it...
I think it will work..it worked for me.....
Imagine the following solution:
Website ABC.com (not Web Application)
BLL (business logic layer in a seperate assembly)
DTO (dto objects in their own assembly)
DAL (data access layer in it's own assembly as well).
The BLL has a reference to the DAL.
The BLL has a reference to the DTO layer.
The Website project references the BLL.
When one compiles the website project, the following DLLs will appear in the BIN directory:
BLL.dll
DTO.dll
DAL.dll
When one goes to preview the site, an error occurs about not having the necessary assembly references... Now if one right clicks on the website project, Add Reference, and explicitly add the reference to the missing assemblies, it will work fine.
It seems to me like ASP.NET pulls the referenced assemblies of the referenced assembly being added/referenced in the website.
Why does one need to add explicit references to the references of the references... ? Sorry if I'm not wording this correctly or if it confusing.
I think the problem may have to do with using a web site project, as oppossed to a Web Application. I can't remember off the top of my head, but there's something funky about the way web site projects are compiled, as oppossed to web application projects.
Here is a good article on your question Compilation and Deployment.
It has something to do with "WebSites" being compile at runtime. Hopefully the above article will answer your question.
Just tested this scenario today for the project I'm on. You should be just fine just adding your assembly in Web.config as:
<compilation debug="true">
<assemblies>
<clear/>
<add assembly="mscorlib"/>
<add assembly="System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<add assembly="System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
<add assembly="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
<add assembly="System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<add assembly="YourBLLLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</assemblies>
</compilation>
Also your assemblies should stay in the famous ./bin folder of your web site's root.
GL!