4.6 Adding WebForms authentication

So far we’ve been demonstrating Xomega features using a Blazor web application. However, our initial Xomega project template also included a client project AdventureWorks.Client.Web for an ASP.NET application using the classic WebForms framework. We have been adding WebForms controls to our model, and the WebForms views have been generated from the model and should use the same view models, data objects and services as the Blazor views. Therefore, to run the WebForms application we just need to implement WebForms specific authentication and authorization logic.

Let's make the AdventureWorks.Client.Web project a startup project for the solution, expand the generated LoginView.ascx under that project, and open the nested LoginViewCustomized.ascx.cs file that was also generated for us. We will start by adding an override for its OnInit method, where we will change the text of the Save button to be "Login" and update the width of the view panel. Unlike Blazor, with WebForms you have access to all the generated controls, so you can programmatically update them however you need. Here's a picture that illustrates this.

Next we’ll add an OnPreRender method, where we will handle the case when an already authenticated user was redirected to this view if they were not authorized to access the view they were trying to open, as follows.

As we mentioned before, the generated code for the Save button, as well as the Xomega Framework base classes, will automatically handle both the UI validation of the supplied email and password, and the invocation of our Authenticate service method to check them against the saved password. If it succeeds, then the view will fire a ViewEvent about it being saved, which we will want to leverage to construct a claims identity for the user, and authenticate the user within the OWIN context. Here's what the corresponding method in our customized view will look like.

You can see how we call our Read operation on the PersonService using dependency injection, and leverage the CreateIdentity method on our SecurityManager class that we created earlier. After we sign the user in with this identity using the current OWIN context, we redirect to a URL that is supplied in the query string, if any.

All we have left to do now is to make some configuration changes for our web application. Let's open up the Web.config that is located under the Views folder of the .Client.Web project, which is where all the views are located. We will change the authorization for all views to deny access to non-authenticated users, except for the Person/LoginViewPage.aspx, which will allow access to all users, as follows.

Make sure that you make this update in the Web.config under the Views folder, and not at the root of the web project. Otherwise, other resources such as javascripts or stylesheets will be inaccessible from the browser, and your application will not function correctly.

Finally, let's update the Web.config, this time in the root of the web project, to map the Login path to our login page as follows.

Alternatively, you can change the LoginPath parameter in the Startup.Auth.cs file to point to the login page.

Let's run the WebForms application and check out the results of our hard work. You will notice that the application presents a login form, where you can enter an email and a masked password. If you enter invalid credentials, you will get the message from our service.

Let’s enter an email “amy1@adventure-works.com” for an external customer user with our valid test “password”. The login should succeed and take you to the home screen. If you go to the Sales Order List screen then, and run the search without any criteria then you’ll see the following screen.

As you see, the screen looks almost exactly like the Blazor application. The user name is displayed in the upper right corner, and the order list shows only current user’s sales orders. The criteria by customer store and customer name are hidden, so we are able to leverage all the common functionality that we’ve built for our application so far.

If you look closely, you may notice some differences from the Blazor app, such as the grid control and the tabs on the details view looking differently. The screen behavior is also slightly different, specifically related to modification tracking and not prompting the users for unsaved changes due to the way WebForms requires a postback in order to update the underlying data objects. By and large though, you still got the same functionality right out of the box.

Finally, let's see how we can disable access to the entire screen for certain types of users. As we discussed before, access to the Sales Order List screen should be only to internal employees and external customers, but not to vendors or other types of users.

Within the ASP.NET web framework this is achieved by setting up authorization using roles in the Views/Web.config file for specific paths (or initial parts thereof), as shown below.

This will also automatically hide the corresponding menu options for the users, since it has security trimming enabled. Unlike the Blazor app though, a sub-menu that contains menu items would not be hidden automatically if all its menu items are hidden due to security, and will just appear as an empty menu.

If the user manually types in the path to a prohibited screen in the browser, they will be redirected to the login view, which will display the Unauthorized message that we configured in our custom code. The following screenshot demonstrates this for our Vendor Contact user that is not authorized to view sales orders.

As you have seen, building secure classic WebForms applications is just as easy with Xomega, even if they may lack some capabilities of more modern web technologies.

Next: 4.7 Adding WPF authentication >