Chapter 14
Setting Up Security

[p]This chapter describes the methodology of securing Lasso-based Web sites using Lasso Security and Site Administration, and is divided into the following sections. [/p]

• Introduction provides an introduction to Lasso Security and introduces concepts described later in the chapter.
• Setting Up Groups describes how to set up groups in Lasso, which represent sets of permissions for end users.
• Setting Up Users describes how to define custom usernames and passwords in Lasso to be used for end user authentication.
• Data Host Permissions describes the data source host permissions which can be assigned to a group, which includes permission to issue SQL queries.
• Database Permissions describes the individual database permissions which can be assigned to a group.
• Table Permissions describes the individual table permissions which can be assigned to a group.
• Field Permissions summarizes the field preferences which can be set for a field and how they are checked.
• Tag Permissions describes how substitution, process, and container tags can be secured by assigning permissions to a group.
• File Permissions describes the permissions and preferences unique to file manipulation tags.
• Web Server Security describes how Lasso Security interacts with the security systems of Web server applications.
• Record-Level Security describes how to use field settings to implement record-level security.
• Security Tips includes general principles which help ensure a secure Web site.

Introduction

[p]This chapter describes the tools that Lasso Professional Server provides to allow developers to build secure Web sites. This chapter documents the concepts behind Lasso’s security, and strategies for setting up security on servers with various purposes. This chapter also documents the Setup > Security section of Site Administration, which is the primary interface for configuring Lasso security. [/p]

Lasso Security Model

[p]One of the most important features in Lasso Professional Server is the inclusion of a very robust security model that can be used to secure all elements of a Lasso solution. Lasso Security interacts with Web server applications, database applications, Web clients, operating systems, and other CGI products. Lasso provides tools to secure access to each of the different applications that Lasso uses, and also tools to control usage within Lasso. [/p]

[p]Lasso Security is comprehensive, and can be used to secure and protect many Web server operations from undesired users. These operations include but are not limited to the following: [/p]

• [def]Database Actions [/def]– Lasso provides tools to restrict the types of actions that can be performed on databases. The same Lasso security model can be applied to all data sources to which Lasso connects.
• [def]Tag Processing [/def]– Lasso provides tools to restrict the use of Lasso tags both at the server level, and at the user level.
• [def]File Manipulation [/def]– Lasso provides permissions specific to tags that manipulate the file system local to Lasso Service.
• [def]File Access [/def]– Lasso can restrict the file suffixes which can be processed by Lasso at the server level.
• [def]Web Browser Authentication [/def]– Lasso automatically prompts Web browsers for authentication as needed, and provides tools to allow developers to prompt for custom authentication.
• [def]Web Server Realms [/def]– Lasso provides tags for interacting with Web server realms and administration for file suffix mappings.

Lasso Groups and Users

[p]At the core of Lasso Security are Lasso groups and users. Groups represent sets of permissions for various operations, and Users represent usernames and passwords (or lack thereof) which can be used to access those permissions. [/p]

[p]The power of Lasso Security lies not only in what permissions can be set for a group, but also in how those permissions can be assigned to users. Group permissions can be shared by one or more users, and users may be assigned to one or more groups (how Lasso determines what permissions to use for a user assigned to multiple groups is described later). This multi-dimensional security model allows the most advanced authentication systems to be created for those that desire them. [/p]

[p]In Lasso Security, there are three classes of groups and users, which are described below. Understanding these classes and what they can do is the first step in using Lasso Security with maximum power and ease. [/p]

Site Administrator

[p]The Lasso Site Administrator has full control over all Lasso-configurable operations by default. Only the Lasso site administrator or server administrator may access Site Administration. The site administrator permissions account is a pre-configured group in Lasso Security that consists of only one username and password set. Site administrator permissions cannot be shared by other users. [/p]

[p]Whenever the site administrator is logged in via a Web browser, he or she will instantly have permission to execute all Lasso code and will pass all security checks without being prompted for authentication again. [/p]

[p]When using Lasso for the first time, it is important to understand that the end-users who will be accessing Lasso solutions will not have the same permissions as the site administrator by default, therefore some security settings such as database permissions will have to be set before other users may use them. [/p]

AnyUser Group and Anonymous Users

[p]Only one configurable group is predefined in Lasso Professional Server, which is the [code]AnyUser[/code] group. If an end user of a Lasso Solution is not logged in with a username and password that is defined in Lasso Security, then he or she will inherit the permissions of this group by default. These users are referred to as [code]Anonymous[/code] users. [/p]

Figure 1: Group Detail

[p]When Lasso Professional Server is installed, it is secure by default. This means that the [code]AnyUser [/code]group has no database or file permissions assigned to it in Site Administration by default. When creating a Lasso solution that does not require authentication, explicit permissions must be set for the [code]AnyUser[/code] group beforehand. How to set permissions for the [code]AnyUser [/code]group is described in this chapter. [/p]

Custom Groups and Users

[p]Custom groups may be created by the site administrator if password protection is desired for certain sets of permissions. [/p]

[p]A custom group may be created with a defined permissions, and then defined users in Lasso Security (with usernames and passwords) may be added to the custom group. Defined users in Lasso Security may also be added to more than one custom group. [/p]

Figure 2: Custom Groups

[p]Much of the security power in Lasso Professional Server comes from creating custom groups and users, and there are many different ways to use groups in Lasso Security to assign permissions to users. Several custom groups with different permissions can be combined to meet the unique needs of any Web site. For example, separate groups could be created for each database used by Lasso, but a single group could define access to file tags across all users of a Web site. [/p]

[p]Lasso Professional Server also features the ability to designate group administrators among custom groups. A group administrator is a user in Lasso Security defined by the site administrator who has permissions to make changes to user accounts that belong to a specific group. [/p]

User Authentication

[p]All Lasso tags and actions are executed with the permissions of a specific user. Since permissions are only granted to groups, the permissions for a specific user are defined by the group(s) to which they belong. When a tag is executed, the permissions of all the groups to which the user belongs are checked in alphabetical order by group name. [/p]

[p]There is no one-to-one correspondence between users and visitors. It is possible for many visitors to authenticate as the same user. For example, all the members of a workgroup may share a common username and password. In the extreme, all unauthenticated visitors are treated as a single [code]Anonymous [/code]user and have the permissions of the [code]AnyUser [/code]group. [/p]

[p]A single visitor may execute code using the permissions of many users. They will be prompted for a username and password if they do not have permission to access a resource based on the current user information they have supplied. If they enter the authentication information for a different user, then they become that user for subsequent pages. [/p]

[p]Lasso primarily relies on the Web authentication routines built into every Web browser in order to authenticate site administrators and other Lasso users. However, Lasso permissions may also be programmatically specified using the [code][Inline] … [/Inline][/code] tag in Lasso. [/p]

