The setup: You scaffold code for WS-Federation for MVC 5 using the Visual Studio 2013 tooling. Then everything stops working when you move that code off of your laptop. What happened?
So, you got started with a federated identity provider on your new ASP.net project and everything’s working great, until it gets published to the dev server. Then, nothing works! This can be super frustrating if it happens to you.
You too can even!
Some of the pre generated/scaffolded code you got when filling out sets a reply URL:
<wsFederation passiveRedirectEnabled="true" issuer="https://myissuer/adfs/ls/" realm="https://localhost:44302" requireHttps="true" reply="https://localhost:44302" />
There’s three possible outcomes involved with the reply item in the wsFederation line in your web.config:
- If there isn’t a reply url set, the RP (on the ADFS box) will redirect to the default URL for redirect.
- If you set a reply url that isn’t on the list of redirect urls in the RP you’ll get an error or a default redirect, depending on some other settings
- If you have a reply url set that isn’t the default RP redirect URL AND that url is on the list of redirect urls on the RP, you get redirected to that url.
Since you are a responsible programmer, you won’t do this, right?
<!-- <wsFederation passiveRedirectEnabled="true" issuer="https://myissuer/adfs/ls/" realm="https://localhost:44302" requireHttps="true" reply="https://localhost:44302" /> --> <wsFederation passiveRedirectEnabled="true" issuer="https://myissuer/adfs/ls/" realm="https://localhost:44302" requireHttps="true" reply="https://mydevelopmentserver:44302" />
Use a XML transformation to automate configuration to work with development.
For more information, check out WSFederation Authentication Module Overview