There are several Ways to
authenticate users with IIS. If you make the right
decisions, IIS can keep a lot of authentication burden
off of your shoulders. The basic modes are:
| Anonymous
Access |
Each user
will be authenticated as a guest user. The real
ID of this guest user ID ist set in the internet
service mangager. This
mode offers no security and can not be used to
reduce authentication work by your web
application.
|
| Basic
Authentication |
With this
mode, users are authenticated with the help of
the Windows NT security accounts database (SAM)
(or Active Directory, if you already run under NT
5). Thus, the browser requests a userid/password
pair when first accessing the server (in a single
session). The user than has to supply his/her
Windows NT userid and password. This is used to
log the user in into the Windows NT Server IIS is
running on top of. All further processing is done
as the logged-in user; any access restrictions
that apply to this user normally still do apply
now (as the user is accessing the server via the
web). This mode can
be used to build pretty secure applications.
There are some drawbacks
however. First of all, each user must exist in
the Windows NT SAM (or Active Directory). If this
isn't the case, no user gets authenticated.
Please be also sure to grant the "log on
localy" right to each user.
Secondly, and more
important, the userid/password pair is
transmitted over the network for each request.
And this is done without any remarkable
protection (it's just base64 encoded and easily
decodable). Thus, basic authentication can break
your Windows NT security! This, fortunately, is
only a matter if the communication channel itself
is not protected. If you use SSL, all data will
be encrypted and everthing will work fine and
secure.
|
| Challenge
Response Authentication |
This works
similiar to basic authentication, but no password
is ever transmitted over the network. Thus, this
mode is even secure if you do not have an
encrypted channel (no SSL). However, there is one
pitfall with this type of authentication: so far
only Microsoft browsers support it! Please also note that MSIE 3.x
versions do login as the current logged in user
only in this mode. Thus the user can not change
his or her identity, which makes this mode
unusable for many real Internet applications.
With MSIE versions 4.x this (I think) bug is
fixed.
As there is no password
transmitted in this mode, the users password is
not available in the server variables.
|
In addition to this
authentication method, custom filers (ISAPI programs) can
add any authentication method imaginable to your server.
Basic and Challenge Response authentication, however,
will do for a lot of applications.
Remember, with both modes the user
becomes a loged in Windows NT user. All processing is
done in respect to this users' access rights. This has a
lot of (positive) implications. The most interesting is
in respect to Microsoft SQL server. SQL server has an
"integrated" authentication mode. In this mode,
no special database logon is necessary, instead the loged
in Windows NT user id is carried on to the database. The
user thus gets authenticated using his already logged in
Windows NT account.
Thus, SQL server honors the Windows
NT authentication, which in turn honored the
authentication made by your browser! Out of an instant,
you have SQL server permissions based on the
authentication done by the web browser. No need to do any
special coding.
The same is true for Microsoft
Transaction Server (MTS) role based security.
|