[p]Usernames and passwords can be specified within [code][Inline] … [/Inline][/code] tags so that the contents of the container tags are executed with the permissions of a specified user. Most of a Lasso page will be executed with the permissions of the user defined by the current visitor, but portions of the Lasso page can be executed with the permissions of specific users. [/p]

[p]There are several ways to specify what user’s permissions should be used to execute a Lasso page or section of Lasso code depending on whether or not the current visitor is authenticated, or if a specific username and password are coded into the Lasso page. [/p]

• [def]Anonymous [/def]– By default, all code is executed as the [code]Anonymous [/code]user. This is the case if no users are defined within Lasso Security, if the current visitor has not specified a username and password, or if the current visitor has specified an invalid username and password.
• If an [code]Anonymous [/code]user does not have permission to access a resource, then an authentication dialog will be displayed in the visitor’s Web browser. If one enters a valid username and password for a user that has permission to access the resource, then one can continue.
• [def]Current Visitor [/def]– If the current visitor has entered a username and password into the Web browser’s authentication dialog and that username and password can be found in Lasso Security, then the Web site will execute all tags with the permissions of that user.
• [def]Inline Authentication [/def]– The [code]-Username[/code] and [code]-Password[/code] command tags can be used to explicitly set a username and password for all code executed within [code][Inline] … [/Inline][/code] tags (including a database action within the opening [code][Inline][/code] tag). This allows the permissions of the current visitor to be augmented by the permissions for a specific user for the duration of the [code][Inline] … [/Inlie][/code] tags.
• [def]Site Administrator [/def]– A single site administrator is defined by Lasso Security. This user has the authority to execute any tag and perform any database action even on tags and databases which are disabled. This user also has the authority to change all of the security settings within Site Administration. The site administrator username and password should never be embedded in a Lasso page.

How Lasso Checks User Security

[p]All of Lasso Security is tied to the action of executing Lasso tags. Lasso performs a series of checks each time a tag is executed in order to confirm that the current user has permission to execute the tag, and the current user has permission to access the resources that the tag requires in order to perform its task. [/p]

[p]The process that Lasso uses to check security settings each time a tag is executed is shown below. Some of the steps are actually performed when a Lasso page is first accessed, or when an [code][Inline] … [/Inline][/code] is entered and information is cached for fast access, but conceptually the steps are performed in this order. [/p]

[p]When a user belongs to more than one group in Lasso Security, groups are always checked in alphabetical order with the exception of the [code]AnyUser [/code]group, which is always checked last. Groups with names that start with letters earlier in the alphabet have higher priority than groups with names that start with letters later in the alphabet. If a specific ordering of groups is needed, then a prefix can be used to ensure that the group permissions are checked in the desired order. [/p]

How Lasso checks security when a Lasso action is performed:

1. The list of available Lasso tags is checked. Any tags which are not enabled (e.g. tags marked [code]Disabled[/code]) are not recognized as part of Lasso, and will generate a syntax error (rather than a security violation).

2. The current username and password are identified. If the current site visitor has authenticated through their Web client, then the username and password they specified are used. If [code]-Username[/code] and [code]-Password[/code] are specified within the Lasso code, then the values of those tags are used. Otherwise, the user is [code]Anonymous[/code].

3. The current user is looked up in Lasso Security. If no matching username and password can be found, then the user is treated as [code]Anonymous[/code]. Note that Lasso will execute code for a visitor who has specified any unknown username and password as [code]Anonymous[/code].

4. The set of groups which the current user belongs to is identified. The permissions for each group will be checked in alphabetical order, followed by the [code]AnyUser [/code]group.

5. The permissions for each group are checked in alphabetical order. If an [code]Allow [/code]permission is found for the tag, then its use is allowed and no further checking is performed. If a [code]Deny [/code]permission is found for the tag, then its use is denied, a security violation is generated, and no further checking is performed. If an[code] Ignore[/code] permission is found, then the use of the tag is not allowed for that group, but Lasso will continue to check that tag’s permissions for the current user in other groups. By default, all substitution tags in [code]AnyUser [/code]have [code]Allow [/code]permission, while all action tags (e.g. [code]-Search[/code], [code]-Add[/code], [code]-Update[/code], [code]-Delete[/code], -[code]SQL[/code]) have [code]Ignore[/code] permission.

6. If the tag references a database, table, or fields, then the permissions specific to those entities are checked. See the sections on Database Permissions, Table Permissions, and Field Permissions for more details.

7. If the tag is a [code][File_…][/code] tag, then the permissions specific to the [code][File_…] [/code]tags are checked. Site users and the site administrator can only use the file tags within the paths defined in Server Administration. See the File Permissions section for more information.

8. If a security violation is generated, then the site visitor will be presented with a browser-specific authentication dialog. After the visitor has entered a new username and password, the entire series of steps are performed again checking against a new user.

Security Error Reporting

[p]Unless custom error handling is coded into your [code].lasso[/code] or [code].lassoapp[/code] files, the Lasso Professional default error page will be shown in the event of a security error while processing a file. The level of detail shown in the default page can be configured using the Setup > Site > Syntax section of Site Administration. [/p]

[note][b]Important: [/b]A configured error reporting of [code]Full [/code]in the Setup > Site > Syntax section of Site Administration will reveal Lasso source code and other critical information when an error occurs. While this is useful for debugging, it is strongly recommended that Lasso Professional servers running in a production environment be set with a error reporting level of [code]Minimal[/code] or [code]None[/code] for maximum security. [/note]

[p]To learn more about error reporting in Lasso Professional and how to code custom error handling using Lasso, see the Error Control chapter in the Lasso 8.5 Language Guide. [/p]

Setting Up Groups

[p]Groups in Lasso Professional Server allow security settings to be set for groups of users. Users can log in to a Lasso-driven Web site with assigned group security values, or in the absence of a recognized username and password are automatically assigned to the [code]AnyUser[/code] group by default. [/p]

[p]The Setup > Security > Groups page in Site Administration allows the administrator to add, view, enable, disable, and configure groups in Site Administration. [/p]

Figure 3: Groups List Page

[p]The [code]Group Listing[/code] panel shows a list of all the groups defined in Lasso. [code]Prev[/code] and [code]Next [/code]buttons are shown if more than 10 groups exist. Selecting [code]Enable All [/code]will enable all groups shown, while selecting[code] Disable All[/code] will disable all groups shown. Selecting [code]Refresh[/code] will refresh the[code] Groups[/code] page with the most recently updated information. [/p]

[p]The default group is [code]AnyUser[/code] with one member [code]Anonymous[/code]. By default, any permissions granted to this group will be granted to all visitors to the Web site. [/p]

Adding a Custom Group

[p]Selecting the [code]Add Group[/code] button shows the [code]Add Group[/code] panel to the right. The [code]Add Group[/code] panel allows the administrator to add a new group to Site Administration. [/p]

