Customize IIS error pages to augment WIA authentication

When you configure SSO (Single Sign-On) in the WCI portal, you’re basically telling the portal to redirect to the /portal/sso/SSOLogin.aspx page, and configuring your SSO product to “protect” that page.  I could write volumes about this topic – and probably will at some point – but for this post let’s consider Windows Integrated Authentication (WIA).

The trick to configuring Windows Integrated Authentication for the portal is to enable Integrated Windows authentication on the “sso” folder like this:

This allows IIS to authenticate the user and pass the username to the portal through the portal session.  But, if the user can’t authenticate for some reason, they may see a screen like this:

While I’ll call out a portal bug any day of the week, this isn’t one of them: the portal is doing exactly what it’s supposed to, and in this case that is NOTHING.  The above error comes from IIS, and the portal never even sees the request to take action on it. [side note: in my last post, I mentioned working on a WebDav fix for Collab; it’s looking like the problems with Windows 7/Office 2010 aren’t Collab’s “fault”, but – like this issue – are the fault of the application server handling the requests.]

Now that we’ve established the issue is with IIS and not the portal, the “fix” is pretty straight-forward.  Just craft a custom HTML error page that redirects the browser back to the portal with this code:


… then, configure IIS to use that error page when the unauthorized message is generated:

This way, if IIS can’t authenticate the user, instead of presenting the error page, it’ll send a redirect to the browser to bounce back to the portal – which will know that it’s already attempted SSO and just present the user with the forms-based login.

Tags: , ,

Leave a Reply