Alpha Anywhere Application Server Active Directory Authentication and Authorization

Overview

Active Directory authentication and authorization can be used in 2 different ways in Alpha Anywhere:
  1. Use an Active Directory rather than a custom database to validate credentials that a user enters into a login page.
  2. "Windows Integrated Authentication" whereby a user and the server are in the same Active Directory domain and an automatic negotiation can be done to identify the user*.
*Windows Integrated Authentication is only implemented in Alpha Anywhere Application Server for IIS beta as of build 2358.

Assumptions

The Active Directory store is treated as read only by Alpha Anywhere. Management of Active Directory users and groups is outside the scope of Alpha Anywhere and is left to the Active Directory administrator's usual tools.

A web application that uses a form to collect user credentials should run over HTTPS so that the credentials are encrypted when transmitted from the browser to the server.

Using Active Directory Authentication and Authorization

Set Web Security Configuration

Edit the Web Security Configuration for your web project.

Web security configuration icon in the web security dialog.

Select the "Use Active Directory" option. The prompt below this option will change to read "Security Table Type for Development and Testing". DBF File or SQL Database will still be used for developing and testing of the application. This means you can develop and test the application without having or needing to have access to the production Active Directory domain. The group names used during development and testing do need to be the same as in the Active Directory. The "Web User and Groups" dialog "Groups" tab allows group names to be imported from an Active Directory or a text file. Create or edit the publish profile settings for the production web server to configure the Active Directory server used in production. Publish profile setting for development and test servers should use the custom DBF file or SQL database.

Security settings dialog.

Select the remainder of security settings needed like the redirect pages.

Users and Groups

While users and groups are now used through Active Directory, developing and testing the web application against a production Active Directory server can be impractical because you may not have access to the Active Directory server. For this reason you will want to create users and groups to be stored in a DBF file or SQL database. These users and groups will be used during development and testing.

In order to work in this way the name of the groups you want to secure against must be spelled the same way as they are stored in the Active Directory. If you only have a few you can manually enter the groups and add some users as members of the groups. Otherwise, you can import groups directly from Active Directory or from a file.

Web users and groups dialog with the groups tab selected and the import groups link highlighted.

Import Active Directory groups dialog.

Importing groups gives you the option to merge into existing groups (add group names not already in the list), overwrite existing groups (delete all groups before adding groups being imported), and include a test user in each group.

Note: As of build 2358 the format of the group name as changed. It is now prefixed with the domain name e.g. ACME\Human Resources. Groups that were imported or entered before build 2358 will need to be reimported or manually updated to include the domain prefix. This change is required to support integrated authorization under IIS.

Note: When you select to include a test user in a group the test user's name will be the group name prepended with "TestUser-" and the test user's password is set to the string "password".

Example: A group name of "Engineering" will get a test user with the name "TestUser-Engineering".

Caution: When "Overwrite existing groups" is selected, existing groups will be deleted. This means that any existing page, component or component control's security settings are removed and will have to be reapplied.

To import groups from a file change the Group name source to "File". Then specify a file that has the name of each group on a separate line. A test user name can be include for the groups too. The test user name follows the group name on the same line. Two tab characters are between the group name and the test user name. The format of the test user name is the test user's name followed by a | character and then the SAM-Account-Name for the test user. Example: John Doe|jdoe.

A command line tool named A5ActiveDirectoryExport.exe is included in the Alpha Anywhere Developer Edition install for generating a file from an Active Directory that can be imported by Alpha Anywhere Developer Edition. This stand alone exe file can be sent to anyone who has access to Active Directory to create a file for import. The command line options are:

-hShow the command line options.
-dSpecify a domain name.
-uUsername that has permission to access Active Directory.
-ppassword of the Username that has permission to access Active Directory.
-iuInclude a group's users.
-ouRestrict groups that are output to a specific organizational unit.

Example usage:

A5ActiveDirectoryExport -iu > ad.txt

This will create a file named ad.txt that will contain groups and test users for current user's domain and will access Active Directory with the current user's identity. The test user names and SAM-Account-Name that are generated are the same. Example: TestUser-Engineering|TestUser-Engineering.

A5ActiveDirectoryExport -iu -ou "East Coast"> adEastCoast.txt

This will create a file named adEastCoast.txt that will contain groups and test users for current user's domain in the organizational unit of "East Coast" and will access Active Directory with the current user's identity. The test user names and SAM-Account-Name that are generated are the same. Example: TestUser-Engineering|TestUser-Engineering.

Publishing an Application

In order to use Active Directory in a web application the publishing profile must define an Active Directory configuration. The create publish profile genie adds a security store type for the Active Directory configuration if the security settings has the "Use Active Directory" option set. This will be the last page of the genie.

Create publishing profile Active Directory genie page.

When the "Configure Active Directory" button is selected the Active Directory Configuration dialog is shown. If an Active Directory server is detected the fields will default to use that Active Directory server.

Select an Active Directory configuration mode to be used.

To change a publish profile's Active Directory configuration locate the Active Directory settings in the publish profile's Miscellaneous section of the property sheet. Change the security store type to change whether an Active Directory configuration is published and/or change the Active Directory configuration by clicking on the smart field button in the "Configure Active Directory" option.

Active Directory options in the publish profile dialog.

Testing an Application

When testing and developing a web application it is necessary to validate correct user authorization to parts of the application. For instance, the web application may have a back office component that should only be available to users in the "web app administrator" group. This is why users can still be defined in the web project's security settings. When publishing to a test environment, instead of defining an Active Directory configuration publish the Alpha Anywhere security tables so that they will be used for authentication and authorization instead of Active Directory. This give the ability to accurately test authorization.

Note: If your test environment includes a test Active Directory domain you, of course, can define an Active Directory configuration to that test Active Directory domain in your publish profile for the test environment.