Figure 4: Add Group Panel

To add a new group:

1. Enter the name of the group to be added in the [code]Name[/code] field.

2. Select [code]Enabled [/code]or [code]Disabled[/code] from the [code]Status [/code]pull-down menu to enable or disable the group in Lasso Professional Server.

3. Select [code]Add Group[/code].

[p]After selecting the [code]Add Group[/code] button, one is taken to the [code]Groups[/code] page with the newly added group selected for additional modifications. [/p]

Updating Group Properties

[p]Selecting a group name in the [code]Groups Listing [/code]panel will show its details in the [code]Group Detail [/code]panel, which appears to the right. Here, the administrator can update the selected group name and status by selecting the [code]Update [/code]button, or delete the group by selecting the [code]Delete [/code]button. The [code]AnyUser [/code]group is separated from all created groups, and appears at the top of the [code]Groups Listing[/code] panel. [/p]

To update details for a selected group:

1. Edit the name of the selected group in the [code]Name [/code]field.

2. Select [code]Enabled[/code] or [code]Disabled [/code]from the [code]Status[/code] pull-down menu to enable or disable the group.

3. Select [code]Update[/code].

[p]The [code]List Users [/code]link takes one to the [code]Users [/code]page with the current group selected. The date and time of the last update is always shown in the lower right corner of the [code]Group Detail[/code] panel. [/p]

[note][b]AnyUser [/b][b]Note[/b]: The [code]AnyUser[/code] group cannot be deleted as it is required by Lasso Professional Server. For this reason, the [code]Update[/code] and [code]Delete[/code] buttons will not be shown in the [code]Group Detail[/code] panel for the [code]AnyUser[/code] group. [/note]

Setting Group Permissions

[p]Group permissions can be set by selecting the [code]Hosts[/code], [code]Databases[/code], [code]Tables[/code], [code]Tags[/code], or [code]Files[/code] buttons in the [code]Group Detail [/code]panel. Doing so will take one to the [code]Hosts[/code], [code]Databases[/code], [code]Tables[/code], [code]Tags[/code], or [code]Files [/code]pages where the corresponding permissions can be set, as discussed later in this chapter. [/p]

[p]For most Lasso Solutions, setting database and table permissions for the [code]AnyUser[/code] group is typically the first task. See the Data Host Permissions, Database Permissions, and Table Permissions sections for more information on these permissions. [/p]

Setting Up Users

[p]Individual user accounts allow different users to access Lasso Professional Server Web solutions with different levels of security. While access and tag-level security settings are set in the [code]Groups [/code]section, the [code]Users[/code] section allows the administrator to set usernames and passwords, set groups to which a user belongs, and to designate specific users as administrators for specific groups. [/p]

[p]The Setup > Security > Users page in Site Administration allows the administrator to add, view, and configure users. [/p]

[note][b]Important: [/b]No user configuration is required for [code]Anonymous[/code] users, which are configured by default through the [code]AnyUser[/code] group. The [code]Users[/code] page is used only for creating custom username and password accounts, and designating custom group administrators. [/note]

Figure 5: Users List Page

User Listing

[p]The [code]User Listing[/code] panel lists all currently defined users. Users from a particular group as well as users who do not belong to any groups can be shown. The current group may be changed by selecting a group from the pull-down menu. In addition to the groups defined in the Setup > Security > Groups section of Site Administration, the administrator may choose one of the following user display options from the pull-down menu. [/p]

• [def]All Users[/def] – Displays all users in Site Administration regardless of group assignment.
• [def]No Group[/def] – Displays all users not currently assigned to groups.
• [def]All Admins[/def] – Displays all group administrators in all groups.

[p]Selecting the username shows details of the user in the [code]User Detail[/code] panel, which appears to the right. All users shown can be enabled or disabled by selecting [code]Enable All[/code] or [code]Disable All[/code]. Selecting [code]Add User… [/code]takes one to the [code]Add User[/code] page. [/p]

Adding Custom Users

[p]Selecting the [code]Add User[/code] button in the [code]User Listing[/code] panel shows the [code]User Detail[/code] panel to the right. The [code]Add User[/code] page allows the administrator to create new users in a specified group or groups. [/p]

Figure 6: Add User Panel

To add a new user:

1. Enter the username of the user to be added in the [code]Name[/code] field.

2. Enter the password for the selected user in the [code]Password[/code] field.

3. Select any number of groups from the [code]Groups[/code] field to which the user is to be assigned.

4. Select any number of groups from the [code]Administrator[/code] field for which the selected user is to be granted administrator privileges. The purpose of a group administrator is to add and remove other users to and from the group the user has group administrator privileges for. There can be as many group administrators as needed. For more information on group administrators, see the following Group Administrators section.

5. Select the [code]Add User[/code] button.

[p]The [code]Search[/code] page allows administrators to search for users by group, name, status, or administrator. [/p]

Updating Custom Users

[p]Selecting a user in the [code]User Listing[/code] panel will show its details in the [code]User Detail[/code] panel, which appears to the right. Here, the administrator can update or delete the selected user’s details by selecting the [code]Update[/code] button, or delete the user by selecting the [code]Delete[/code] button. [/p]

[p]To update details for a selected user: [/p]

1. Edit the username of the selected user in the [code]Name[/code] field.

2. Edit the password for the selected user in the [code]Password[/code] field. The password will be hidden, but can be changed by deleting the contents of the [code]Password [/code]field, and entering a new password.

3. Select [code]Enabled[/code] or [code]Disabled[/code] from the [code]Status[/code] pull-down menu to enable or disable the user.
4. [note][b]Note: [/b]Disabled users are treated as anonymous users, and are assigned permissions from the [code]AnyUser[/code] group when accessing Lasso pages or LassoApps. [/note]

4. Select any number of groups from the[code] Groups [/code]field to which the user is to be assigned.

5. Select any number of groups from the [code]Administrator[/code] field for which the selected user is to be granted administrator privileges. The purpose of a group administrator is to add and remove other users to and from the group the user has group administrator privileges for. There can be as many group administrators per group as needed. For more information on group administrators, see the following Group Administration LassoApp section.

6. Select the [code]Update[/code] button.

[note][b]Note: [/b]The [code]Anonymous[/code] user cannot be modified or deleted as it is required by Lasso Professional Server. For this reason, the [code]Delete[/code] button will not be displayed in the [code]User Detail [/code]field for the [code]Anonymous[/code] user. [/note]

Group Administrators

[p]Users can be granted the privilege to be a group administrator for one or more groups. Any user which is defined as a group administrator can add users to a group using the [code]GroupAdmin.LassoApp[/code] file, or using the [code][Admin_…][/code] tags in Lasso. Only a group administrator or the site administrator can add users to a group, and a group can have as many group administrators as needed. [/p]

Group Administration LassoApp

