Siteminder SSO not protecting ASP.NET MVC site - asp.net-mvc-2

I have site minder installed on IIS7 and I am running ASP.NET site on the sever. It appears that Site minder SSO fails to protect ASP.NET MVC requests. It appears that all ASP.NET requests are processed by ASP.NET isapi filter which prevent Siteminder isapi filter from running. How can I make siteminder SSO work for protect my ASP.NET MVC site? Is there a way I can force isapi filter for Siteminder SSO to be loaded before ASP isapi filter?

The solution for us was to list the SiteMinder web agent ISAPI handler followed by the MVC ISAPI handler, in that order, in your web.config file.
I posted the code fragment here.

Have you tried ordering ISAPI filters in IIS? I have not done it with Win2008 IIS7, but with Windows 2003, SiteMinder agent installer reorders the filters. You should be able to check it in IIS Manager and reorder. SiteMinder filter should be on the top.

I had the same problem on my MVC-2 site enenthough the virtual folder was protected by siteminder.
Finally figured out what the issue was.
Changed the Application Pool mode to Classic from Integrated and voila! problem solved.

We have the same problem for MVC3 on IIS7 and we need to use Integrated Mode. Our solution is to use combination IHttpModule and Handler (.axd) but it is now uncessary since the new version of siteminder has IIS7WebAgent.dll which is a integrated MODULE instead of ISAPI filter (ISAPI6WebAgent.dll). I tested this and confirmed its working, it was able to protect all our MVC url and we can also read HTTP Header created by siteminder such as SM_USER from the MVC pipeline.
The siteminder version I tested is R12 SP 3. If your planning to use IIS7WebAgent.dll, you need to remove all occurances of ISAPI6WebAgent.dll on "Handler Mappings", "ISAPI & CGI Restrictions" and "ISAPI Filter" on IIS to make sure its not complicting.

Related

Right design for SiteMinder

I have to give my recommendations for an architecture for SSO using Site Minder.
We have few J2EE applications. These J2EE applications are designed to work when http headers have information after authentication by SSO provider. We have kept our applications SSO provider agnostic. This means we only rely on headers from SSO provider. This worked well with RSA as the SSO provider.
Now there is another architecture proposed with SiteMinder. The way request will flow is
SiteMinder with IIS -> Apache Reverse Proxy -> Tomcat Application -> Backend Applications.
To break down we will have
a) SiteMinder with IIS (public facing site)
b) Apache Reverse Proxy ( For routing)
c) Tomcat Application (For routing and a logic for site access based on time)
d) Backend applications
The reason for bringing the new architecture is that all back end applications have code for site access. The site can be down for some time, which is controlled by a property file.
I find this architecture wrong. I do not understand why Apache Reverse Proxy is requried. I would still go with simple architecture with flow as
a) SiteMinder with IIS doing the routing -> Backend Applications(accessing a common service to check whether site can be accessed or not)
Am I missing something?
The Apache reverse proxy would make it easier to load balance between multiple IIS instances. As far as I know to do something similar on IIS you would need to use the ARR (application request routing) module which won't be optimised to work with Tomcat etc.
However, the SiteMinder with IIS does seem an added overhead in your architecture. The Apache reverse proxy also supports SiteMinder agents. Why don't you push for setting up the SiteMinder agent on the Apache proxy and remove IIS completely from the picture. I can think of the following benefits:
Remove one extra layer from the architecture
Remove an extra network hop
Clean up the stack. Apache + Tomcat is very standard in enterprises while IIS + Apache + Tomcat definitely isn't.
Hope this helps
I don't see either the rationale behind the second architecture. The first scenario is a much more common deployment of Siteminder.
Be aware that this kind of architecture potentially opens vulnerabilities (logon bypass notably). See my answer on this question. Those remarks are true for both architectures.

How does CA SiteMinder web agent work with IIS?

Installed SiteMinder web agent(ca-wa-IIS7-12.0-sp3-cr010-win64.exe) in windows server 2008 r2, and IIS version 7.5. There are 2 web sites(A,B) under the IIS server, while the agent only targets to one web site A(select one website during install). I do not have a valid policy server, so input fake IP during configuration of web agent.
Then access A in browser, there is error as expected, but access B in browser, server also returns an error. CA related http modules can be seen registered in A site in IIS. none CA SiteMinder related things in Module or Handler in B site of IIS. so How does CA SiteMinder web agent work with IIS? and is it able to process request event not resisted in IIS? is there a way that only apply SSO to only one website of server with many websites?
That version was buggy. use CR12 if 12.0 SP3 Pollicy Server. If 12.5 or later use the 12.5 or later agent.
that version has the classic 6 embedded and a new module for the new pipline.
this type of question really should be answered with "go take a class, ca has many" because you did not specify a problem and thus there is no real issue to address and assist with.

Deploying Hybrid ASP.NET webform and MVC project on iis7 - MVC Routing does not work

Hi Stackoverflow,
Im trying to deploy a hybrid ASP.Net Webform/mvc-project onto iis7 but the mvc routing does not work.
This is what i have done so far:
Added all required mvc-related dlls.(i have double checked bin-catalog to make sure that everythings there on the deployed installation)
Added MVC wildcard by adding the IsapiModule handler to iis handler mappings.
The Server has .Net-Framework 3.5 SP1 installed.
The web site Managed pipeline mode set to classic
Our project requires the app pool to be running in none-integrated pipeline, but im not sure what MVC requires of the app pool, may i run ASP.NET MVC(2) in a none-integrated managed pipeline?
The web application loads and i want to use the MVC-routing to load javascript but the mvc routing does not responde to the request and instead Webforms gives us a 404-response,
this only happens when the project has been deployed onto the server.
Does anyone has a idea of why the ASP.Net MVC routing does not fire?
Thanks and Best regards,
Mikael
I found the error, the installer did not update production web.config,
so there was some missing mvc-required references,
i used this article to find out what was missing, it describes how to setup a hybrid WebForm/Mvc project in a simple way.
And now im able to run a hybrid webform/mvc-project on iis7 classic without any problem.

How to mention Expire Header and Compression for IIS 6 in web.config

I need to specify the Expire Header and enable Compression for static files such as images, css and js in order to optimize my site. My web app is hosted in IIS 6 with shared server. Since, this is a shared server, so I don't have access to IIS manager. So, the only option, I have is play with "web.config".
Technologies which I am using is Asp.Net MVC 2.0.
Thanks.
Not possible in IIS 6 through Web.config, since config support for such operations were added in IIS7. Ask for assistance from your hosting service provider.

Why is my ASP.net MVC site not serving pages on Windows Server 2008?

Why is my ASP.net MVC site not serving pages on Windows Server 2008? The website is running under an application pool that has the .net framework 4.0 in integrated mode. It serves .htm files with no problem. However, when I try to view any of the MVC pages I get a page saying "Internet Explorer cannot display the webpage." How can I troubleshoot this?
Server 2008 with IIS 7 you need to look at the website in question and go to the HandlerMappings settings. You need to make sure that the .Net mappings are set to enabled.
I found out what the problem was. This was a pain to track down. The server hosts 2 websites. The HTTPS bindings were not associated with the IP address for the website. Instead, the IP binding was set to "All unassigned".
The solution was to associate the HTTPS binding with the website's IP address.