If you have worked with ADFS 2.0 or other claims based security models Azure’s Access Control Service (ACS) should not seem all the new to you. It is basically Azure’s hosted Secure Token Service (STS).
Recently I have been building an MVC 3 application and did not want my application to be forums protected. My personal opinion is that no one wants to create one off logins on the web anymore. To solve this I decided to use MVC 3 with ACS. Adding ACS to your MVC 3 project is not very hard and is explained in a few blogs on the net (here is a good one). You basically just use Visual Studio’s “Add STS” functional like you would for any other STS.
When you add the STS to your project it updates your web.config with information it needs for federation to work. By default it protects your entire website. This means you cannot even hit the login page without signing in. But what if I want unauthenticated people to read parts of my website, like the homepage? Well this is what I had to figure out. In the end it is pretty simple but given my newness to MVC and experience with using ADFS to protect WCF services I went down the wrong direction for awhile.
Your web.config is updated by the STS fedutil with the following information.
<location path="FederationMetadata"> <system.web> <authorization> <allow users="*" /> </authorization> </system.web> </location> <system.web> <authorization> <deny users="?" /> </authorization>
This does two things. 1) It tells the website not to protect the path to the federationmetadata. This allows the STS to get the information it needs. 2) It tells the site to deny access to all unauthenticated users (<deny users=”?”>). Since that node is not inside a location node that directive applies to the entire site, minus any location node directives.
Now if you want to unprotect certain areas of your site you might think you can just use some additional location nodes. Well this will send you down the wrong path with MVC. With a standard ASP.net or WCF app this could work but MVC adds a framework that causes this so it doesn’t work very well. In MVC 3 authorization is handled via the “authorize” attribute added to methods in controls or the controller class. In order to make sure you don’t open security holes this is really where you want to keep that control. If you add this attribute to a controller method, and it fails, the requests will fall into the Windows Identity Framework pipeline. The user will then be pushed to authenticate, IF, you change your config file a little.
Since the fedutil setup your web.config file to protect your entire site the website configuration will pick up the authorization requirement before it gets to any controller actions. So we need to change our web.config so it is not protecting anything. Update your web.config so it looks like the following:
<location path="FederationMetadata">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<system.web>
All we did was remove the authorization deny nodes from the web.config. This now opens up your entire site so nothing is protected by ACS. To start locking down your site you need to go into each of your controllers and start applying the Authorize attribute. For each method that has this attribute applied the site will fail over to your ACS (via the WIF pipeline) and request the user to login (unless of course they are already logged in).
Here is what a HomeController might look like:
public class HomeController : Controller { public ActionResult Index() { ViewBag.Message = "Welcome to MVC 3!!"; return View(); } [Authorize] public ActionResult About() { return View(); } }
Notice how the About method has the authorize attribute. Now when this method is called (in the standard MVC 3 default template this is called via clicking on the about link in the navigation) the user will be directed to login if they have not already.
You can also apply the attribute to the entire controller if everything should be projected.
Comments