[p]The group administrator is able to add and remove users from a group via the [code]GroupAdmin.LassoApp[/code] file, which is a LassoApp served on-demand from the Lasso Professional Server application folder. This LassoApp only contains the features of the Setup > Security > Users section of Site Administration. When accessed, the [code]GroupAdmin.LassoApp[/code] file prompts one for a group administrator username and password, as designated in the Setup > Users > Admin page in Site Administration. Within the Group Administration LassoApp, group administrators are only able to access the group to which they have been assigned. [/p]

Figure 7: Group Administration LassoApp

To access the Group Administration LassoApp:

[p]In a Web browser, visit [code]http://www.example.com/Lasso/GroupAdmin.LassoApp[/code]. Replace [code]www.example.com[/code] with your domain name, IP address, or [code]127.0.0.1[/code] if on a local machine. If an error is displayed, make sure Lasso Service is running. [/p]

[p]Data Host Permissions [/p]

[p]The Setup > Security > Hosts page in Site Administration allows the administrator to define all host-level permissions for any specific group. [/p]

Figure 8: Hosts Page

Setting Group Host Permissions

[p]Selecting a host in the [code]Host Listing[/code] panel shows its permissions settings in the [code]Host Detail[/code] panel to the right. The following describes the database security permissions that can be set for the selected group: [/p]

• [def]Execute SQL[/def] – Allows or denies the ability to issue SQL statements by restricting the [code]-SQL [/code]command tag in Lasso 8. Allowing [code]Execute SQL[/code] effectively grants a group the ability to view and edit all databases, tables, and fields in a host via SQL statements, and should be allowed with care. This is the only permission specific to the host-level in Lasso Professional Server, and is only applicable for data sources that can interpret SQL statements.

1. [note][b]Warning: [/b]Due to the large array of things that permission to execute SQL statements opens up for a developer, SQL permission should only be given to trusted users. [/note]

[p]The administrator can update host security settings by selecting [code]Allow[/code] or [code]Deny[/code] from the [code]Execute SQL[/code] pull-down menu, and then selecting the [code]Update [/code]button. The[code] List Databases[/code] button takes the administrator to the [code]Databases [/code]page with the current host selected. [/p]

How Lasso Checks Data Host Security Settings

[p]When a user attempts to perform a SQL query via Lasso, the permissions for all the groups the user belongs to are checked in sequence. The following steps are performed. [/p]

1. The set of groups which the current user belongs to is identified. If the user belongs to more than one group, the permissions for each group will be checked in alphabetical order by group name.

2. The permissions for each group are checked for a permission which references the current host. If an [code]Allow [/code]permission is found for the host, then its use is allowed and no further checking is performed. If a [code]Deny [/code]permission is found for the host, then its use is denied, a security violation is generated, and no further checking is performed. If an[code] Ignore[/code] permission is found, then the database is not allowed for that group, but Lasso will continue to check database permissions for the current user in other groups.

3. If no result is found after checking all of the groups which the user belongs to and the [code]AnyUser [/code]group, then the SQL query is denied and a security violation is generated.

4. If the database referenced in the SQL query has any SQL stop words defined in Site Administration, they are compared to the SQL statement which was specified in the Lasso SQL query. If a match is found, then the SQL statement is not allowed and a security violation is generated.

[p]An [code]Allow[/code] permission is required in order to issue SQL statements for a data source host. The SQL permission for a host is [code]Ignore[/code] by default, and this permission must be explicitly set to [code]Allow[/code] before any SQL statements can be issued using Lasso. [/p]

Database Permissions

[p]Lasso Security allows administrators to either [code]Allow [/code]or [code]Deny [/code]different database actions for a group for each specific database available through Lasso. Permissions can also be defined for a single meta-entry[code] [/code][def]All Databases[/def]. This entry is checked if no permissions are found for a specific database. [/p]

[p]The Setup > Security > Databases page in Site Administration allows the administrator to define all database-level permissions for any specific group. [/p]

Figure 9: Databases Page

[p]The top panel shows the current group to the right of [code]Permissions For Group[/code]. The current group can be switched by selecting an existing group from the [code]Groups[/code] pull-down menu and selecting [code]Switch Group[/code]. [/p]

[p]The[code] Database Listing[/code] panel shows a listing of all the databases available for the current group, as well as links to [code]All Databases [/code]and [code]All Tables [/code]settings. The current connector and host are displayed by default. The administrator can switch connectors and hosts by selecting a new connector and host from the [code]Connectors[/code] and [code]Hosts [/code]pull-down menus. Selecting [code]Unassign All [/code]will reset all permissions for all databases to their default values. No user will be able to access a database via a Lasso solution unless the database has been assigned with at least one permission set to[code] Allow[/code] by the administrator. [/p]

[p]Selecting the [code]All Databases[/code] link in the [code]Database Listing[/code] panel allows permissions to be set for all databases regardless of data source connector or host in the[code] Database Detail[/code] panel, which appears to the right. Selecting the [code]All Tables[/code] link takes the administrator to the [code]Table Detail[/code] panel in the [code]Tables[/code] page, where permissions for all tables regardless of data source connector, host, or database can be set. For more information, see the [code]Tables[/code] page description. [/p]

Setting Group Database Permissions

[p]Selecting a database in the [code]Databases Listing[/code] panel will show its permissions settings in the [code]Database Detail[/code] panel for the selected group. Here, the administrator can update database security settings by selecting the [code]Update [/code]button. [/p]

[p]The following describes the database security permissions that can be set for the selected group: [/p]

• [def]Search Records[/def] – Allows or denies record searching for the selected group by restricting the [code]-Search[/code], [code]-FindAll[/code], and [code]-Random[/code] command tags in Lasso 8.
• [def]Add Records[/def] – Allows or denies the ability to add records for the selected group by restricting the[code] -Add[/code] tag.
• [def]Update Records[/def] – Allows or denies the ability to update records for the selected group by restricting the[code] -Update[/code] tag.
• [def]Delete Records[/def] – Allows or denies the ability to delete records for the selected group. This is accomplished by restricting the [code]-Delete [/code]command tag in Lasso 8.
• [def]Show Database Schema[/def] – Allows or denies the ability to view a database’s schema for the selected group. The database schema is a list of all tables in a database, and is accomplished by restricting the [code]-Show [/code]command tag in Lasso 8.
• [def]Execute Scripts[/def] – Allows or denies the ability to execute FileMaker Pro scripts utilizing the [code]-FMScript [/code]command tags in Lasso 8.

[note][b]Note: [/b]All permissions default to [code]Ignore[/code], which simply is the absence of an [code]Allow[/code] or [code]Deny[/code] permission. [/note]

[note][b]The [/b]administrator can update database security settings by selecting [code]Allow[/code] or [code]Deny[/code] from each pull-down menu, and then selecting the [code]Update [/code]button. The[code] List Tables[/code] button takes the administrator to the [code]Tables [/code]page with the current table selected. [/note]

