Recently I needed build a solution that made it possible for editors to log in to Episerver as both “local SQL users” and AD users, using ADFS. I didn’t have much experience with ADFS, Federated security, Claims-based identity or OWIN. So, it was a steep learning curve for me. I wasn’t able to google a solution, so I reached out to Dan Matthews, who seemed to know a bit about these things. Dan was extremely helpful, and pointed me in the right direction. In return I promised to blog about the solution. Only problem was I didn’t have a blog…
Hence the birth of this blog 🙂
In this blog post I explain the ADFS part of the solution (second part here). At time of writing I was using Episerver 10.8.0 and ADFS 2.0.
Configuration of ADFS server
It took me a while to find out how the ADFS server should be set up. Since I basically didn’t know anything about ADFS, I didn’t really know what too look for. This blog post helped me a lot. Once I knew a bit more, the Microsoft documentation also helped.
Unfortunately I can’t show any screen-shots since I don’t have access to the ADFS server myself. But what you need to do is:
- Forms Authentication for extranet users needs to be enabled. You’ll find the setting under “Authentication Policies”.
- Create a new “Relying Party Trust”. Add the Url to your web site as both a “Relying party identifier” and a “WS-Federation Passive Endpoint”. Note that the Url needs to include correct prefix and slash at the end.
- Find out the “ADFS Metadata Address”. Default address is https:///FederationMetadata/2007-06/FederationMetadata.xml.
- The identity returned must include the claims needed by Episerver: “Name” and “Role”
When creating a Relying Party Trust you can add multiple Relying party identifiers. At first I added one for every environment we used (dev, test, production etc.). And then added the same Urls as WS-Federation endpoints. But when using that setup, after signing in, the user was always redirected back to the first (default) WS-Federation endpoint. It didn’t help that I in my code added the Wreply parameter. Googling the issue told me that the Wreply parameter was ignored by the ADFS server when using WS-Federation… So, I ended up creating a Relying Party Trust for every environment.
Also note that when Episerver synchronize the identity returned from ADFS, it saves the Name claim as username. That means that it is probably a good idea to use the username (nameidentifier) in ADFS as the value for the Name claim.
Setting up my local dev environment
After enabling SSL in visual studio the URL for my local development environment was something like https://localhost:44312. The ADFS server didn’t accept “localhost” as domain for a Relying party identifier. So, I needed to use a custom URL: https://mylocaldev.com:44312. To be able to use a custom domain for your local (IIS Express) environment you need to
- Add the domain to your hosts file.
- Add the domain as a binding in your IIS Express config file (you’ll find it in <path to your VS-project>\.vs\config\applicationhost.config).
Note that you need to run Visual Studio as administrator when having multiple bindings for IIS express.
All developers working with this solution need to use the same custom domain and SSL port (unless you create one Relying Party Trust for every developer). To change the SSL port used by IIS Express, you need to manually edit the IISExpressSSLPort-value in the .csproj file.
The actual coding to get this working was the simpler part. I basically followed the steps and used the code from Episerver´s Federated security guide
Other resources that might be helpful