So a few disclaimers prior to this post –
- This was a unique set of circumstances and was only ever meant to be temporary. I don’t know what the effects of it would be long term.
- I’m not a SharePoint developer and there was probably a better/smarter way of doing this.
- I can’t speak to this being a best practice, for all I know this is the way you’re supposed to do things and I’m wasting everyone’s time. That being said the names of have been changed to protect the innocent, err.. guilty..
I ran into a situation the other night where a requirement had come up to change the default authentication provider on a SharePoint web application from ADFS to FBA. I won’t go into the details of the requirement but it came down to the customer not wanting to continue supporting ADFS (even though it was working), and wanting some additional features that they felt would be better supported using FBA. Their goal was to implement FBA side by side with ADFS and run both during a transition time while users were converted between authentication types. My job was to provide platform support for the project which included deploying the developer’s solutions to staging and production.
When ADFS was the only authentication mechanism on a web application after hitting the front page of the site you were automatically redirected to the ADFS sign in page which was located on a different server (the ADFS proxy) and had a different URL. Once the configuration changes and solutions were implemented to support FBA when you hit the front page of the site you were presented (as intended) with a page at https://sharepoint.company.com/_login/default.aspx which allows you to pick the authentication provider you want to use.
Unfortunately this surprised the developers who had been testing both authentication types by just hitting a direct url for each. Now when you implement FBA you can build a custom page and set that page as the custom sign in url in central administration. But let’s say you want to continue having users be directed to the ADFS sign in page without being prompted to choose an authentication type. You can’t set the custom sign url to be a page/site that isn’t part of the web application you’re currently on.
So if your ADFS proxy site is at https://adfs.company.com/login.aspx and your SharePoint site is https://sharepoint.company.com you won’t be able to set the custom sign in page to https://adfs.company.com/login.aspx. SharePoint just won’t let you do it. But!! Before you frantically create some redirect code and edit /_login/default.aspx dig around a little in IIS and you will discover a set of directories with default pages for each authentication type.
The one we wanted was @ /_trust/default.aspx. Setting the custom sign in page in Central administration to /_trust/default.aspx allowed us to bypass the authentication selection page and send users directly to the ADFS proxy site.
Now the developers could continue testing in the staging environment on the FBA login and the ADFS login without the pesky prompt to choose an authentication type. Hopefully someone finds this to be useful.