How Lasso Checks Database Security Settings

[p]When a user attempts to perform a database action, the permissions for all the groups the user belongs to are checked in sequence. The following steps are performed. [/p]

1. The set of groups which the current user belongs to is identified. If the user belongs to more than one group, the permissions for each group will be checked in alphabetical order by group name.

2. The permissions for each group are checked for a permission which references the current database and action. If an [code]Allow [/code]permission is found for the database, then its use is allowed and no further checking is performed. If a [code]Deny [/code]permission is found for the database, then its use is denied, a security violation is generated, and no further checking is performed. If an[code] Ignore[/code] permission is found, then the database is not allowed for that group, but Lasso will continue to check database permissions for the current user in other groups.

3. If no result is found in a particular group, then the permission for the[code] All Databases [/code]entry for that group is checked. If an [code]Allow [/code]permission is found for the database action for [code]All Databases, [/code]then the action is allowed. If a [code]Deny [/code]permission is found, then the database action is denied and a security violation is generated. Note that after the first [code]Allow [/code]or [code]Deny [/code]is found, no further checking is performed.

4. If no result is found after checking all of the groups which the user belongs to and the [code]AnyUser [/code]group, then the database action is denied and a security violation is generated.

5. If the database has any SQL stop words defined, they are compared to the SQL statement which was specified in the [code]-SQL[/code] command tag or to the SQL statement generated automatically by Lasso. If a match is found, then the SQL statement is not allowed and a security violation is generated.

[p]This order of operation means that any database actions which are not explicitly allowed for a group (and its associated users) are effectively denied. The [code]All Databases [/code]entry can be used to allow database actions across all databases available to Lasso. [/p]

[p]Database permissions are required in order to access a table. A database must have [code]Allow [/code]permission for a specified action in order for the like permissions of the table to even be checked. All actions for a table have [code]Ignore[/code] permission by default, and permissions must be explicitly set to [code]Allow[/code] before any data can be retrieved from the table. [/p]

Table Permissions

[p]Lasso Security allows administrators to either [code]Allow [/code]or [code]Deny [/code]different database actions for a group for each specific table available through Lasso. [/p]

[p]The Setup > Security > Tables page in Site Administration allows the administrator to define all table-level permissions for any existing group. [/p]

Figure 10: Tables Page

[p]The top panel shows the current group to the right of [code]Permissions For Group[/code]. The current group can be switched by selecting an existing group from the [code]Groups [/code]pull-down menu and selecting[code] Switch Group[/code]. [/p]

[p]The [code]Table Listing[/code] panel shows a listing of all the tables available for the selected database. The current connector, host, and database are displayed by default. The administrator can switch databases by selecting a new database from the [code]Database[/code] pull-down menu. Selecting the name of a table shows its group security settings in the[code] Table Detail[/code] panel. Selecting [code]Unassign All[/code] will reset all permissions for all tables to their default values. [/p]

[p]Selecting the [code]All Databases[/code] link in the [code]Table Listing [/code]panel takes the administrator to the [code]Databases[/code] page, where permissions for all databases can be set in the [code]Database Listing [/code]panel. Selecting the [code]All Tables[/code] link allows permissions to be set for all databases regardless of data source connector, host, or database in the[code] Table Detail[/code] panel, which appears to the right. [/p]

[note][b]Note: [/b]Allowing permission for all tables does not override any database permission setting of [code]Deny[/code] or I[code]gnore[/code]. If a database permission is set to [code]Deny[/code] or [code]Ignore[/code], then a user will not be able to access any information in the database even if all table permissions are set to [code]Allow[/code]. [/note]

Setting Group Table Permissions

[p]The administrator can update table security settings for the selected group in the [code]Tables Detail[/code] panel. The following describes the table security permissions that can be set for the selected group. [/p]

• [def]Show Table Schema [/def]–[def] [/def]Allows or denies the ability to view a table’s schema for the selected group.
• [def]Search Records [/def]–[def] [/def]Allows or denies record searching for the selected group.
• [def]Update Records[/def] – Allows or denies the ability to update records for the selected group.
• [def]Add Records[/def] – Allows or denies the ability to add records for the selected group.
• [def]Delete Records [/def]–[def] [/def]Allows or denies the ability to delete records for the selected group.

[note][b]Note: [/b]In order for a user to be able to use a database via a Lasso solution, permissions must be set to [code]Allow[/code] on both the database and table level. For example, a user will not be able to search for records in a database unless the [code]Search Records[/code] permission is set to [code]Allow[/code] for both the database and the table that contains the records. [/note]

[p]The administrator can update database security settings by selecting [code]Allow[/code] or [code]Deny[/code] from each pull-down menu, and then selecting the [code]Update [/code]button. [/p]

How Lasso Checks Table Security Settings

[p]When a user attempts to perform a database action, the permissions for all the groups the user belongs to are checked in sequence. The following steps are performed. [/p]

1. The set of groups which the current user belongs to is identified. If the user belongs to more than one group, the permissions for each group will be checked in alphabetical order by group name.

2. First, permission is checked for the database which contains the table and for the [code]All Databases [/code]entry. If [code]Allow [/code]permission is granted, then the table security settings are checked.

3. The permissions for each group are checked for a permission which references the current table and action. If an [code]Allow [/code]permission is found for the table, then its use is allowed and no further checking is performed. If a [code]Deny [/code]permission is found for the table, then its use is denied, a security violation is generated, and no further checking is performed. If an[code] Ignore[/code] permission is found, then the use of the table is not allowed for that group, but Lasso will continue to check table permissions for the current user in other groups.

4. If no result is found in a particular group, then the permission for the[code] All Tables [/code]entry for that group is checked. If an [code]Allow [/code]permission is found for the database action for [code]All Tables, [/code]then the action is allowed. If a [code]Deny [/code]permission is found, then the database action is denied and a security violation is generated. Note that after the first [code]Allow [/code]or [code]Deny [/code]is found, no further checking is performed.

5. If no result is found after checking all of the groups which the user belongs to and the [code]AnyUser [/code]group, then the database action is denied and a security violation is generated.

[p]Database permissions are required in order to access a table. A database must have [code]Allow [/code]permission for a specified action in order for the permissions of the table to even be checked. [/p]

[note][b]Note: [/b]In order for a user to be able to use a database via a Lasso solution, permissions must be set to [code]Allow[/code] on both the database and table level. For example, a user will not be able to search for records in a database unless the [code]Search Records[/code] permission is set to [code]Allow[/code] for both the database and the table that contains the records. [/note]

Field Permissions

[p]Field permissions are established as preferences in the Setup > Data Sources > Fields page of Site Administration. Field permissions are discussed in the Setting Up Data Sources chapter, and also in the Record-Level Security section that follows. [/p]

