If, however, a user logs on to a workstation with an account that isn't in the security database that the Web server uses and then connects to the Web site with IE, IE prompts the user for his or her Win2K or NT 4.0 logon credentials. If the user responds with a username and password that are in the security database, IIS uses Windows authentication to log on the user.
The IIS online documentation mentions two limitations of Windows authentication: Users must use IE 2.0 or later as their browser, and integrated Windows authentication doesn't work over HTTP Proxy connections. The first limitation isn't typically a problem because the user accounts must be in either a domain or a local database. Thus, you know who the users are and can specify that they use IE 5.0 or IE 4.0 to connect to your application.
If users must use other browsers or HTTP Proxy connections, you can select the Basic authentication (password is sent in clear text) option in the Authentication Methods dialog box to control access to the Web site and therefore to SQL Server. The basic authentication method sends usernames and passwords in clear text. Thus, if you use this method with Internet connections, you should use Secure Sockets Layer (SSL) to encrypt the channel before you ask for the username and password. You can set the authentication level for a virtual directory within a Web site if you need to secure only part of the site.
Let's take a moment to review authentication versus authorization. Authentication validates users against some set of credentials, such as Win2K or NT 4.0 accounts. If users log on with a valid username and password, the OS authenticates them as valid users. Authenticated users can't take any actions with resources such as files or database tables unless the users have authorization to do so. Typically, administrators use NTFS to set permissions to files and Enterprise Manager to set permissions to SQL Server objects to control authorization to these resources.
So far, I've covered part of the process of setting up security—the part in which Win2K or NT 4.0 authenticates users. When users try to connect to SQL Server, the database must further authenticate them before opening a trusted connection. To authenticate users, SQL Server obtains their login credentials from the OS and looks them up in SQL Server. For SQL Server to authenticate users, the users must have a SQL Server login account mapped to their user account or their user account must be in a Win2K or NT 4.0 user group that's linked to a SQL Server login. The users must also be authorized for specific SQL Server resources before they can gain access to those resources.
The way to give users access to a SQL Server resource is to map their Win2K or NT 4.0 accounts, individually or as a group, to a SQL Server login, then assign that login's permissions to the resource. Figure 6 shows the Win2K NorthWindReaders group, which contains users who should have permission to read data in the sample Northwind database. To add this group as a SQL Server login, open Enterprise Manager, then open the Security folder under the desired server. Right-click the Logins folder, and select New Login. On the SQL Server Login Properties - New Login dialog box's General tab, click the ellipsis (...) beside the Name text box to open the dialog box that Figure 7 shows. Select NorthWindReaders, click Add, then click OK. At the bottom of the General tab that Figure 8 shows, select the default database for the SQL Server login from the Database drop-down list (in this case, the master database is the default).
At this point, if you click OK, users in the NorthWindReaders group will be able to log in to SQL Server but they won't be able to access any database resources because you haven't authorized them to. One way to authorize users is to set permissions on the SQL Server login. To do this, first click the SQL Server Login Properties - New Login dialog box's Database Access tab. Then, select the database the group needs access to (such as Northwind). To control access to the database, click the SQL Server Login Properties - New Login dialog box's Server Roles tab and select the database again. After you select a database, you'll see a list of available database roles for that database at the bottom of the dialog box. You want users in the NorthWindReaders group to have read-only access to the Northwind database, so select the db_datareader role and click OK to create the login. Now, users in the NorthWindReaders group can use their Windows logon to access the Web site and the database. Alternatively, you can use the sp_grantlogin stored procedure to create a login and the sp_grantdbaccess stored procedure to grant access to a login.
Authentication Alternatives
Internet Information Services (IIS) 5.0 administrators have several alternatives to Windows authentication and basic authentication for authenticating users that visit a Web site. One alternative is to map a client certificate to a Win2K or domain user account. When users connect using that certificate, IIS 5.0 uses the mapped account to log on the users; the users can then use the account credentials to access resources such as SQL Server.
Another authentication alternative (for Win2K and IIS 5.0 or later shops only) is digest authentication. With digest authentication, the browser creates a hashed version of the username and password as well as other information. A third party can't easily decipher the hashed credentials, but the DC can match the hashed information with the plaintext version stored on the DC. Thus, digest authentication lets the browser and server authenticate the user without sending clear-text passwords. Obviously, users must use a browser that supports digest authentication (such as IE 5.5 or IE 5.0), and the IIS 5.0 server must be part of a Win2K Active Directory (AD) domain.
Prev. page
1
[2]
3
next page 
