IIS 7.5 Siteminder is not protecting ASP.net MVC requests

Question

We are trying to use ASP.Net MVC with Siteminder for Single Sign on. This is on Windows Server 2008 R2 with IIS 7.5. Siteminder Agent version 6QMR6.

Problem : Siteminder protects physical files that are exist. And it is not protecting the folder when we try to access a non existed file. It must redirect to login page even if the file doesn't exist when the user is accessing a protected folder.

How to configure in IIS 7.5 that Do not verify a file exist, before authentication by siteminder. SiteMinderWebAgent is a Handler(WildCard Script Map) we created using the ISAPI6WebAgent.dll

How to Protect ASP.Net MVC Request with Siteminder? (Added this as My previous question did not solve the problem). MVC Request shows up in IIS Log but not in Siteminder log.

Update : Microsoft Support says currently IIS7.5, even in earlier versions doesnt support wildcard mappings on any two Isapi Handlers with * wild card. Currently in my case Siteminder has * wildcard and asp.net mvc (handler is aspnet_isapi) has * wildcard to handle the reqeusts. Ordered priority doesnt work in the wild card mappings case with Just *. Did not convinced with the answer but will wait till tomorrow for them to get back.

Solution 1

Here is the explanation and workaround from Microsoft on ASP.Net MVC with Siteminder.

A request can be executed by any ONE handler, but can be worked upon by multiple modules. When a request comes in the URLRoutingModule routes the requests to the handler for MVC (if a map for it exists in the routing table as defined in the Application_Start event of the Global.asax), and the SiteMinder handler is never invoked. Since only one handler can execute the request and in this case it should be the MVC handler SiteMinder login page never comes up. One handler executing a request is a by design behavior.

Suggested Workaround:

i) In the AuthenticateRequest method in Global.asax check to see if the SSO session cookie is there in the request.

ii) If the cookie is not there, then redirect to another SSO login page.

iii) The login page responsible for authentication should not be in the MVC routing table.

iv) If a request for a page that is not in the MVC routing table comes in, the SiteMinder will come into action as the URLMappingsModule will not route this to the MVC handler as expected.

v) On this page, after authentication, the user can be redirected to the main URL that was requested earlier. As this time we have the SSO session cookie, so the request will not be redirected in the AuthenticateRequest and would be responded to by MVC.

We are following this work around. This must be implemented with caution as there is a chance that the Siteminder cookie could be invalidated but not checked by siteminder as the request wont go thru siteminder for MVC requests.

Solution 2

Upgrade to the latest version of Siteminder, remove all the ISAPI, move from ClassicMode to IntegratedMode as MVC / WEB API needed then use just CASiteMinderWebagentModule

and forget about the whole stupidity around hacking MVC/Webapi because ISAPi and siteminder, MVC/Webapi was never designed to run under ClassicMode.

Comments

[Jonathan Sayce]

Hi HariM - did you ever find a more satisfactory solution to this problem or are you still using the workaround you proposed in your answer?

[HariM]

Thanks you. I have done that. I dont see Reqeust Restrictions for "Wildcard Script Map". But the PathType is set to Unspecified. In this case seems like Asp.Net MVC is taking the request even before Siteminder processing the request and responding back to client. I see a Log for MVC request in IIS logs but not in Siteminder logs.

[Scott Forsyth]

It sounds like it's setup correctly to handle different extensions. You can reorder the handlers to have the process in the opposite order. They load from top to bottom.

[HariM]

When I see the ordered list, Siteminder handler shows up first in the list.

[HariM]

Also, to process MVC request we have added <modules runAllManagedModulesForAllRequests="true"/> to web.config file under system.webServer.

[Scott Forsyth]

It's possible that they need to load in the other order. You can also try Failed Request Tracing. That will show you exactly what loads, in which order and if there is a match for the path or not.

[Raj]

Doesn't work for me. Did you complete any additional configuration other than this?