[p]If both the database and table referenced by a given Lasso action have been allowed, then the field preferences are checked. Since field preferences cannot be set on a per-group basis, they are the same for all users who have access to the database and table regardless of what groups they belong to. [/p]

How Lasso checks field permissions:

1. The [code]Allow…[/code] preferences are checked to ensure the field can be used in searches, or can be modified. Otherwise, a security violation is generated.

2. The [code]Require an Exact Match… [/code]preferences are checked and if any are set to [code]Yes[/code], the values of the fields involved are compared to those in the database before the action is allowed. If any field values do not match, then a security violation is generated.

3. The field filters are processed. If any of them return errors, then the error is returned and the database action is not performed. Otherwise, the values of the field filters are used to process the database action.

4. If the field is being referenced as a response field, then the appropriate preferences must be established for the field. Otherwise, a security violation is generated.

Tag Permissions

[p]Lasso Security allows administrators to either [code]Allow [/code]or [code]Deny [/code]access to any of the tags in Lasso. The Setup > Security > Tags page in Site Administration allows the administrator to define all tag-level permissions for any existing group. [/p]

Figure 11: Tags Page

[p]The top panel shows the current group to the right of [code]Permissions For Group[/code]. The current group can be switched by selecting an existing group from the [code]Groups[/code] pull-down menu, and then selecting [code]Switch Group[/code]. [/p]

Setting Tag Category Permissions

[p]The[code] Tag Categories Listing [/code]panel shows a listing of all relevant tag categories for which tags can be enabled or disabled at the group level. Category level permissions can be set by selecting[code] Allow[/code] or [code]Deny [/code]from the [code]Status[/code] pull-down menu, and selecting [code]Update[/code]. All categories can be allowed or denied by selecting [code]Allow All[/code] or [code]Deny All[/code]. A [code]Mixed[/code] status indicates that a selected tag category may contain both [code]Allow[/code] and [code]Deny[/code] permissions for individual tags. [/p]

Setting Tag Permissions

[p]When a category is selected in the [code]Tag Categories Listing [/code]panel, it shows all relevant tags in that category and their security permissions for the selected group in the [code]Tags Listing[/code] panel. [code]Prev[/code] and [code]Next[/code] buttons appear for navigation if there are more than ten tags in a selected category. Each tag can be individually allowed or denied by selecting [code]Allow[/code] or [code]Deny [/code]from the [code]Status[/code] pull-down menu, and then selecting [code]Update[/code]. An [code]Ignore[/code] permission designates the absence of an [code]Allow[/code] or [code]Deny[/code] permission. All tags shown in the [code]Tags Listing[/code] panel can also be allowed or denied by selecting [code]Allow All[/code] or [code]Deny All[/code]. [/p]

Tag Dependencies

[p]Some Lasso tags have dependencies on other tags to function properly. If permissions for a tag has been denied that has dependencies with other tags, then those tags will not function correctly. For example, if [code][TCP_…] [/code]tags are denied, it will cause tags such as[code] [Email_Send] [/code]not to work, which relies on the use of the [code][TCP_…] [/code]tags. To see whether on not a tag has any dependencies, consult the Lasso 8 Reference and check to see if there are any tags listed in the [code]Required [/code]field in the [code]Detail[/code] view for any tag. [/p]

[p]When a user attempts to execute a tag, the permissions for all the groups they belong to are checked in sequence. The following steps are performed. [/p]

How Lasso Checks Tag Security Settings

1. The set of groups which the current user belongs to is identified. If the user belongs to more than one group, the permissions for each group will be checked in alphabetical order by group name.

2. The permissions for each group are checked for a permission which references the current tag. If an [code]Allow [/code]permission is found for the tag, then the tag execution is allowed. If a [code]Deny [/code]permission is found, then the tag execution is denied and a security violation is generated. Note that after the first [code]Allow [/code]or [code]Deny [/code]is found, no further checking is performed.

3. If no result is found, then the tag execution is allowed.

[p]This order of operation means that any tag which is not explicitly denied is implicitly allowed. [/p]

File Permissions

[p]Lasso Security allows administrators to establish permissions for what files a group of users can manipulate, and what operations they can perform on those files. [/p]

[p]The Setup > Security > Files page in Site Administration allows the administrator to set file-level security for selected groups. This affects the use of the [code][File_…],[/code] [code][HTTP_…][/code], [code][FTP_…][/code], [code][Image][/code], and [code][PDF_…][/code] tags, which are described in the Lasso 8.5 Language Guide and Lasso 8 Reference. [/p]

Figure 12: Files Page

[p]The top panel shows the current group to the right of [code]Permissions For Group[/code]. The current group can be switched by selecting an existing group from the[code] Group[/code] pull-down menu, and then selecting[code] Switch Group[/code]. [/p]

Viewing File Permissions

[p]The [code]File Permissions[/code] panel shows what file permissions the current group has. Each entry has two parts. [/p]

• [def]Path[/def] – The path in which a user can access files. Any files in sub-folders of this path can be accessed. A path starting with / is located within the Web server root. A path starting with [code]///[/code] or [code]C://[/code] is located outside the Web server root.
• The paths listed are all established by the server administrator for this site. By default permission is granted to access the Web server root and the file uploads location.
• [def]Permissions[/def] – Lists the permissions that a user in the current group has for files within the path. The meaning of the permissions are listed in full on the following page.

[p]Selecting any path shows information about the path in the Path Permissions panel to the right. The permissions can then be changed according to the instructions in the following section. [/p]

[note][b]Note: [/b]The final path [code]/ (Read Only)[/code] is included to indicate that permission is always granted for users to read any files within the Web server root. [/note]

[p]The Unassign All button at the bottom of the panel unassigns all permissions for all paths for the current group. The [code]Refresh[/code] button simply refreshes the current panel. [/p]

Updating File Permissions

[p]The[code] File Permissions[/code] panel shows the file permissions for a single path. The path can be changed or the file permissions for that path modified. [/p]

• •[def] [/def][def]File Root[/def] – Designates the folder that the group may access. Since the available roots are determined by the server administrator the root cannot be edited here.
• Inspect Files – Allows users in the group to retrieve information about files, such as the file size or creation date.
• Read Files – Allows users in the group to read the content of existing files.
• Create Files – Allows users in the group to create new files.
• Write Files – Allows users in the group to write to existing files.
• Move Files – Allows users in the group to move existing files.
• Copy Files – Allows users in the group to copy existing files.
• Delete Files – Allows users in the group to delete existing files.
• Any File Extensions – Allows users in the group to access files with any file permission, not just those which are explicitly allowed.

[p]File permissions can be set by selecting[code] Allow[/code] or [code]Deny [/code]for each permission, and selecting [code]Update[/code]. All permissions can be allowed or denied by selecting [code]Allow All[/code] or [code]Deny All[/code]. [/p]

File Uploading

