If you are developing an on-line store you need to protact your data so the information doesn't go in the wrong hands. Read how Macromedia Dreamweaver MX allows you to safely interact with your database.
The term virtual security refers, in this context, to security that is inherent to your database, rather than your application. It is the functionality provided by SQL Server that grants and denies access to databases, tables, and other components. Virtual security is handled using logins and roles.
SQL Server has two modes by which it allows authentication: Windows NT and Mixed Mode. In Windows NT mode, SQL Server assumes that any connection that has made it to the SQL server has already been validated by the operating system against a domain account. Mixed Mode allows connections using either a Windows account or a SQL Server security account. Login accounts, which provide access to SQL Server, can be set up to validate either way. I will focus on the SQL Server authentication method (or Mixed Mode) because that's what is likely to be used in a hosted environment.
The first thing to concern yourself with when setting up your SQL Server logins is the system administrator (SA) account. Like Access, SQL Server comes with an administrator account that has no associated password. The SA account has full rights to everything in the database. If you leave it with no password, anyone using Enterprise Manager can connect to your database and login with full privileges. Now this might sound like a silly thing to warn you about, but a recent study discovered a surprising number of SQL Server databases exposed to the Internet with no SA password. The first thing you should do to provide security to a new SQL Server installation is place a password on the SA account that only you know.
The topic of logins is a broad subject. You can set up logins to allow access to your database by many people with a wide range of responsibilities. By granting permissions to certain databases and to only certain activities within those databases, you can allow people to create tables, perform backups, administer certain databases, or have only public access. They can see only what you have allowed them to see, which could also be nothing at all.
At this point, your goal is to create a login that is separate from the SA (or other administrator) login that you use to create and interact with your databases. This login will be used in the connection string that allows your website to pull data from the database and will restrict the user to only certain controlled activities.
In Enterprise Manager, locate and expand the Security folder. Within this folder, you will see a section called Logins. This section manages logins for the entire server. A particular login can be given rights to numerous databases, so think of security from a server level at this point, not from that of a particular database.
Right-click on Logins and choose New Login.
In the New Login dialog box, choose a name for this login.
Select the SQL Server Authentication option and enter a password for this login.
Choose the database that you are working on as the default database for this login. This database is chosen by default when the login tries to access the server. If no other database is specified, this is the database that will be connected to. You may have seen this happen when setting up a DSN on a web server. If the login has permissions for databases other than the default, you may also select one of those at the time of connection.
You may assign this login to a server role in the Server Roles tab, but for now click the Database Access tab. This tab lists all the databases in the server and allows you to check which ones the login has access to.
Click the box next to the database that you are creating this login to be used with. If you select a default database, but don't provide access to that database in the Database Access tab, you will get a message when saving that says the user cannot access this default database.
Click OK. Once you verify the password, the login is created. You can click the Logins option in the Enterprise Manager to see all of the logins and select one for maintenance should you need to make changes in the future.
This is enough for your purposes at this point. You can now supply this login with permissions to individual components of your database, like stored procedures. When you connect to the database in Dreamweaver, you will be able to interact with those components to create recordsets and commands. Logins can also be managed in groups called Roles, which help to define the permissions that you want specific groups of users to have.
You can certainly provide access to your users through the use of individual logins, which you then painstakingly customize to grant permissions to the many components of your database. But an easier way is to define roles to which you can add logins.
Roles are simply groups of logins that have common permissions. You might have a Backup Operator role that allows members to back up a database; or a Data Reader role that allows data to be read by its members, but not inserted, updated, or deleted. Roles can be created at the server level under the Security folder in Enterprise Manager, on at the database level under each database.
Roles are really a SQL Server administration topic; they are beyond the scope of this article. They are not difficult to use, however, and a little investigation will take you a long way. Basically, you right-click on Roles under a particular database and select New Database Role to create a new role. Name the role and click the Permissions tab.
You will be presented with all of the objects in the database from which you can select those that this role should have access to, and what kind of access should be granted. Once that is complete, use the Add button to add existing logins to the role. All of those logins now have the permissions defined for that role and any others of which they are members.