Sharing Web Security Across Multiple Projects

Configuring an IIS Profile to Reference a Single Web Users Database in Multiple Applications

If you are using IIS, your IIS publishing profile can be configured to allow multiple apps to reference the same web users security database.

Accessing the same web user data across multiple apps is controlled through the publishing profile for each application under IIS. The membership and role provider settings must point to the same database and use the same value for the "Security application name" in the Publishing Profile. See the Provider Configuration Guide for more information about publishing profiles.

Configuring an IIS Publishing Profile

Configuring Web Security to Reference a Single Web Users Database in Multiple Applications

Setting Up Web Project Security Settings

If you are using the built-in Alpha Anywhere web security, you can configure the security settings for each app to reference the same web users security database. The user data must be stored in a SQL database. Multiple applications cannot reference the same web security data if it is stored in DBF tables.

When configuring security for your web application, the security profile must be identical in all applications that reference the same user data. If the profiles differ between apps, the login verification process will fail.

Password encryption settings must be identical in all applications. If encryption is enabled in one app, it must be enabled in all apps. Additionally, the password encryption key must also be identical in all apps that reference the same web security user database.

Password encryption settings must be identical in all apps that reference the same security data.

Creating Active Link Tables to Reference SQL Data

To configure an application to reference an existing security table, you must create the Active Link tables yourself. While the security framework can automatically generate the Active Link tables, the framework may also try to re-create the SQL tables during this process. Follow the instructions for creating Active Link tables in the Using SQL Tables in Web Security guide.

You can also copy the Active Link tables between projects. You will need to find and copy all of the files that begin with "websecurity_" in the project that has the Active Link tables. They are stored in .WebProject directory alongside the components and other files for your Alpha Anywhere application. Once you locate the websecurity files, copy them into the .WebProject directory for your application. This is usually the Default.WebProject directory found inside the *.WebProjects folder.

If you copy the Active Link tables, you need to make sure the connection string they use is configured properly. You can configure the connection string for the Active Link tables using the Control Panel (not to be confused with the Web Projects Control Panel.) Use the Add Tables/Sets tool under the File menu. Navigate to where the Active Link files were copied to in the .WebProject folder for your application. Add all of the files that begin with "websecurity_". Once listed in the Control Panel, you can validate the connection string for the Active Link Tables. Right-click on an Active Link table on the Tables/Sets tab in the Control Panel and select "Show Link Definition". Here, you can check the connection string configuration and determine the name of the AlphaDAO connection you need to create.

Using Separate Group and Member Tables

The only websecurity tables that need to be shared among applications are the users tables - websecurity_exprired and websecurity_users. The group and members tables - websecurity_groups and websecurity_members - can be unique to each project. Creating separate group and members tables enables you to specify only the groups you need for each project. This approach can be more complex but will give you a higher level of control over the groups defined for each project.

Using Groups to Restrict User Access to Specific Apps

Groups can be used to define access privileges for each application. This can be accomplished by either setting up separate group and members tables (see Using Separate Group and Member Tables above) or by defining a group for each app. The latter is described below.

Suppose you have three applications - AppA, AppB, and AppC - for which you want to restrict access to using the same web security database for all. You can create three groups that correspond to each application: Group_A, Group_B, and Group_C. Users in Group_A have access to AppA, users in Group_B have access to AppB, and users in Group_C have access to AppC.

When configuring security access for each app, security settings for the web pages and components in the app need to be configured to require login. Login required requires you specify which groups can access the pages when the user is logged in. For all files in AppB, the logged in user would need to be in Group_B to access them. Security groups can be required to access components, pages, reports, and other files and directories.

With this approach, all applications will have the same groups and users. This may require additional planning as not every group will be applicable to every project. One solution is to code the group names to indicate which project should use them.

Group_A
Group_A_report
Group_A_maps
Group_B
Group_C
Group_C_report