[p]In order for site developers to be able to use uploaded files, they must be granted permission to access the temporary folder in which uploaded files are placed. They usually must also be granted permission to access a folder where the uploaded files will be copied permanently. [/p]

[p]The location of the temporary items folder can be different depending on how the operating system is set up. The server administrator needs to add the file uploads path to the list of available paths in order to allow group permission to be assigned to it. [/p]

[p]Lasso automatically deletes any files which are not removed from the temporary items folder before the current Lasso page is finished being processed. This ensures that unwanted uploads are not allowed to occupy disk space for longer than the time it takes Lasso to process a single Lasso page. [/p]

[p]In addition, the temporary items folder is automatically cleaned by the operating system when the computer is restarted. This ensures that even if Lasso Service crashes, unwanted file uploads will be deleted the next time the computer is restarted. [/p]

[p]See the Files and Logging chapter in the Lasso 8.5 Language Guide for more information about using file uploads. [/p]

How File Permissions are Checked

1. When a file tag is called, the groups for the current user are determined. In the following example, [code][File_Read][/code] attempts to read a file within the Web server root in a Windows machine.

[pre][code][File_Read: 'c://inetpub/wwwroot/default.lasso'][/code] [/pre]

2. The permissions for the groups are checked in alphabetical order by group name for a [code]File Root [/code]that contains the file which is referenced within the[code] [File_Read][/code] tag. For example, a group that provides access to the [code]wwwroot [/code]directory would match the [code][File_Read][/code] tag above.

[pre]Allow Path = 'c:/inetpub/wwwroot/' [/pre]

3. Once a matching [code]File Root [/code]is found, the individual permissions are checked. For a [code][File_Read][/code] tag, the user must be granted [code]Read Files [/code]permission.

4. If [code]Read Files [/code]is not permitted, then the permissions for the groups continue being checked for another permission that matches the[code] File Root [/code]of the parameter to [code][File_Read][/code]. If no valid permission can be found then a security violation is generated.

Web Server Security

[p]Most Web server applications provide built-in security which protects files with certain names or in certain directories. Lasso generally works in concert with Web server security, but can also be used in some instances to bypass Web server security. [/p]

• [def]Lasso Pages [/def]– If Lasso pages are called directly, they will only be served if the current site visitor has permission to access the specified file. For example, if the Web server has a realm protecting the folder [code]Private [/code]then the following URL can only be accessed if the visitor has permission to access that realm.

[pre]http://www.example.com/Private/default.lasso [/pre]

• Lasso will be called on to process the Lasso page only if the appropriate file suffix (e.g. [code].lasso[/code]) is set properly within the Web server administration options. The file suffix must also be allowed within Lasso Security.
• [def]Response Files [/def]– Lasso pages which are referenced using one of the [code]-Response…[/code] tags may obey Web server realms. Depending on the Web server application, Lasso checks with the Web server’s security before serving any file as a response page. Since Lasso can work with many different Web Server connectors it is best to test whether realms protect Lasso response files before relying on this security.
• For example, if the Web server has a realm protecting the folder [code]Private [/code]then the following URL can only be accessed if the visitor has permission to access that realm.

[pre]http://www.example.com/Action.Lasso?-Response=/Private/default.unknown [/pre]

• The suffix mappings within the Web server administration options do not have any effect on what files Lasso will process using a [code]-Response… [/code]tag. The [code].lasso[/code] suffix in [code]Action.Lasso [/code]ensures that Lasso is called without checking the file suffix of the actual response file.
• This allows Lasso pages with suffixes not defined in the Web server administration options to be processed by Lasso. However, the file suffix settings in Lasso Security do still apply. Lasso will only process Lasso pages with suffixes that have been allowed in Lasso Security. In this case, the suffix[code] .unknown[/code] would have to be allowed in Lasso Security.
• [def]Include Files [/def]– Lasso pages which are served as part of a valid Lasso pages using one of the [code][Include_…][/code] tags are not dependent on the Web server’s file suffix mappings or realms. Any file within the Web server root which is allowed by Lasso’s own file suffix settings within Lasso Security can be served using the [code][Include_…][/code] tag.

1. [note][b]Important: [/b]The [code][Include…] [/code]tags can be used to bypass Web server realms and serve any files from within the Web server root. Only trusted developers should be allowed to upload Lasso pages. [/note]

• [def]File Tags [/def]– The file tags can be used to manipulate any files within the [code]Allow Path [/code]according to the permissions which have been granted to the current group. It is important to grant only the least number of permissions which each developer needs to implement the desired behavior of their site.
• If [code]Allow Access to Files Outside Root [/code]is granted to a group, then any users in that group can access any files on the machine hosting Lasso Service. This includes any files on the machine inside or outside of the Web server root.

Record-Level Security

[p]Record-level security can be enabled in Lasso by setting fields to require an exact match when various Lasso actions are performed. A specific action will be allowed only if a value is specified for each field that requires an exact match, and if that value is exactly the same as the value currently stored in the database. [/p]

[p]Note that record-level security will only be checked if the current user has permission to perform the action in the database or table directly. Record-level security can only be used to deny actions to users who would otherwise be able to perform an action. [/p]

[p]Three types of actions can be secured using record-level security. [/p]

• [def]Search [/def]– Records can only be viewed when the proper value for a field is specified. This could be used to allow visitors to password protect individual records. No other visitors will be able to view a specific record unless they know the proper password.
• [def]Update [/def]– Records can be updated only when the proper value for a field is specified. This could be used to allow only authorized visitors to update certain records. No other visitors will be able to update a specific record unless they know the proper password. This can be used separate from the search option in order to allow visitors to view records, but not to update them.
• [def]Delete [/def]– Similarly, records can be deleted only when the proper value for a field is specified. This can secure a database so only certain users can delete records, or can serve as a simple check where deletes must be confirmed by specifying a special field value before they are carried out.

To establish record-level security:

1. Create two fields within the database or table to be secured. In the following example, [code]Username [/code]and [code]Password[/code] fields will be created in the [code]People [/code]table of the [code]Contacts [/code]database. Visitors will be able to specify their username and password when they create a new record. Only the visitor that created the record will then be able to update, or delete that record, but anyone will be able to view the record.

2. Within Site Administration Setup > Data Sources > Fields check the box for [code]Require an Exact Match on this Field when[/code] [code]Updating Records[/code] for both the [code]Username [/code]and [code]Password [/code]fields.

3. Ensure that the [code]AnyUser [/code]group has permission to search the database, add records to the database, and to update records within the database. The exact match option will only be checked when the user attempts to update a record within the database.

4. The add records page needs to require values for both the [code]Username [/code]and [code]Password [/code]fields. The following example shows an HTML form with [code]-Required [/code]command tags embedded before the text inputs for [code]Username [/code]and [code]Password[/code].

[pre]<form action="response.lasso" method="post"> [/pre]

