Windows authentication is an attractive option for you, for the reasons that:
– It involves little programming work on the developer’s part – You don’t need to create a login page, check a database, or write any custom code, because Windows already supports basic user account features such as password expiry, account lockout, and group membership.
– It allows you to use existing user logins – Normally, you use Windows authentication for applications where the users are part of the same local network or intranet as your web server. This means you can authenticate users with the same credentials they use to log into their computers. Depending on the settings you use and the network architecture, you may be able to provide “invisible” authentication that works without forcing a separate login step. Instead, the browser simply uses the logged-in identity of the current user.
– It provides a single authentication model for multiple types of applications – When you are working with Windows authentication, you have a single authentication model across different types of applications. You can use the same model for web services, ASP.NET applications, etc. For that reason, Windows authentication can save you from the challenge of flowing identities between machine boundaries and with Kerberos in place, Windows offers a well-established mechanism for such scenarios.
– It allows you to use impersonation and Windows security – You can take advantage of existing Windows security settings. For example, you can control access to files by setting Windows file-access permissions, but these permissions don’t take effect automatically, because by default your web application runs using a fixed account (Network Service on IIS 7.x). You can change this behavior by carefully using Windows authentication and impersonation.
Windows authentication also has the following disadvantages:
– It’s attached to Windows users – This authentication approach does not work unless the users you are authenticating already have valid Windows accounts. If you could create a Windows account for each visitor of your public website, it wouldn’t be as efficient as a database approach for large numbers of users. There is a potential security risk, because Windows user accounts can have permissions to the web server computer or other network computers.
– It’s attached to Windows client machines – Some of the authentication methods that IIS uses require users to have compatible software on their computers. This limits your ability to use Windows authentication for users who are using non-Microsoft operating systems or for users who aren’t using Internet Explorer.
– It does not provide flexibility and can’t be customized easily – You can’t control authentication process. For you is very difficult to add, remove, and manage Windows account information programmatically or to store other user-specific information with the user credentials.