Why not get passwords set for the domain? Why write
password and user id management into your web applications
when it is already supplied by the OS?
I don't mean to avoid the question but it seems to me you
are going about this the wrong way.
As for the question.
You would have to put the ids and passwords in some form
of storage and the DB is a good idea. Store the passwords
with one of the available one-way hash algorithms. As for
sharing the code to manage a web service means you'll have
to decide how to secure the web service. Also consider
whether you will support things such as expiring accounts,
expiring passwords, password complexity, etc. Also if you
call the web service with a plain text password it could
be a vulnerability issue. I'd seriously consider getting
windows passwords in a domain if possible.
>I am developing for an Intranet with about 100 users
>(we do computer training).
>We're running about 12 different ASP.NET applications.
>4 of these applications require authentication.
>Windows authentication is not an option, as for Windows
>most of our users have a blank password (so it would
>be too easy for one user to impersonate another).
>For my secure applications all users will have their own
>password, and it should be the same password for the
>4 applications. They should have an option to change
>their own password.
>What will be the best policy to avoid duplicating code
>and information about users and passwords?
>My first thoughts were:
>- to use a database with user names and (encrypted)
>- to share the database code and functionality (checking
> credentials, changing passwords) through a web service
>- to call the web service whenever a user is logging on.
>Is this a good path to follow?
>Or can it be done with one single web.config file?
>Any other suggestions?