[pre] <input type="hidden" name="-Required" value="">
<p>Username: <input type="text" name="Username" value=""> [/pre]

[pre] <input type="hidden" name="-Required" value="">
<p>Password: <input type="text" name="Password" value=""> [/pre]

[pre] <p>First Name: <input type="text" name="First_Name" value="">
<p>Last Name: <input type="text" name="Last_Name" value="">
<p>Phone: <input type="text" name="Phone_Number" value=""> [/pre]

[pre] <p><input type="submit" value="Add Record">
</form> [/pre]

• When this form is submitted, the following[code] [Inline] … [/Inline] [/code]tags in the [code]response.Lasso[/code] page add a new record to the table with the [code]Username [/code]and [code]Password [/code]established for that record.

[pre][Inline: -Add,
-Database='Contacts',
-Table='People',
-KeyField='ID',
'Username'=(Action_Param: 'Username'),
'Password'=(Action_Param: 'Password'),
'First_Name'=(Action_Param: 'First_Name'),
'Last_Name'=(Action_Param: 'Last_Name'),
'Phone_Number'=(Action_Param: 'Phone_Number')]
[/Inline] [/pre]

5. Any user will be able to view the [code]First_Name[/code], [code]Last_Name[/code], and [code]Phone_Number [/code]established for the user using simple search and response Lasso pages. Of course, the [code]Username [/code]and [code]Password [/code]fields should never be revealed on any search response.

6. Users will be able to modify their record in the database using the following update form. This form is similar to the add form which was defined above, but has the added feature of the exact match setting. Lasso Security will not allow the [code][Inline] … [/Inline] [/code]which this form triggers to be processed unless both the [code]Username [/code]and [code]Password [/code]fields are defined with the right values.

[pre]<form action="response.lasso" method="post"> [/pre]

[pre] <input type="hidden" name="-Required" value="">
<p>Username: <input type="text" name="Username" value=""> [/pre]

[pre] <input type="hidden" name="-Required" value="">
<p>Password: <input type="text" name="Password" value=""> [/pre]

[pre] <p>First Name: <input type="text" name="First_Name"
value="[Field: 'First_Name']">
<p>Last Name: <input type="text" name="Last_Name"
value="[Field: 'Last_Name']">
<p>Phone: <input type="text" name="Phone_Number"
value="[Field: 'Phone_Number']"> [/pre]

[pre] <p><input type="submit" name="-Nothing" value="Update Record">
</form> [/pre]

• When this form is submitted, the following [code][Inline] … [/Inline][/code] tags in [code]response.lasso [/code]perform the update action within the database.

[pre][Inline: -Update,
-Database='Contacts',
-Table='People',
-KeyField='ID',
-KeyValue=(KeyField_Value)
'Username'=(Action_Param: 'Username'),
'Password'=(Action_Param: 'Password'),
'First_Name'=(Action_Param: 'First_Name'),
'Last_Name'=(Action_Param: 'Last_Name'),
'Phone_Number'=(Action_Param: 'Phone_Number')]
[/Inline] [/pre]

Security Tips

[p]This section provides some important tips and concepts about using security on a Lasso Professional Server server. [/p]

General

• Grant the least number of privileges necessary for a user to access the resources they need. By denying all accesses and only granting permissions when needed, unauthorized uses of the server can be minimized. Additional permissions are easy to grant within Site Administration.
• Turn off Classic Lasso support to prevent the ability for site visitors to submit Lasso commands directly to your Web server through URLs or HTML form submissions.
• Never allow untrusted parties to write Lasso code in Lasso pages stored on your server. All Lasso tags should be authored by trusted developers. By default only code which is stored within valid Lasso pages (or database fields) can be executed by Lasso. Consider carefully before allowing code from other sources to be executed.
• Use operating system privileges to protect sensitive files. The security of a Web site goes only as far as the security which protects the Lasso pages and databases files that comprise it. Create user accounts so that only trusted users can modify or read critical files.
• Store backed-up setup files in a secure location. These files contain all of the passwords and security settings for Lasso Professional Server.
• Use SSL security when appropriate. Site Administration and custom-built Web site administration interfaces can be accessed through SSL for greater security.
• Disable any tag modules which will not be in use. Remove any third-party LCAPI or LJAPI tag modules or data sources which are not in use. Remove any libraries or LassoApps from [code]LassoStartup [/code]that are not in active use. Disable LJAPI if no LJAPI tag modules are in use.

Databases

• Never allow database files to be served directly by the Web server application. SQLite, FileMaker Pro, or other third party database files should never be stored within the Web server root. The database security in SQLite and FileMaker Pro is largely designed to prevent access to the databases through client applications or the graphical user interface. If a user gains access to the database file itself, they can usually read the data from it using a text editor.
• Store sensitive data encrypted within the database. The [code][Encrypt_…] [/code]tags can be used to encrypt data so only a Lasso page with the appropriate [code][Decrypt_…] [/code]tag can access it. Personal information and sensitive data like credit card numbers can be stored encrypted within the database, and only decrypted when necessary to process the order. Encryption tags are discussed in detail in the Encoding chapter of the Lasso 8.5 Language Guide.
• If sensitive information such as a record ID, password, or credit card number needs to be passed in a URL, or in a place where it can be viewed in the HTML source code, use of the [code][Encrypt_…] [/code]tags is recommended to encrypt the data so only a Lasso page with the appropriate [code][Decrypt_…] [/code]tag can access it.

User Authentication

• Once authentication information is entered into a Web browser for a specific Web server that same authentication information will be sent with each subsequent request.
• Usernames and passwords are cached by many Web browsers for easier authentication. If the username and password for the site administrator or any Lasso user is cached, then subsequent users of the Web browser may be able to access Site Administration or portions of a Web site without being prompted for authentication.
• If Site Administration or a protected area of a Web site is visited using a public browser such as in a library or Internet café, any requests to store cookies or cache usernames and passwords should be denied, and the history of the browser should be cleared before logging off of the machine.
• The site administrator is not bound by any of the settings established in Lasso Security. When a user is authenticated as the site administrator it may be possible to perform actions which are normally not allowed by Lasso Security.
• Sessions can be used to provide an alternate method of authentication for users. Sessions rely on cookies or information passed in URLs to authenticate a user. Sessions can be deleted explicitly, or will automatically timeout after a set period of inactivity.

Testing Solutions

• Each Web browser implements authentication in a slightly different fashion. If a Web site must be accessed from many different Web browsers, it should be tested on each one to ensure that the authentication works properly.
• Since authentication information is cached, the Web browser should be quit between each test of a different username and password. On some systems it might be necessary to quit all Internet applications in order to clear out cached usernames and passwords.
• Be careful with testing solutions using the same browser which has been used to access Site Administration. Since the site administrator can access any resources within Lasso, it can be difficult to tell how Lasso Security is set up if the current user is the site administrator.